I'm trying to implement scheduler to my application. I use spring and quartz support.
I have test my component and run perfectly.
My Main method is:
public class Main {
public static void main(String[] args) {
new ClassPathXmlApplicationContext("application-context.xml");
}
}
I use wrapper-windows-x86-32-3.5.7, I configure the wrapper.conf, and run from console using DemoApp.bat wrapper.
It works.
But When I want to install the service, I got error message Startup failed: Timed out waiting for a signal from the JVM.
After 5 times repetition, I got error message
JVM did not exit on request, terminated
There were 5 failed launches in a row, each lasting less than 300 seconds. Giving up.
Thanks for help.
Because it is working fine for you running in a console, but not as a service. This is most likely a problem with the environment of the SYSTEM user. The most common cause is not being able to locate the java binary. The cause should be fairly obvious if you look in the wrapper.log file.
The default location of the java binary is:
wrapper.java.command=java
This will cause it to be found on the PATH. To use a JAVA_HOME location, try the following:
wrapper.java.command=%JAVA_HOME%/bin/java
Then make sure you have declared the JAVA_HOME variable as a SYSTEM WIDE variable, not jsut for your current user account.
Cheers,
Leif
Related
Im developing a Spring Boot Web Application, using SWI-Prolog's JPL interface to call Prolog from Java. In development mode everything runs OK.
When I deploy it to Docker the first call on JPL through API, runs fine. When I try to call JPL again, JVM crashes.
I use LD_PRELOAD to point to libswipl.so
SWI_HOME_DIR is set also.
LD_LIBRARY_PATH is set to point to libjvm.so
My Controller function:
#PostMapping("/rules/testAPI/")
#Timed
public List<String> insertRule() {
String use_module_http = "use_module(library(http/http_open)).";
JPL.init();
Query q1 = new Query(use_module_http);
if (!q1.hasNext()) {
System.out.println("Failed to load HTTP Module");
} else {
System.out.println("Succeeded to load HTTP Module");
}
return null;
}
Console output
1st Call
Succeeded to load HTTP Module
2nd Call
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f31705294b2, pid=16, tid=0x00007f30d2eee700
#
# JRE version: OpenJDK Runtime Environment (8.0_191-b12) (build 1.8.0_191-8u191-b12-2ubuntu0.18.04.1-b12)
# Java VM: OpenJDK 64-Bit Server VM (25.191-b12 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libswipl.so+0xb34b2] PL_thread_attach_engine+0xe2
#
# Core dump written. Default location: //core or core.16
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
I uploaded the error log file in pastebin. click here
Has anyone faced the same problem? Is there a solution about this?
Note that, I also checked it also with oracle-java-8 but the same error occurs.
UPDATE:
#CapelliC answer didn't work.
I think I would try to 'consume' the term. For instance
Query q1 = new Query(use_module_http);
if (!q1.hasNext()) {
System.out.println("Failed to load HTTP Module");
} else {
System.out.println("Succeeded to load HTTP Module:"+q1.next().toString());
// remember q1.close() if there could be multiple soultions
}
or better
if ((new Query(use_module_http)).oneSolution() == null) ...
or still better
if ((new Query(use_module_http)).hasSolution() == false) ...
Not a direct answer because it suggests a different approach, but for a long time I was running a setup where a C++ program I wrote would wrap SWI-Prolog the way you're doing with Spring Boot and it was very difficult to add features to/maintain. About a year ago I went to a totally different approach where I added a MQTT plugin to SWI-Prolog so my Prolog code could run continuously and respond to and send MQTT messages. So now Prolog can interoperate with other modules in a variety of languages (mostly Java), but everything runs in its own process. This has worked out MUCH better for me and I've got everything running in Docker containers - including the MQTT broker. I'm not firmly suggesting MQTT (though I like it), just to consider the approach of having Java and Prolog less tightly coupled.
Most likely the reason why it is failing the second time is because you are calling JPL.init() again. It should be called only once.
Finally it was a bug of JPL package. After contacting SWI-Prolog developers, they patched a fix to the SWI-Prolog Git and now the error is gone!
Right configuration, so that Docker container be able to understand JPL is found in this link: Github : env.sh
I want to create a Windows system service using QT/MinGW which communicates with other applications over DBUS (from freedesktop.org). For the moment DBUS is running as a "service" by meaning of it was installed as service using the instsrv/srvany tools (however, the DBUS will get it's bus-service-win later). Since running as a service, DBUS is running as system bus.
I wrote a simple application to ensure that DBUS is working (creates on simple object with 1 method and exectued it with QDBusViewer). Well, that worked.
Next I tried to use the same DBUS stuff in the ServiceMain from my service, where ServiceMain is a member of a class created by our own). I can see the object in QDBusViewer, but as soon as I select it, QDBusViewer reported a timeout (no reply) after it stucked for a while.
I have seen this behavior in my test application, and could fix it by creating a QCoreApplication "app" and "block" on app.exec() after the DBus object have been created. I tried the same in the service, but got a warning that QCoreApplication was not created in the main thread, and the problem still persists.
I tried to create "app" in the function that calls StartServiceControlDispatcher() and run app.exec in the ServiceMain, but app.exec() quits immediately with a the error "must be called from the main thread".
How can I get over this? Have much thanks in before.
Comparing my own service class against the QtService class from "QT Solution" fixed my problem.
All after all I needed to put the StartServiceControlDispatcher() function into a QThread and change the method of my service class in a way that exec() is only executed when definitely running in the context of the SCM.
I have compiled a program on Windows Server 2008 using GHC 7.6.3 32-bit. I'm attempting to run it via a service within windows on boot-up (and ideally keep it up). To do so I have created a service with the following command successfully
sc create stworker binPath= "C:\Users\vagrant\Desktop\worker.exe"
The problem I'm having is that when I attempt to start the service I receive the following error (see image below).
The executable runs fine when I double click it. So not sure why Windows wouldn't allow the service to be run.
I don't think this is an issue w/ GHC. I'm under the assumption that GHC compiles to native code and not MSIL.
So any ideas why I can't run my executable as a service?
As mentioned in the comments, you need to actually implement the Win32 service API for your program to behave as a Windows service, and you can do this using the Win32-services package.
There's also a wrapper package Win32-services-wrapper that I wrote that aims to provide some of the boilerplate and handle logging, so that defining a service looks like this:
main =
defineService $
Service {
serviceName = "Service",
-- Start the service given a debug handle to write to.
-- Make sure not to use stdout or stderr as they don't exist.
-- Any state needed by serviceStop can be returned here -
-- the Service type takes the type of the state as a type parameter
serviceStart = \debugHandle -> ...,
-- Stop the service given the service state returned by serviceStart
serviceStop = \serviceState -> ...
}
There's a real example of using it in darcsden.
A previous post on this subject has been helpful (see How to export TestExecute/TestComplete results to teamcity?)
Right now, our TestComplete solution creates a text file that MSBuild consumes with a Microsoft.Build.Utilities.Task helper that sends the messages back up to TeamCity. However, I'm wondering if we can do better.
The TeamCity help topic (http://confluence.jetbrains.com/display/TCD65/Build+Script+Interaction+with+TeamCity#BuildScriptInteractionwithTeamCity-ServiceMessages) says, messages "should be printed into standard output stream of the build". What I'm trying to figure out is, can I directly access that stream from the TestComplete script?
I was hoping that it would be something as simple as:
dotNET.System.Console.WriteLine_11("##teamCity[testSuiteStarted name='Foo']");
But that is obviously not giving me the correct output stream. Thoughts? Can it be done?
The issue you are experiencing is that TestComplete does not support writing to the standard output stream, even if you invoke the CLR Console.WriteLine, you are writing to the process named tcHostingProcess.exe in which all CLR objects exist.
In order to work around this, you need a console application running that can accept messages from your TestComplete project. There are a number of ways to do this, but here is a proposed solution using TCP/IP for the necessary IPC.
In TeamCity
In the TeamCity build steps, you want the TestComplete or TestExecute process to launch without holding up the build script and then to launch a custom console application which will receive the messages from TestComplete.
start TestComplete.exe [arg1] [arg2] ...
TCConsoleHost.exe
Console Host Application
The console host program will start a TcpListener, and once a client connects, it will read messages from the resulting NetworkStream object and print them to the console. This program will continue until there is an error in reading from the stream (i.e. TestComplete has exited).
class Program
{
static void Main(string[] args)
{
TcpListener listener = new TcpListener(IPAddress.Parse("127.0.0.1"), 9800);
listener.Start();
TcpClient client = listener.AcceptTcpClient();
NetworkStream stream = client.GetStream();
BinaryReader reader = new BinaryReader(stream);
while (true)
{
try
{
string message = reader.ReadString();
Console.WriteLine(message);
}
catch
{
break;
}
}
}
}
Message Client Class
Likewise, we can create a TcpClient which can connect to our listening process and relay messages. The real trick here is to wrap this in a static class with a static constructor so that once TestComplete loads the CLR bridge, it will automatically connect and be ready to send the messages. This example has a TeamCity service message function SendMessage which automatically formats the message (including escaping single quotes).
public static class TCServiceMessageClient
{
static BinaryWriter writer;
static NetworkStream stream;
static TCServiceMessageClient()
{
TcpClient client = new TcpClient();
client.Connect("127.0.0.1", 9800);
stream = client.GetStream();
writer = new BinaryWriter(stream);
}
public static void SendMessage(string message)
{
writer.Write(string.Format("##teamcity[message text='{0}'", message.Replace("'","|'")));
}
}
In TestComplete
Now, since the client will automatically connect when the CLR bridge is loaded, the only code necessary in TestComplete is:
dotNET["TCServiceMessageClient"]["TCServiceMessageClient"]["SendMessage"]("Hello TeamCity!");
Additional Notes
There are a few caveats with the above code, namely timing, reconnect, etc. A deployed solution should have better error handling of the network conditions. Additionally, it may be more desirable that the TCMessageHost application actually launches TestComplete directly with a System.Process object so that it can more reliably wait for the application to exit.
I'm working with TeamCity and TestComplete as well. I ran into the exact same problem, and you can't write to the console no matter what you try to do, at least not that I've found. I even tried writing a C# app that I used the CLR bridge in TestComplete to talk to it, and still nothing.
What we ended up doing was to create batch file that handles the TestExecute call. We then call the batch file from TeamCity. To call TestExecute use this (with your pjs file and /p specific to your tests):
start /wait TestExecute "{TestCaseID}.pjs" /r /e /p:"{TestCaseID}" /silentmode /forceconversion
Then we check the ERRORLEVEL property returned by TestExecute. A level of 2 means that the test execution failed. In that case, we print the following with an echo statement:
##teamcity[testFailed name='{TestCaseID} - {TestName}' message='TestExecute reported a failure' details='See artifacts']
After TestExecute closes, it will attempt to open the log file. We have our build servers set so that mht files are opened by the calculator since they take a while to open (set it as the default in the Windows Right-Click -> Open With menu). So, after TestExecute completes, it opens the calculator, then our batch file just kills the calculator using taskkill.
We then copy the result file from TestExecute into a specified location (this is a separate executable that we wrote). The we finish the test execution and publish our artifacts to TestExecute:
echo ##teamcity[testFinished name='{TestCaseID} - {TestName}' duration='%milliSecondsElapsed%']
echo ##teamcity[publishArtifacts 'C:\BuildResults\{GroupName}\{TestCaseID}\*.mht']
One thing to note: We were never able to get TestExecute to reliably run a single test at a time, so we actually use a list of our test cases to generate separate pjs and mds files for each of our test cases. Then we use those generated pjs and mds files in TestExecute. That's where the {GroupName}, {TestCaseID}, and {TestName} variables from above come from. Those are specific to our implementation, but you may need different indicators there.
Hope this helps!
If you are using TestExecute this has become "Relatively" simple recently
Execute TestExecute with the following parameters:
/exportlog:"log\Index.html" /SilentMode /DoNotShowLog
For a full rundown of TestExecute parameters check: https://support.smartbear.com/testexecute/docs/running/automating/command-line/command-line.html
Setup your TestComplete project with a build level report:
Please be aware it is case sensitive
On your build configuration, in the general settings tab, export the generated log folder as an artifact.
Once the build has run, you will be able to see the test log embedded within TeamCity:
This is using TestComplete V14 and TeamCity 2019.1
I am trying to queue a build in my own build definition. But the sql connection in my code throws an exception that Login failed for user 'domainName\computerName$' which is natural since it should have used domainName\userAlias.
My question is why is it using domainName\computerName, and how to make it use windows auth instead? Can some one please help me with this?
You need to set the service account that the build service uses on the server(s) running your Build Agent(s). It sounds like it's currently set to run as Network Service.
You can change it by firing up TFS Admin Console, and going to Build Configuration and changing the properties on the service: