missing connection response

[chengen]

Hello, Teresa,

We have the following code,

_es = new ElectroServer();
_es.loadAndConnect("settings.xml");
_es.engine.addEventListener(MessageType.Connection Response.name, onConnectionResponse);
...
waitpanel = new popup_wait_panel("connecting to server ...");
addChild(waitpanel);
....

private function onConnectionResponse(e:ConnectionResponse):void
{
if (waitpanel && waitpanel.stage) { removeChild(waitpanel) }
if (e.successful) {
...
}else {
waitpanel = new popup_wait_panel("Can not connect to server.");
addChild(waitpanel);
}
}

Usually user would see the "connecting to server ..." popup for a few seconds and see the next screen we display afterwards in the e.successful section. But some users would see the "connecting to server ..." popup and stay there. Usually this happens on their first try (which is going to be their only try if they don't get in) and if they refresh a few times, close browser and reopen, or just come back and try again later, they may get pass that "connecting to server ..." popup.
It sounds to me like they don't get the ConnectionResponse message on their first try. But with nothing changed, they may get it later after refresh or close browser or something.
Do you have any idea what is going on? Thanks.

Regards,
Jesse

[tcarr]

There are a number of things that might be causing this. Would you be interested in trying the ES5.3.2RC2 build? We've had some very positive results with it so far.

If not, then I will need to know the exact version of ES5 you are running, and whether you can reproduce this problem on your test server or only on production. Things to consider:

• What type of garbage collection is your JVM using?
• Is the user connecting using BinaryTCP or HTTP?
• Does the user have a noisy connection?

[chengen]

Teresa,

We are using ES5 version 5.3.1. I would like to know what is involved in changing to the new version. Do we need to change any coding or simply change the ES5 installation on the server?
I don't think we have any garbage collection. So whatever java uses. Our settings.xml file specifies BinaryTCP before HTTP, so I assume user would connect to BinaryTCP unless it doesn't connect. I do not know what kind of connection our users have (they are from different places).
I can not reproduce this problem myself because I can always connect. Some users told me they get blank screen or "connecting to server ..." popup screen. I can't see their screen because they are remote.

[chengen]

There is another problem I thought it was our own problem, but maybe related to this issue also? When a new user first logs on, his session is not getting certain plugin message. We have a server update event that server sends to all online users but the new user on his first session doesn't seem to get that event. If he disconnect and reconnect, usually he will get that server update event. I also noticed, if instead of close the browser window to disconnect and reconnect, the user simply logs on from a different window (thus disconnect the first window), his session still does not get the server update event. All these are only from a few testings so may not be 100% true, just my feeling of the problem. Could it be because somehow the server doesn't recognize the user as online? But the user's session does get other events the server generates, just not the server update event, which is not that different from other event I would say. So maybe it is still our own problem?

[tcarr]

It's a minor release so you should be able to just follow the "minor version" instructions:
http://www.electrotank.com/docs/es5/...r_upgrades.htm

The only thing that might require editing is if your application reads an XML file that was produced using EsObject.toXML with a different version. Just edit out any "_array" from the datatypes and it should work, unless you have bytes. Bytes and byte arrays had a larger change.

ES5.3.2RC2 is wire compatible with previous versions back to ES5.2.0, so you don't even have to recompile your client unless you want to take advantage of the bug fixes.

If you don't specify any garbage collection scheme for JVM, it's quite possible that your JVM (depending on which one you are using) is stopping ALL threads for a full second or two while it does garbage collection, then processing all the backed up requests and responses, which makes for very strange performance. If you install 5.3.2RC2, the new manual (which isn't up on the website yet) has this information in it:

For most JVMs, Java waits until it is low on memory, then stops all threads and runs the garbage collector. This behavior is not good for production servers of course. The best fix for this is to specify the GC settings that you want Java to use, and choose ones that run concurrently. This set works well for most projects:

-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode

If you start ES5 normally, these command line parameters can be set on the ES Admin's General Settings screen. If you start ES5 in SAFEMODE, then they will need to be added to the start script or to the JVM default options.

[tcarr]

There is another problem I thought it was our own problem, but maybe related to this issue also? When a new user first logs on, his session is not getting certain plugin message. We have a server update event that server sends to all online users but the new user on his first session doesn't seem to get that event. If he disconnect and reconnect, usually he will get that server update event. I also noticed, if instead of close the browser window to disconnect and reconnect, the user simply logs on from a different window (thus disconnect the first window), his session still does not get the server update event. All these are only from a few testings so may not be 100% true, just my feeling of the problem. Could it be because somehow the server doesn't recognize the user as online? But the user's session does get other events the server generates, just not the server update event, which is not that different from other event I would say. So maybe it is still our own problem?

When is the client adding a listener for plugin events? If it waits until after it gets the login response, it might just miss a plugin event that is sent from userDidLogin. If a plugin message is sent from executeLogin most of the time the user will not get it.

I suggest that you try upgrading to the RC2 release and see if that helps, and if it doesn't then we will explore this further.

[chengen]

Teresa,

Your answer reminded me that I am using the Electroserver5.swc from an earlier version of ES5 (maybe 5.1.x) with my flashdevelop project. I didn't even think about changing it when we moved to ES5.3.1. Should I get the Electroserver5.swc from the latest ES5 and recompile my client and switch to the latest ES5 on the server? Together with setting the garbage collection setting in the ES5 Admin console, do you think that may fix the strange problem of user get stuck at seeing "connecting to server ..." popup window? Also do you think our other problem might be solved by the ES5 upgrade?

Regards,
Jesse

[chengen]

BTW, we already have "-Detio.synchronousWrites=false" in our command-line parameters in ES5 admin console. How do we add the other garbage collection setting you mentioned? Separate with colon or something?

[chengen]

When is the client adding a listener for plugin events? If it waits until after it gets the login response, it might just miss a plugin event that is sent from userDidLogin. If a plugin message is sent from executeLogin most of the time the user will not get it.

I suggest that you try upgrading to the RC2 release and see if that helps, and if it doesn't then we will explore this further.

Didn't see this with my earlier replies. We have event listeners added at the very beginning of the code (together with the listener for connection response, where the ... was in my original post).
I will try the RC2 release and hopefully it will solve all our problems.

[tcarr]

BTW, we already have "-Detio.synchronousWrites=false" in our command-line parameters in ES5 admin console. How do we add the other garbage collection setting you mentioned? Separate with colon or something?

Just put them on separate lines in the same textarea.

If you update to ES5.3.2RC2 I would suggest that you use the swc for that. It's a lot easier for me to reproduce a problem that you are seeing if we are using the same version of the api, and if you report client side error messages, the line numbers won't mean anything if it's from an old version.