[jboss-jira] [JBoss JIRA] Commented: (JGRP-867) COMPRESS: cannot replace message buffer in-place

[Bela Ban (JIRA)]

    [ https://jira.jboss.org/jira/browse/JGRP-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12440279#action_12440279 ] 

Bela Ban commented on JGRP-867:
-------------------------------

Actually, it doesn't matter whether the message is our own or someone else's: whenever NAKACK.up() receives a message with a compressed payload, that message will be stored in the XMIT table. But when passed up to COMPRESS, the latter will uncompress the *same* message and *modify* its byte buffer.

> COMPRESS: cannot replace message buffer in-place
> ------------------------------------------------
>
>                 Key: JGRP-867
>                 URL: https://jira.jboss.org/jira/browse/JGRP-867
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.6.8, 2.7
>
>
> When we send a message, COMPRESS *replaces* the msg buffer with the compressed buffer. Say the message buffer has 105992 bytes, the compressed version now has 55000 bytes. The message with a buffer of 55'000 bytes is now stored in NAKACK for retransmission.
> However, when we receive our own multicast, we will receive the *same* message we sent and COMPRESS.up() will uncompress the buffer in-place to 105'922 bytes. This means that the message in NAKACK retransmit buffer will now be 105'992 bytes and thus fail if we use UDP because of the 65K max datagram size !
> Typical error msg:
> org.jgroups.protocols.UDP - failed sending message to null (105992 bytes)
> java.lang.Exception: message size (105992) is greater than max bundling size
> (61000). Set the fragmentation/bundle size
> in FRAG and TP correctly
>         at org.jgroups.protocols.TP$Bundler.checkLength(TP.java:1770)
>         at org.jgroups.protocols.TP$Bundler.send(TP.java:1665)
>         at org.jgroups.protocols.TP$Bundler.access$200(TP.java:1650)
>         at org.jgroups.protocols.TP.send(TP.java:1214)
>         at org.jgroups.protocols.TP.down(TP.java:988)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:351)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:176)
>         at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:364)
>         at org.jgroups.protocols.FD.down(FD.java:357)
>         at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:95)
>         at org.jgroups.protocols.pbcast.NAKACK.sendXmitRsp(NAKACK.java:984)
>         at org.jgroups.protocols.pbcast.NAKACK.handleXmitReq(NAKACK.java:922)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:682)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167)
>         at org.jgroups.protocols.FD.up(FD.java:322)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:300)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:145)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:246)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1535)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1484)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:619)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira