I'm still trying to find a solution for the issue raised earlier this year, and discussed with Bryan Schumsky during the Revelation Conference in Seattle. Please allow me a couple of statements and questions:

1) On server (A) I have Apache 2.2.3 running on Windows server 2003 SP1, OECGI2.EXE is in the cgi-bin directory, its registry settings for ServerPort and ServerURL point to my server (B).

2) On server (B) I have the UDH and the OEngineServer running on Windows server 2003 R2, the OI application which is called from OECGI2 resides on that same server and has a runtime license for 256 concurrent users.

3) For each and every request coming from OECGI2 I see (in the task manager of server (B)) java.exe eating up to 100% CPU for the entire duration of the request (i.e. try to imagine a request that gives you, say, 1000 records back sorted alphabetically, hit mutiple times…). Is this behavior correct? And why (because in this case i don't understand the benefit of having multiple engines running simultaneously)?

4) How can I avoid java.exe to eating all of the CPU forever, in case of a great number of simultaneous requests?

5) If this can't be solved, may I implement a different technology? Which one?

My diagnose if perhaps completely faulty, but I really don't know what else to do, where else to look. Do you believe me if I say that I'm worried (and kind of upset)?

Many thanks in advance for any hint.

Stefano

Hi, Stefano. At the conference, I gave you updated components for testing - did they make _any_ difference in the behaviour you're seeing? Are you still getting OEngines that appear to terminate improperly?

One of the first things we need to do is isolate where the cpu-intensive processing is coming from. My initial feeling is that it's not, actually, java.exe (running the oesocketserver.jar) nor oecgi2.exe - at least in our tests in-house, we didn't see those components consume 100% cpu.

So first, let's see what happens when you run your routine with the same inputs, but from OpenInsight directly. Please determine the name of the routine you run from the OECGI2 interface (you can look in your registry, HKEY_LOCAL_MACHINE\SOFTWARE\REVSOFT\OECGI2 at the ProcedureName parameter), and the exact string that's coming in from the browser during one of these requests. From the System Monitor, please type in RUN "". If you look at the Task Manager CPU's usage during this request, what does it show?

Thanks,

- Bryan Shumsky

Hi Bryan,

Hi, Stefano. At the conference, I gave you updated components for testing - did they make _any_ difference in the behaviour you're seeing? Are you still getting OEngines that appear to terminate improperly?

Unfortunately I see no difference. Is it correct that some of the engines (oengine.exe) use 5MB of memory, while some others only use 900kB?

One of the first things we need to do is isolate where the cpu-intensive processing is coming from. My initial feeling is that it's not, actually, java.exe (running the oesocketserver.jar) nor oecgi2.exe - at least in our tests in-house, we didn't see those components consume 100% cpu.

java.exe consumes up to 100% cpu while processing an OECGI2 request, in order to see it you need to fire a "stressing" (i.e. with lots of I/O) request, maybe multiple times. oecgi2.exe (on the other machine) consumes up to 100% cpu as soon as java.exe is in the above state.

So first, let's see what happens when you run your routine with the same inputs, but from OpenInsight directly. Please determine the name of the routine you run from the OECGI2 interface (you can look in your registry, HKEY_LOCAL_MACHINE\SOFTWARE\REVSOFT\OECGI2 at the ProcedureName parameter), and the exact string that's coming in from the browser during one of these requests. From the System Monitor, please type in RUN "". If you look at the Task Manager CPU's usage during this request, what does it show?

Well, I see OINSIGHT.exe consuming between 20% and 70% (if I keep hitting return on a silly request like "give me all documents containing an a") cpu until the result is sent back.

Stefano

View this thread on the Works forum...