Archived
This forum has been archived. Please start a new discussion on GitHub.
Compression issue with PHP client (TcpTransceiver.cpp:158: ConnectionLostException)
Hello,
I suppose there is a bug in php client resulting in message:
Investigation reveals that php client sometimes (it is very indeterministic) does not respect compression flag sent by server on validation message. There is a trace from one conversation that shows this:
PHP side:
Server side (Java):
In general, I can say that situation when validation message is sent twice is very often, but everything ends fine because php side turns off compression after second 'validation message'. Anyway there are cases when it does not.
To make situation clear, this happens when server (Java in our case) has no access to the apache bzip classes. By the way, it is very tricky that (for Java) ant.jar must be included in the classpath to make compression work. Couldn't commons-compress be used for example?
Ice version: 3.3.0
PHP version 5.2.6
I suppose there is a bug in php client resulting in message:
on php side.Uncaught Ice_UnknownLocalException TcpTransceiver.cpp:158: Ice::ConnectionLostException: connection lost: recv() returned zero
Investigation reveals that php client sometimes (it is very indeterministic) does not respect compression flag sent by server on validation message. There is a trace from one conversation that shows this:
PHP side:
[ 08/18/08 08:34:03.518 Protocol: received validate connection message type = 3 (validate connection) compression status = 0 (not compressed; do not compress response, if any) message size = 14 ] [ 08/18/08 08:34:03.518 Protocol: sending request message type = 0 (request) compression status = 2 (compressed; compress response, if any) message size = 115 request id = 1 identity = SessionFactory/sessionFactory facet = operation = ice_isA mode = 1 (nonmutating) context = ] [ 08/18/08 08:34:03.521 Protocol: received validate connection message type = 3 (validate connection) compression status = 0 (not compressed; do not compress response, if any) message size = 14 ] [ 08/18/08 08:34:03.522 Protocol: sending request message type = 0 (request) compression status = 2 (compressed; compress response, if any) message size = 115 request id = 1 identity = SessionFactory/sessionFactory facet = operation = ice_isA mode = 1 (nonmutating) context = ]
Server side (Java):
[ 18.08.08 08:31:59:349 Protocol: sending validate connection message type = 3 (validate connection) compression status = 0 (not compressed; do not compress response, if any) message size = 14 ] [ 18.08.08 08:31:59:349 Protocol: sending validate connection message type = 3 (validate connection) compression status = 0 (not compressed; do not compress response, if any) message size = 14 ]
In general, I can say that situation when validation message is sent twice is very often, but everything ends fine because php side turns off compression after second 'validation message'. Anyway there are cases when it does not.
To make situation clear, this happens when server (Java in our case) has no access to the apache bzip classes. By the way, it is very tricky that (for Java) ant.jar must be included in the classpath to make compression work. Couldn't commons-compress be used for example?
Ice version: 3.3.0
PHP version 5.2.6
0
