March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1173) Discovery protocol based on jclouds

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1173?page=com.atlassian.jira.plugin.... ] Bela Ban deleted JGRP-1173: --------------------------- > Discovery protocol based on jclouds > ----------------------------------- > > Key: JGRP-1173 > URL: https://issues.jboss.org/browse/JGRP-1173 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > > Write a discovery protocol based on jclouds (jclouds.org). This allows us to support more than just EC3 (S3_PING). This protocol cannot live in JGroups, however, as I don't want to add a JAR dependency. > Contact the jclouds folks to see if they want this (dep on JGroups) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-872) TP: cluster name is shipped with each message

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-872?page=com.atlassian.jira.plugin.s... ] Bela Ban resolved JGRP-872. --------------------------- Resolution: Won't Fix > TP: cluster name is shipped with each message > --------------------------------------------- > > Key: JGRP-872 > URL: https://issues.jboss.org/browse/JGRP-872 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > > If a cluster name (the name used in Channel.conect()) is long, because we ship it with each message (in the TP header), this blows up the size of the marshalled messages. > Maybe we can canonicalize the cluster name shipped with each message, similar to what we want to do with Addresses, e.g. replace the cluster name with a short. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2) Memory based flow control

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2?page=com.atlassian.jira.plugin.sys... ] Bela Ban deleted JGRP-2: ------------------------ > Memory based flow control > ------------------------- > > Key: JGRP-2 > URL: https://issues.jboss.org/browse/JGRP-2 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Memory and retransmission based flow control protocol. Should be much faster than the current FC > on a fast network, we can still run out of memory because received_msgs/delivered_msgs becomes very big. > Instead of basing FC on the speed of the network, we should also take the number of messages processed > (a.k.a delivered_msgs/received_msgs) into account, and only send credits when that number falls below a > certain threshold. First: look at the number of received/delivered msgs in the perf test ! > --> Look into memory-based FC: criteria for sending credits are > - available free memory > - outstanding retransmission requests (sender sends with each message number of messages sent, > receiver keeps track of how many messages received, if diff is > threshold --> pause) > - [optional] latency -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-872) TP: cluster name is shipped with each message

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-872?page=com.atlassian.jira.plugin.s... ] Bela Ban updated JGRP-872: -------------------------- Fix Version/s: 3.3 (was: Future) With the implementation of message batching [1], the cluster name is shipped only once per batch, so this issue is moot [1] https://issues.jboss.org/browse/JGRP-1564 > TP: cluster name is shipped with each message > --------------------------------------------- > > Key: JGRP-872 > URL: https://issues.jboss.org/browse/JGRP-872 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > > If a cluster name (the name used in Channel.conect()) is long, because we ship it with each message (in the TP header), this blows up the size of the marshalled messages. > Maybe we can canonicalize the cluster name shipped with each message, similar to what we want to do with Addresses, e.g. replace the cluster name with a short. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-903) Logical addresses: associate multiple physical addresses with one logical address

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-903?page=com.atlassian.jira.plugin.s... ] Bela Ban deleted JGRP-903: -------------------------- > Logical addresses: associate multiple physical addresses with one logical address > --------------------------------------------------------------------------------- > > Key: JGRP-903 > URL: https://issues.jboss.org/browse/JGRP-903 > Project: JGroups > Issue Type: Sub-task > Reporter: Bela Ban > Assignee: Bela Ban > > Currently this can be done via OS mechanisms, e.g. IP bonding on Linux, or via hardware, e.g. trunking with switches. Pushed into 3.x, may never be implemented -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-511) FC: dynamically adjust credits

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-511?page=com.atlassian.jira.plugin.s... ] Bela Ban deleted JGRP-511: -------------------------- > FC: dynamically adjust credits > ------------------------------ > > Key: JGRP-511 > URL: https://issues.jboss.org/browse/JGRP-511 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > > FC currently has a static number of credits (max_credits). It would be beneficial to implement something similar to TCP's exponential backoff and slow start, to take the message loss rate into account. > Goal: when there is an overload, we reduce the credits in order to avoid compounding the overload by sending messages. On the other hand, we can send more messages when the receiver(s) have free capacity. To do this, each receiver sends the number of credits it can accept with its responses. By default, this would be the default number of credits (in TCP: size of the sliding window). > DESIGN: > NAKACK (and/or UNICAST) send the loss rate (rolling average of number of messages missing over number of messages received, per sender) when it exceeds a certain value (defined in NAKACK,UNICAST) up the stack. > FC looks at the loss rate and slices the number of credits for that sender in half (exponential backoff). On the next response, it piggy backs the new number of credits, so that sender will block sending messages. > When the loss rate drops below a certain (predefined) value, NAKACK sends another event up the stack. FC then increases the credits by a predefined value (slow start). Next time, it increases the value by the predefined value by 2 and so on, until the max number of credits have been reached again. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-41) Hierarchical message dissemination

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-41?page=com.atlassian.jira.plugin.sy... ] Bela Ban deleted JGRP-41: ------------------------- > Hierarchical message dissemination > ---------------------------------- > > Key: JGRP-41 > URL: https://issues.jboss.org/browse/JGRP-41 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > > Scheme proposed by EPFL -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1142) Introduce compaibility testing into the JGroups testsuite

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1142?page=com.atlassian.jira.plugin.... ] Bela Ban deleted JGRP-1142: --------------------------- > Introduce compaibility testing into the JGroups testsuite > --------------------------------------------------------- > > Key: JGRP-1142 > URL: https://issues.jboss.org/browse/JGRP-1142 > Project: JGroups > Issue Type: Task > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > > The dgree to which JGroups versions interoperate is determined by their stated compatibility relationships. > The purpose of this issue is to: > (i) clarify the desired backward compatibility conditions in use for JGroups > (ii) devise tests which validate those relationships and incorporate them into the JGroups testsuite -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-376) Concurrent stack: use priority based queue rather than BoundedLinkedQueue for default thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-376?page=com.atlassian.jira.plugin.s... ] Bela Ban deleted JGRP-376: -------------------------- > Concurrent stack: use priority based queue rather than BoundedLinkedQueue for default thread pool > ------------------------------------------------------------------------------------------------- > > Key: JGRP-376 > URL: https://issues.jboss.org/browse/JGRP-376 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > > This will allow us to dispatch incoming messages to threads from the pool based on criteria. > - The impl implements interface BoundedChannel > - It has N queues, 1 for each sender (possibly those are BoundedLinkedQueues) > - There is a max size in bytes for the priority queue, each internal queue has max_size / N bytes where N = number of members. This is > dynamically adjusted > ADDITION > - An internal queue maintains the number of bytes (Message.length()), an offer() or put() increases that amount by the size of the message, a > take() or poll() decreases the amount. When a put() or offer() would exceed the max amount, it will block until a take() or poll() decreases > it such that the new message can be added to the queue. We might also discard messages to full queues, or implement somthing akin to > RED (random early detection), which starts discarding messages *before* the queue is full > REMOVAL > - Strategy pluggable, e.g. > - Take from the fullest queue > - Take from the least full queue > - Round robin > - Weighted round robin (weighted by capacity of each queue), e.g. take relative to capacity from each queue. Example: > Queues A (2MB), B (2MB), C (6MB): we take 2 from A, 2 from B and 6 from C > - Random robin > etc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1227) Discovery protocol based on GoGrid

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1227?page=com.atlassian.jira.plugin.... ] Bela Ban deleted JGRP-1227: --------------------------- > Discovery protocol based on GoGrid > ---------------------------------- > > Key: JGRP-1227 > URL: https://issues.jboss.org/browse/JGRP-1227 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > > Similar to S3_PING (Amazon), create a discovery protocol (extending FILE_PING) which uses GoGrid's distributed store -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 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 March 2013