[MQ-155] Direct Broker does not implement message compression Created:
03/Mar/12 Updated: 26/Mar/13 Resolved: 16/May/12
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Closed
mq
mq-ra
4.5
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Environment:
Bug
gfuser9999
Fixed
None
Not Specified
Issue Links:
Related
is related GLASSFISHto
18436
5.0
Priority:
Assignee:
Votes:
Major
cgdrake
1
Not Specified
Not Specified
Any OS
GlassFish (all versions) with EMBEDDED broker
Unable to send compressed JMS
message...
Description
The message queue broker for the Direct* protocol
that is used with am embedded broker
does not handle JMS_SUN_COMPRESS property
and hence fails to decompress/work
with messages that are sent from an external JMS
client (that is not direct). This will cause failure
to read the messages in the clients in the embedded broker.
----------Tetscase
----------This is the same as http://java.net/jira/browse/GLASSFISH-18436
Testcase in there.
Resolved
------Cause:
------The JMS_SUN_COMPRESS checking is not done in the Direct
protocol. It seems that the messages are compress/decompress
in the jmsclient/MessageImpl implementation and
hence is not on the common machinery. ie: DirectPacket
have the Z_FLAG is true...
Since jmsclient MessageImpl is the one doing the
work. This would mean also that JMS_SUN_COMPRESS
for the outgoing case does not work.
------------Expected:
------------1. Glassfish embedded/direct can receive Compressed payload
2. Glassfish embedded direct can sent Compressed payload
to self/remote.
Comments
Comment by jthoennes [ 05/Mar/12 ]
Hello Nigel,
as we asked for a correction per Orace SR 3-5395017701:
Would it be possible to solve this for the next minor MQ release being compatible with GF
3.1.2?
My idea is to replace the MQ version (which one??) released as part of GF 3.1.2 with the
updated one.
Thanks, Jörg
Comment by gfuser9999 [ 08/Mar/12 ]
------------------------------------Extra:
----------------------------------

DirectSession/Producer is missing some compared to the
normal TCP jmsclient.
Do check as a whole that :a) Compression / Decompression (sent/recv) from embedded works
b) Check http://docs.oracle.com/cd/E19587-01/821-0029/gglft/index.html [XML
validation] as this is also done
by the TCP client (for Text XML messages) but not for direct
packet.
[This seems less used but then the same unimplemented
feature syndrome seen here]
Comment by Nigel Deakin [ 09/Mar/12 ]
Setting fix version as 5.0
Comment by Nigel Deakin [ 09/Mar/12 ]
@jthoennes: if you've logged this as a bug via Oracle support this will get handled by the
sustaining team who may provide a fix earlier than 5.0.
Comment by jthoennes [ 09/Mar/12 ]
In reply to comment #4:
> @jthoennes: if you've logged this as a bug via Oracle support this will get
> handled by the sustaining team who may provide a fix earlier than 5.0.
Hello Nigel,
yes, we filed SR 3-5395017701 : Unable to send compressed JMS message from client to
Glassfish to request a solution
for this issue. Do you think it will be get part of the next MQ 4.5.3 release. I am not sure about
the schedules since even
MQ 4.5.2 is not complete according to the JIRA repository.
Are there any planning pages with up-to-date infos?
Cheers, Jörg
Comment by Ed Bratt [ 09/Mar/12 ]
http://download.java.net/mq/open-mq/4.5.2/latest/
The repository reflects the final build. There were only two builds for this update.
Comment by jthoennes [ 15/May/12 ]
Hello,
Bug 13808159 : MQ:4.5.2-DIRECT BROKER DOES NOT IMPLEMENT MESSAGE
COMPRESSION
has now a FVB which has been successfully tested by us.
When will this bug update accordingly?
Thanks, Jörg
Comment by jthoennes [ 19/May/12 ]
Hello,
will this be available for version 4.6, too?
Thanks, Jörg
Comment by jthoennes [ 06/Jul/12 ]
According to
http://java.net/projects/glassfish/lists/users/archive/2012-07/message/16
there will be a micro release 3.1.3 of Glassfish soon.
Will this patch be included in this release?
Thanks, Jörg
Comment by saradak [ 26/Mar/13 ]
verified.
Generated at Wed Feb 10 06:12:18 UTC 2016 using JIRA 6.2.3#6260sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.