7.5 Communication Error
7.5 Communication Error
Unfortunately, this message was used for more than its intended purpose and became the generic message for
all communication issues with the server. There are a number of different reasons this message can be
displayed and in some cases there is a possibility the user hasnt lost any data (And really the only loss of data
are changes made in the browser that did not make it to the server).
Page 1 of 8
Page 2 of 8
can be sent to the browser at relatively the same time. Given the nature of TCP, there is no
guarantee that the request to validate field A makes it to the server before the request to validate B.
To insure that the requests are handled by the Tpae in the same order they are sent from the browser,
each request has a sequence number that the framework uses to maintain proper order in handling
requests. Lets say the update request for field A has a sequence number of 1 and field Bs request
has a sequence of 2. Lets also say for some unlikely (but possible) reason, Bs request makes it to
the server first. The Tpae framework will be expecting a request with sequence of 1, so it will
park Bs request and wait for As request. Once As request reaches the server, it is handled and it
Bs request is queued to be handled next. Now what happens if As request never makes it to the
server? Thats where the communication error comes in. The framework cant wait forever for
earlier sequenced events and will eventually timeout and send the communication error. When this
happens, the changes made to field A and B will be lost along with any other updates made after
modifying field A.
The important number in that message is OutOfOrderPageSeqNum: -1. It most likely was caused by the user
having multiple tabs open sharing the same state.
Page 3 of 8
Now youll notice the error code listed under the message. This is the error code returned by the browser and
can be different per browser. For instance on FireFox a code of 0 means it could not connect to the
network/internet. For IE the Error code will be 12029. For IE any error code in the 12000s typically means
there was some issue with the connection to the server and/or network. List of IE status codes can be found
here: http://msdn.microsoft.com/en-us/library/aa383770%28VS.85%29.aspx
If the browser can connect to the internet/network but for some reason the server rejected the request, the error
code will be an Http status code in the 400s. For example an error code of 404 is a page not found error.
Page 4 of 8
Seeing an error code in the 400s should be rare in Tpae, but possible. For more information on Http Status
codes see: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
If an unexpected error occurred on the server, the user will see this message:
In most cases the error code should be 500 which means there was an internal server error. If users see this
message they should note the time the error occurred and what they were doing at the time. There should be an
error in the logs that needs to be investigated.
In the above cases there is little Tpae can do to prevent the message from being displayed, but in the case of a
user having multiple tabs open sharing the same state, there are a couple of changes made to mitigate the
problems caused by this.
In the scenario where a user has a bookmarked URL with the uisession id parameter, the new property
mxe.webclient.allowURLDefinedUISessionID was added to prevent that. If disabled (set to 0) this property
will ignore the uisessionid parameter when creating a new session state object. By default this property is
enabled (even if the property doesnt exist, its considered enabled). Typically disabling this property should
not have any negative impact except in the case where you have some automated process that connects to Tpae.
For example: automated testing. If the test scripts are written to use a URL with a specific uisessionid, running
your test scripts will break, but in a production environment you shouldnt have such problems.
In the case where the user opens another tab or window with the File > New Window or File >
Duplicate Tab or copies the url to another tab/window there isnt anything Tpae can do to prevent it but it will
now notify the user that this occurred and will prevent the state of both windows/tabs from being corrupted.
Once the second window/tab is opened it has taken over the state from the first window. If the user goes back
to the first window, instead of getting the Comm error when they use the application, they will be redirected to
the Tape exit page and presented with this message:
Page 5 of 8
The user is not logged out and since this windows state has been taken of by the other window/tab they will not
lose any changes (except the ones they tried to make when they went back to the first window). Clicking on the
Return button will send the user back into Tpae (they will not need to log in) on the Start Center and the user
will now have two windows open with different states.
One important note about the three new messages: The messages were added to interim/hotfix patches for
7.5.0.1, 7.5.0.2, and 7.5.0.3 but in English only. Typically messages are not included in interim/hotfix patches
because they are not translated but given that the Comm Error can be shown for multiple reasons, it was
determined it was best to deliver the new messages to help diagnose the cause.
In this case the log shows the act of saving in the metergrp application took just over 60 seconds to complete. If
this is seen repeatedly, then the save action in the metergrp app should be investigated as to why its taking so
long.
To the user, they will not know that this has happened. To them the action just takes a long time.
Page 6 of 8
There is an Http Server configuration change that can also prevent this from happening. Setting the Http
Servers ServerIOTimeout to a larger number than the default. Basically this setting is the number of seconds
the Http Server will wait for a response from the Application server before resending the request. For more
information on this setting and how to change it go to:
http://www-01.ibm.com/support/docview.wss?uid=swg21318463.
Note: There is still the possibility that the fix for APAR IV31643 will not prevent an error. If the original
request takes too long to complete that the Http Server times out the repeated request (since it is waiting
for the original request to finish), then the Http Server will error and return a 500 http status to the
browser. In this case the user will see the unknown error message mentioned earlier. One way to
prevent this is to increase the ServerIOTimeout plugin property. Increasing it to 120 or 180 should
hopefully help until the investigation into why the action/event is taking so long is completed.
What is the SRTServletRequest parseParameters SRVE0133E exception and how to prevent it?
As mentioned above one of the causes of the communication problem is the unexpected exception:
com.ibm.ws.webcontainer.srt.SRTServletRequest parseParameters SRVE0133E: An error occurred while parsing parameters. {0}
java.net.SocketTimeoutException: Async operation timed out
at com.ibm.ws.tcp.channel.impl.AioTCPReadRequestContextImpl.processSyncReadRequest(AioTCPReadRequestContextImpl.java:189)
at com.ibm.ws.tcp.channel.impl.TCPReadRequestContextImpl.read(TCPReadRequestContextImpl.java:111)
at ........
Caused by: com.ibm.io.async.AsyncTimeoutException(Async operation timed out, [Timeout, rc=0])
at com.ibm.io.async.AbstractAsyncFuture.waitForCompletion(AbstractAsyncFuture.java:359)
at com.ibm.io.async.AsyncFuture.getByteCount(AsyncFuture.java:218)
at com.ibm.ws.tcp.channel.impl.AioSocketIOChannel.readAIOSync(AioSocketIOChannel.java:215)
at com.ibm.ws.tcp.channel.impl.AioTCPReadRequestContextImpl.processSyncReadRequest(AioTCPReadRequestContextImpl.java:182)
in the Tpae logs. It is believed this exception occurs as a result of an IE bug when it tries to resend a request
after an error occurs. Heres whats happening:
Browsers can have multiple connections open with a server. And by default servers can typically tell the
browser to keep the connection open for reuse, this is done to save the overhead of opening connections. These
connections have an inactivity/idle timeout on both the server and the browser. I believe IE's is 60 seconds
while the Http Server's is 5 to 20 seconds (this can be changed via configuration). As you are using a browser
there is the likelihood of multiple connections being open and at least one of those connections has a chance to
sit idle for as long or longer than the server's idle timeout (remember by default it is less than IE's). As a user is
using Tpae, IE can have multiple open connections to the server and it is possible for one (or more) of those
connections sit idle for approximately the server's idle timeout. When the connection "times out" on the server
and before the server can send the close connection acknowledgement to the browser, the browser uses that
connection to send a request. Instead of the expected acknowledgement from the server of receiving the
request, the server tells IE that the connection is closed, causing an error. The way IE handles such an error is
to try and send the request again with another connection. This is where the IE bug comes into play. When IE
resends the request, only the header information is sent and not the posted body, basically half the request is
sent), the server errors trying to read the parameters from the post body. (One thing to note: It's the parameters
in the posted body that tell Tpae what event is being sent from the browser, so without that info Tpae wouldn't
know what to do). Others have seen similar things with IE as evidenced by this Microsoft KB article:
Page 7 of 8
http://support.microsoft.com/kb/895954
Unfortunately enabling the IE hotfix mentioned in the article, does not fix the problem so we are left with
coming up with ways to work around until an IE solution becomes available. As of now there isnt a Tape
solution to this problem but it is something that Tpae development is currently investigating. In the mean
time there are a couple of things clients can do to prevent this error: The first is to use FireFox instead of IE.
So far there has not been any evidence that this error occurs with FireFox. The second involves a configuration
change to the Http Server.
As mentioned above the server can tell the browser to keep connections open for reuse. This is done by
the Connection keep-alive response header value. This can be disabled by setting the KeepAlive directive to off
in the HttpServers httpd.conf file. For more information on the KeepAlive directive here are a couple links:
http://www-01.ibm.com/software/webservers/httpservers/doc/v2047/manual/ibm/en_US/9atperf.htm#keepa
http://www-01.ibm.com/software/webservers/httpservers/doc/v2047/manual/mod/core.html#keepalive
IMPORTANT: It is not recommended that every client disable the KeepAlive directive. This can impact
performance for clients with high latency. If you see the SRVE0133E exception on a rare occasion, it may not
be worth the potential performance impact to prevent the error.
Page 8 of 8