Archived
This forum has been archived. Please start a new discussion on GitHub.
Bug with Compression Flag
in Bug Reports
Client (C #) establishes a bidirectional connection with the "-z" option but the client does not have bzip2.dll
Requests from client to server and responses are sent uncompressed with the flag "Uncompressed, sender cannot accept a compressed reply (0)",
but callbacks are always sent compressed with the flag "Compressed, sender can accept a compressed reply (2)" that causes an abnormal client disconnect.
Requests from client to server and responses are sent uncompressed with the flag "Uncompressed, sender cannot accept a compressed reply (0)",
but callbacks are always sent compressed with the flag "Compressed, sender can accept a compressed reply (2)" that causes an abnormal client disconnect.
0
Comments
-
Thanks for the bug report, and welcome to the forum.
I've tried to reproduce it a couple of different ways without success. With any bug report, we always ask that you describe the Ice version, compiler/VM version, languages being used, and OS version. Please also provide as much detail as possible about how to reproduce the problem - a small but complete code example would be best.
Regards,
Mark0 -
After further consideration, I'm guessing that the server in your scenario is forcing the use of compression, either by calling ice_compress(true) on the callback proxy, or by setting a property such as Ice.Override.Compress=1. Either of these configurations would result in the error you described. The question is whether this should be considered a bug in Ice or a bug in the application.
Mark0 -
Ice version 3.5.1.
Application is modified demos\demo\Ice\bidir.
Server runs in Fedora-19 (x86-64).
Client runs in windows 7-64.
See attachments.
Perhaps this is not a bug. This is my misunderstanding.0 -
Thanks for the information. The server enables compression by default with this configuration setting:
Callback.Server.Endpoints=tcp -p 10000 -z
Including the -z option means all proxies created by the object adapter will use compression by default for this endpoint, and this includes so-called "fixed" proxies created for bidirectional connections.
At present there is no way for a server to discover the compression status of a request. If there was such a way, the server could use that information to decide whether to enable compression for a bidirectional callback proxy. We'll consider adding this in a future release.
Meanwhile, you've got a few options:- Remove the -z option from the OA endpoint and have the client pass an additional argument to the server indicating whether it should use compression for callback requests
- Add an additional endpoint to the OA that does not use the -z option, and change your client (via configuration or code) to use the appropriate endpoint
Regards,
Mark0