[JBoss JIRA] (JGRP-1745) Optimize in-memory object size
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1745?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1745:
---------------------------
Fix Version/s: 3.6.8
(was: 4.0)
Done for most important classes
> Optimize in-memory object size
> ------------------------------
>
> Key: JGRP-1745
> URL: https://issues.jboss.org/browse/JGRP-1745
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8
>
>
> Get the Java Object Layout tool from [1] and
> * Measure the size of objects which are frequently allocated in memory, e.g.
> ** Message
> ** Event
> ** Header subclasses (TpHeader, UNICAST3$Header, STABLE$Header, NakaAckHeader3)
> Try to remove fields which are not absolutely needed and / or can be moved into the superclass.
> E.g.: {{NakAckHeader2.sender}} might get removed: can't we determine the sender from the message ? (Maybe not, if sender is the original sender, not the sender of the message)
> [1] https://github.com/Sanne/java-object-layout
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1745) Optimize in-memory object size
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1745?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1745.
----------------------------
Resolution: Done
> Optimize in-memory object size
> ------------------------------
>
> Key: JGRP-1745
> URL: https://issues.jboss.org/browse/JGRP-1745
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8
>
>
> Get the Java Object Layout tool from [1] and
> * Measure the size of objects which are frequently allocated in memory, e.g.
> ** Message
> ** Event
> ** Header subclasses (TpHeader, UNICAST3$Header, STABLE$Header, NakaAckHeader3)
> Try to remove fields which are not absolutely needed and / or can be moved into the superclass.
> E.g.: {{NakAckHeader2.sender}} might get removed: can't we determine the sender from the message ? (Maybe not, if sender is the original sender, not the sender of the message)
> [1] https://github.com/Sanne/java-object-layout
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-718) Transport: limit number of bytes read
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-718?page=com.atlassian.jira.plugin.s... ]
Bela Ban updated JGRP-718:
--------------------------
Fix Version/s: 3.6.8
(was: Future)
We also send a cookie, plus the length, so unless both match, the mesage won't ever be read and will be discarded right away. If it does match, then an OOME will ensure, will causes the msg to be discarded as well, and the next message will be read (or the conn closed).
> Transport: limit number of bytes read
> -------------------------------------
>
> Key: JGRP-718
> URL: https://issues.jboss.org/browse/JGRP-718
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Vladimir Blagojevic
> Priority: Minor
> Fix For: 3.6.8
>
>
> In the transport, each message is prefixed with its length. If, on the receiver side, we receive garbage data (e.g. a random app connects to the same port), then JGroups tries to interpret the first 4 bytes as length, and this might be quite huge (1.6GB in one instance).
> If we know that our packets are never larger than 200'000 bytes, then we can set a flag discard_messages_larger_than="200000". If the flag is 0, no messages will be discarded.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-718) Transport: limit number of bytes read
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-718?page=com.atlassian.jira.plugin.s... ]
Bela Ban closed JGRP-718.
-------------------------
Resolution: Cannot Reproduce
> Transport: limit number of bytes read
> -------------------------------------
>
> Key: JGRP-718
> URL: https://issues.jboss.org/browse/JGRP-718
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Vladimir Blagojevic
> Priority: Minor
> Fix For: 3.6.8
>
>
> In the transport, each message is prefixed with its length. If, on the receiver side, we receive garbage data (e.g. a random app connects to the same port), then JGroups tries to interpret the first 4 bytes as length, and this might be quite huge (1.6GB in one instance).
> If we know that our packets are never larger than 200'000 bytes, then we can set a flag discard_messages_larger_than="200000". If the flag is 0, no messages will be discarded.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months