[jboss-jira] [JBoss JIRA] Updated: (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:all-tabpanel ]

Bela Ban updated JGRP-867:
--------------------------

    Workaround Description: Move COMPRESS under NAKACK
                Workaround: [Workaround Exists]


> 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