Hi,

We have a situation the a new is is starten with every call.

This happens only if we connect to UTFPortNumber.

In the commandline version we see this snippet:

looking for available engine, key is *SYSTEM☺1☺1☺ED☺☺HTTP_MCP☺☺1* have 7 available engines looking at engine #0 in lAvailable, its key is *SYSTEM☺1☺1☺ED☺☺HTTP_MCP☺☺0* looking at engine #1 in lAvailable, its key is *SYSTEM☺1☺1☺ED☺☺HTTP_MCP☺☺0* looking at engine #2 in lAvailable, its key is *SYSTEM☺1☺1☺ED☺☺HTTP_MCP☺☺0* looking at engine #3 in lAvailable, its key is *SYSTEM☺1☺1☺ED☺☺HTTP_MCP☺☺0* looking at engine #4 in lAvailable, its key is *SYSTEM☺1☺1☺ED☺☺HTTP_MCP☺☺0* looking at engine #5 in lAvailable, its key is *SYSTEM☺1☺1☺ED☺☺HTTP_MCP☺☺0* looking at engine #6 in lAvailable, its key is *SYSTEM☺1☺1☺ED☺☺HTTP_MCP☺☺0* Creating new engine

We think it has to do with the 8th value.

What can be the problem here

Regards Ed Keeman

Hi, Ed. Can you tell me a bit about how you have the engine server set up, and what your goal was? Are you trying to access data in UTF-8 applications (as defined in OpenInsight's Application Settings)? Is this for OpenInsight 8, 9, 10…?

Thanks,

- Bryan Shumsky

Revelation Software, Inc.

Hey Bryan,

Openinsight 9.4 not in UTF8

The engine runs as service, but for debugging we use commandline as well.

Our goal is to let a webserver communicate with OI throug UTFPortNumber because the webserver is UTF8.

At the moment the webserver communicates with PortNumber (not UTF8) and this works fine.

In order to get UTF8 chars in OI we need to communicte with UTFPortNumber.

Communicating works, but for every call a new engine is started.

The webserver uses java to connect to the Oengineservice.

On another site we use PHP to connect to the Oengineservice and that workks fine for UTFPortNumber.

We think that the problem is within the java code. Maybe you can tell by looking at the ids of the engines what the problem can be.

Regards

Ed Keeman

Hi, Ed. Sorry, I'm not seeing the issue (in the image you provided). When the Engine Server looks to see if there's an available engine it can re-use, it creates a "fingerprint" of the engine information so that it can make sure it only gives you the same exact engine as you need. The fingerprint code does something like this:

ourKey = application + "\001" + startupFlags + "\001" + shutdownFlags + "\001" + username + "\001" + password + "\001" + "" + "\001" + OILoc;

if (bUTF8) {

     ourKey += "\0011";

} else {

     ourKey += "\0010";

}

So, if you are asking for a UTF8 engine, the "fingerprint" will end with "1"; if you've got an ASCII engine, the "fingerprint" will end with a "0". What you are showing me says there are 7 engines running, but they are all ASCII engines; you are asking for a UTF8 engine here, so it needs to create a new one.

Or…is the problem that those other 7 engines are ALSO supposed to be UTF8 engines? And once the engine is created, it "forgets" that it's UTF8? I can't see that behavior in the image you posted, but maybe that's what you're describing?

Thanks,

- Bryan Shumsky

Revelation Software, Inc.

Yep,

The Engines are supposed to be UTF8.

For Logon, request and Logoff an engine gets created.

In effect for one call 3 engines are created

Oengineconfig:

IdleCheck=0 Application=SYSTEM EControlPassword=29HhPpiVHhDQ0t3YtutfiQCmg0ZZqBR1 MaxConnections=0 ShutdownFlags=1 StartupFlags=65 UserName=ED MaxRunTime=5 Server= StartupProc=OESTART MaxEngines=10 Password= PortNumber=8187 UTFPortNumber=8287 WebServerPortNumber=8887 IdleTimeout=1 MaxUpTime=0 Mode=-1

Ed Keeman

Hi, Ed. I'd like some clarification of what you're using to send in your request - let's take this offline, and you can send me the code snippet of what you're sending in to the engine server? Please send the details to info at revelation dot com, and I'll reply from there.

Thanks,

- Bryan Shumsky

Revelation Software, Inc.

Hi Bryan,

We made a copy of loglines from the commandline-engine.

We wanted to compare that with the loglines from another engine which runs correct on UTF8.

We noticed that the engines are running on different version. Oops

On revelation dot com we found a download for an update.

We updated the engine and everything runs well now.

Thank you and sorry we didn't see that earlier.

Ed Keeman

Ah ha, my favorite solution! I didn't have to fix anything

- Bryan Shumsky

Revelation Software, Inc.

Hope this is useful. Back in 2014 I created a simple O4W Mobile app that allowed the mobile user to switch to one of a number of offered Languages. This app is a questionnaire and it asked the same questions in the chosen language.

At the begin of the O4W commuter, which had only 'CREATE' and 'CLICK': If the chosen language was NOT ENU (English), then it always did a "call setUTF8( 1)". This was because at that time each connection had to tell the engine it was in UTF8 mode.

The end of the routine always did a "call setUFT8( 0)".

I never heard that there was some registry or .cfg setting for this.

Dave Harmacek - Harmacek Database Systems - near Boston, MA USA[google]Google search[/google]

Hi, Dave. Well, things have changed a _little_ since 2014

The engine server allows you to explicitly connect to a UTF8 engine - that's what the UTFPort parameter in the eserver.cfg specifies. When some "client" wants to talk to a UTF8 engine, it connects to the UTFPort as opposed to the normal engine server port, and it also has to pass in the "UTF8" flag in the connection parameters. If both those are set, then the engine server starts up the oengine and opens the application in utf8 mode. And, during the engine startup, we also ("belt and suspenders") call setUTF8 as well.

I'm not suggesting you change what you've been doing all these years - if it works, let's not break it - but I just wanted to clarify for you and anyone else, going forward.

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

View this thread on the Works forum...