java.exe process holding on to port 9001 after stop

I get this too:

The error message was: The application script threw an exception: java.lang.OutOfMemoryError: Java heap space BSF info: null at line: 0 column: columnNo

I've followed the FAQ's on optimizing and increasing memory (to 1000 MB), and I've done everything except reduce the amount of information being saved in session variables, and clicking off "tidy html" which really would be problematic. I'm running screen scraper as a server, and starting it from the command line, and still it craps out after about 700 records (same as running it in the gui console, incidentally). Very frustrating! It seems there really ought to be a a way to clear this while the process is running.

Ok, it looks like an unhandled exception in some subsystem triggers a process shutdown, which orphans the java.exe process hosting the database.

I finally observed a crash and realized that abnormal termination is what orphans the db process in this situation (not sure if this applies to using the Win32 SCM API, but it could be similar). Searching through the log files (all 537,000!) I found the following message. It appears that there could be a memory leak somewhere. The process itself, while running into the 600MB range, is on a box which can handle that kind of memory usage. Seeing the bit about the inability to create a native thread, it could be stack exhaustion, but I'd guess that would be a StackOverflowException or similar - but I have no clue how java handles native Win32 threads.

Actually - I just noticed this behavior with the batch files as well on v3.18a. I'll try to repro it to get a better case for you, but I'm really crunched for time, so it may be a while.

In the mean time, have you considered using the Win32 Job API to batch these processes together, so that their lifetime is controlled as one unit?

Ok, I looked at the bat files and they appear to work, since somehow the "Wrapper.exe" process knows about shutting the DB java.exe process first. While this is really not optimal over using the built-in Windows APIs to do it, I'll accept that things have to be done this way. Ultimately it is not a Windows permissions issue, since the logon session I use to stop the services is the same - the same token with all the same privileges and rights for each method.

Thanks for pointing me to the Wrapper.exe program.

Hi Todd -

Here are the details:

1) I'm using XPSP2.
2) I'm stopping the service using the Win32 Service Control Manager API.
3) I'm running the process that stops the service under an account that has admin privileges on the machine.

On further investigation, the SS service is running under a different logon session, and so the process I am using to monitor and control the SS service doesn't have ownership of the SS processes. This results in the Access Denied error when I try to kill it, even thought I have admin privs. Once I take ownership of the process, or enable the SeDebugPrivilegeName privilege on the process token, I can kill it.

However, this is all a bit heavy handed - the real problem is that when the service is shut down, a java.exe process is left over. Any idea why this happens?

I see this a fair bit on a reallly old windows 2000 (rc1 patched) box with not enough memory and a slow processor (read: Not likely ss's fault since it's such a crappy box and os install) -- I use the SysInternals Process Exporer, which lets you kill things with much more power than the standard task manager. Kill's 'em dead every time.