We've been testing OECGI3.EXE with our existing web app which was running on OECGI.EXE… Everything was working OK for the first couple of days; but all the sudden when we browse to the server we are getting:

1
Login failed
0

We have not made any changes… Never seen this before… I have requested ADMIN to stop and restart OEngineServer; but I'm afraid if it resolved the issue it will be temporary…

We recently upgraded from 8.03 to 9.2.1 which I assume we are using the latest OESocketServer.jar it's dated 12/14/2010…

Any ideas?

Thanks

Paulo

Just wondering … did you change the reg settings after upgrading to Oecgi3? As a check could you list the export. What is the server OS?

Was the OEngineServer stopped when the update was run? If not stop it and reapply the update.

Was the eServer.cfg file customized? If so restore this file from a backup prior to the update or edit the file to the correct values. The update will overwrite this file with the default version.

Paulo,

we ran into into the same problem when upgrading from OI 9.1.1 to 9.2, and again from 9.2 to 9.2.1. I suspect it has to do with the OESocketServer.jar file, and was promptly reported to this WORKS discussion, but never got a solution. As a workaround, we replaced the OESocketServer.jar file (version 1.0.0e) with its previous version (1.0.0d, that one shipping with OI 9.1.1), and that did the trick.

Hope it helps,

Stefano

This started happening at one of my sites upon upgrade to 9.2.1, but some week or so after. This is intermittent.

Do you have a SysDown page? If so, does it get presented? Mine does.

I find no problems in Windows Events or the Apache log (until it fails and I get oecdi3.exe errors in Apache).

Revelation has not yet sent me a fix.

I'll try this .jar idea and report back.

Dave

Hi, Paulo.

The biggest difference between OECGI and OECGI3 (as you may already know) is that OECGI3 uses the Engine Server (OESocketServer.jar) to create new engines dynamically, and that these engines (once created) are kept around in a cache to improve performance.

The error message you're seeing is telling us that the attempt by the Engine Server to create a new engine failed, and so isn't actually a failure in OECGI3 - it's successfully talked to the engine server, and received a response. The problem, as I said, is that the Engine Server was unable to create a new engine.

This might be caused by having too many engines running at one time, and thus running out of licenses; alternatively, the machine that's running the Engine Server may be "too busy" and thus the creation of a new Engine takes too long and times out.

Unless you are getting this message on _every_ request, I would think the problem wasn't caused by problems with your registry settings; if it's a sporadic error, or an error that only starts up after some time, then I'd think it's more likely one of the issues I mentioned above.

Hope that helps,

- Bryan Shumsky

Revelation Software

Well, what Brian says is certainly worth a double-check - HW and SW environments are all different. It just didn't work for us. We spent a lot of time trying to trace and debug this issue, with no luck at all. We are not able to make it happen on purpose. One of the nice things we provide is a 24/7 service, and having the system intermittently responding with a "Login failed" is simply not affordable. Thus the decision of downgrading the OESocketServer.jar file - version 1.0.0d is rock solid, it never complains.

Stefano

Folks,

Thanks for all the feedback; one of the things I've been noticing about OengineServer service is that it's a lot more sensitive than the old OECGI.EXE using a workstation with 1 engine to handle requests…

We currently have the MaxEngines=10

Keeping in mind other than adding the OECGI3 registry entry and parameters nothing else has changed… We have an application called ISYS which contains certain volumes / tables attached and in some cases some tables can be found deep in the DBT and they also show in SYSTABLES but are no-ware to be found on Database Manager… in the old OECGI.EXE I assume this was ignored; cause once we moved it over we started getting a SP (can't remember number) open media because the files not showing in the Database Manager were causing these issues… So using an editor I stripped the files from DBT and we no longer had these issues… (there has to be an easier way to edit / manage a DBT)…

My theory is that every time a session / engine was open and had this error; session would crash… the next time it would open a new sessions once the last session (10th) is used and crashes that's when we start getting the login failed message because it can't open new engines… again this was not tested but my theory…

We still have a few issues / tweaks we need to work adjust… but I've noticed this message coming up a few times… this is what I'm currently trying to figure out…

"CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers."

Any ideas?

Thanks

Paulo

Hi, Paulo. Glad you were able to track down problem #1.

As for problem #2…

This means that the routine you're calling didn't return its full results. It might have returned _nothing_, or it might have returned a partial page. This could either be by design (that is, it returned nothing because it was called in a certain way) or because you've hit an error and the routine "broke".

Hope that helps,

- Bryan Shumsky

Revelation Software

Hi All,

I'm also working on this issue with Paul. I have tried a variety of solutions and discovered some interesting behavior.

The procedure we are dealing with is called INET_BPE_LOOKUP. It is designed to take in a parameter such as address or customer name and return the record for that customer.

1. When the webpage calls INET_BPE_LOOKUP through the script engine, it returns the "incomplete set of HTTP headers" message.

2. When I call INET_BPE_LOOKUP through a test program and pass it the exact same request string as the engine receives in scenario 1, it returns a complete webpage which I am able to write to disk from the test program and load using IE8.

3. When I insert a write_row statement at the end of INET_BPE_LOOKUP, and then call it from the website through the script engine (as in scenario 1), not only does it write out the same html code as found in Scenario 2, it also displays properly on the webpage! There is an extra additional line at the bottom which states: "SSP615: Row "RESULT" successfully written." This is the only difference between this HTML source code and the HTML source code from Scenario 1.

Clearly something is going on here with the way the script engine is handling the returned page, but it's not visible to me in the above scenarios. The program does not error out, has no debugs, and appears to be returning legitimate HTML code.

Any help would be appreciated.

Thanks,

Cully

Hi, Cully. Can you try putting "CALL SET_STATUS(0)" at the end of your INET routine? I believe what you may be seeing is some "out of band" output (from some call that you are making during your INET procedure) that is messing up your HTML output.

Please let us know if that makes a difference.

Thanks,

- Bryan Shumsky

Revelation Software

Thanks Bryan. I tried your suggestion, both with and without the write_row call which makes the page display. Unfortunately both scenarios return the HTTP Headers error page. Any other suggestions?

Thanks All,

Cully

Hi Cully,

My gut says that there is a status set somewhere, that Write_row

steps on it, and that putting call set_Status(0) earlier will take care of it.

However, other things to consider:

INET_FINALIZE will toy with the headers unless you have added your own.Could you be returning data that causes Inet_finalize to corrupt it?

Any UTF8 values in your data that would confuse an OI running in ANSI mode?

You might learn what the problem is using firebug or a tool like fiddler to view the headers that your browser receives.

- Bob

View this thread on the Works forum...