January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1709) Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1709: --------------------------- Fix Version/s: 3.6.8 (was: 4.0) Done, by Romain > Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles > ------------------------------------------------------------------------------------------- > > Key: JGRP-1709 > URL: https://issues.jboss.org/browse/JGRP-1709 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.8 > > > Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages. > Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1709) Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1709. ---------------------------- Resolution: Done > Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles > ------------------------------------------------------------------------------------------- > > Key: JGRP-1709 > URL: https://issues.jboss.org/browse/JGRP-1709 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.8 > > > Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages. > Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (JGRP-705) Unicast JGroups

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-705?page=com.atlassian.jira.plugin.s... ] Bela Ban updated JGRP-705: -------------------------- Fix Version/s: 3.6.8 (was: Future) Buried > Unicast JGroups > --------------- > > Key: JGRP-705 > URL: https://issues.jboss.org/browse/JGRP-705 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.8 > > > Investigate use of JGroups for point-to-point communication, as a replacement for java.net{Server}Socket. > E.g. > Channelch=new JChannel(); > ch.connect(null); // null means p2p -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-705) Unicast JGroups

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-705?page=com.atlassian.jira.plugin.s... ] Bela Ban closed JGRP-705. ------------------------- Resolution: Won't Do > Unicast JGroups > --------------- > > Key: JGRP-705 > URL: https://issues.jboss.org/browse/JGRP-705 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.8 > > > Investigate use of JGroups for point-to-point communication, as a replacement for java.net{Server}Socket. > E.g. > Channelch=new JChannel(); > ch.connect(null); // null means p2p -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-763) UnicastChannelTest broken

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-763?page=com.atlassian.jira.plugin.s... ] Bela Ban closed JGRP-763. ------------------------- Resolution: Out of Date > UnicastChannelTest broken > ------------------------- > > Key: JGRP-763 > URL: https://issues.jboss.org/browse/JGRP-763 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.8 > > > Caused by moving the starting of threads into handleConnect() (in UDP), however, a unicast channel doesn't send down a CONNECT event. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-763) UnicastChannelTest broken

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-763?page=com.atlassian.jira.plugin.s... ] Bela Ban updated JGRP-763: -------------------------- Fix Version/s: 3.6.8 (was: Future) Won't do unicast JGroups > UnicastChannelTest broken > ------------------------- > > Key: JGRP-763 > URL: https://issues.jboss.org/browse/JGRP-763 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.8 > > > Caused by moving the starting of threads into handleConnect() (in UDP), however, a unicast channel doesn't send down a CONNECT event. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016