After running for a while (hours, few days), the wrapper
suddenly stops:
-------------------------------
...
INFO | jvm 1 | 2005/01/06 09:32:55 | Job Finished
(3674562).
STATUS | wrapper | 2005/01/06 11:28:54 | <--
Wrapper Stopped
-------------------------------
but the Windows services still shows that the service is
running.
Logged In: YES
user_id=228081
The Wrapper will stop like that for a few reasons. I would
not be able to tell you the exact cause without seeing the
Debug output. Can you set the wrapper.debug=true property
and run your application again?
1) All non-daemon threads have exited.
2) System.exit was called.
Other causes for the exit would have resulting in a log entry.
As for the second issue about the service still being shown
as running. Where are you seeing that? If you are looking
at the service control panel, it must be refreshed to see
the latest status of services. You can also run "net
start" to get a list of currently running services.
Cheers,
Leif
Logged In: YES
user_id=667728
Neither 1) nor 2) because I was able to connect from my
client application to my server application (that runs as a
service). But the server didn't do anything anymore, no
logging, no processing, nothing. After such a problem, I
always start my server as a normal application (not as a
service), but then the server always runs flawlessly for days.
Then I switch back to run as service and such unexpected
halts/stops occur. Sometimes the service just stops for no
reason (Service panel shows that servcie doesn't run
anymore).
I now installed JRE 1.5.0_01 and run the service with
wrapper.debug=true. Hope that it doesn't stop during
weekend but next week soon.
Anyway, the wrapper should log more information when it
stops - no matter what reason. It doesn't hurt to have more
lines in the log when the wrapper stops. And then you don't
have to deinstall/install the service to switch debug just to
find reasons for unexpected halts/stops (as they seem to
appear for other users also).
Logged In: YES
user_id=228081
The Wrapper never exits abnormally without showing a message
that I am aware of. Enabling debug output will show exactly
what is going on. If there are other failure modes where
additional output should be getting logged then I will be
happy to add them.
You say that your server application is up, but just not
responding. Is this before or after the Wrapper has quit?
You are seeing the "<-- Wrapper Stopped" message, so this
does not appear to be a problem where the Wrapper process is
crashing.
Cheers,
Leif
Logged In: YES
user_id=667728
This morning, the services just re-started for no reason! The
wrapper log (debug mode) didn't lag anything new (last entry
3 days ago). But my applications log showed that the
application must have exited and started from new. At this
time a co-worker told me that the client application suddenly
lost connection to the server. The log files of server and
client showed the exact time frames.
Under this condition, we can't use the service wrapper in
production mode. It's just strange that the wrapper doesn't
log such states...
Logged In: YES
user_id=667728
I found the bug: as this was (thankfully) reproducable, i found
the state where this strange bug occurs:
- last friday, I changed the service so that the logfile was not
written to the current working dir but to "%
TEMP%/jServiceWrapper.log". My tests were successful, so I
thought my set of tests jobs where enough.
- as these sudden restarts occured today, I changed back
the location of the wrapper log file and the jobs that caused
the restart continued working (no restart of service anymore).
- then I change the wrapper log back to %TEMP% and
debugged my code. I noticed that the restarts occured when
my code had a
System.err.println();
line. I replaced the System.err.println() calls with a
corresponding logger call and voila ... the service didn't
restarted anymore.
The first thing that came to my mind where the Java Service
Wrapper filters, but I just have this one:
wrapper.filter.trigger.1=java.lang.OutOfMemoryError
wrapper.filter.action.1=RESTART
and I can't remember to thought about filter System.err.
The conclusion is, that the Service Wrapper doesn't like
System.err calls. As I understand that they don't make too
much sense (and should not be used in service applications),
the wrapper should at least handle them nicely (or is this
impossible?). The wrapper should at least ignore them or (if
possible) print them to it's log.
However, the replacement of the System.err's with logger
calls fixed my problem - but the wrapper log does not log
anything to the log file! I have wrapper.debug=TRUE, but the
wrapper just logs
----------------------
STATUS | wrapper | 2005/01/07 10:01:11 | iComps IJS
removed.
DEBUG | wrapper | 2005/01/07 10:09:34 | Working directory
set to: ../
DEBUG | wrapper | 2005/01/07 10:09:34 | Service
command: "F:\Program
Files\ijsJobScheduler\JavaServiceWrapper\wrapper.exe" -s
wrapper.conf
STATUS | wrapper | 2005/01/07 10:09:35 | IJS installed.
-------------------
as when i change the logfile from %TEMP% to current working
dir, the wrapper logs lots of things (also pings). So this is still
an open issue that I don't understand...
Logged In: YES
user_id=667728
addendum: well, well ... the restart keeps occuring with other
jobs - this time during FOP. I moved the wrapper log back to
the current working dir and then it works. Even though the %
TEMP% dir (f:\temp) has a security setting of "Everyone is
allowed to do everything", this doesn't seem to work properly.
Now that I have moved the log file back, all the log entries
reappear and the service doesn't restart anymore (hopefully
not anymore at all). I browsed the Java Service Wrapper
homepage but haven't found a hint concerning this so far ... ?
Logged In: YES
user_id=667728
Changed the title of this bug report to reflect the real issue.