March 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-1053) UNICAST: set retransmission timeout based on actual retransmission times

by Bela Ban (JIRA)

UNICAST: set retransmission timeout based on actual retransmission times ------------------------------------------------------------------------ Key: JGRP-1053 URL: https://jira.jboss.org/jira/browse/JGRP-1053 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 UNICAST needs to compute a rolling average of retransmission times, per sender (AckSenderWindow). The retransmission timeout per sender can then be set based on the actual average retransmission times. The advantage is that we throttle retransmission when we have a lot of message loss, and speed it up again when there are no message drops. The function to set the timeout should always compute the new timeot value based on (1) the old value times a decay factor and (2) a new value. The average should go up relatively quickly if the actual retransmission values go up, but come down slowly when the actual values go down. A potential function is shown below: static final double SLOW_DECAY_FACTOR=0.9, FAST_DECAY_FACTOR=0.7; static final double FAST_UP= 1 / FAST_DECAY_FACTOR, SLOW_UP= 1 / SLOW_DECAY_FACTOR; static final double SAFETY_BUFFER=0.3; static double avg=200; public static void main(String[] args) { final long[] times={200,200,400,400,500,500,500,500,500,100,100,100,100,100,100,100,100,100,100,100,100,100}; // final long[] times={200,200,200,200,200,200,200,200,200,200,200}; for(Long val: times) { double result=avg(val); System.out.println(val + ": " + result); } } private static double avg(long val) { double decay, up; if(val > avg) { decay=FAST_DECAY_FACTOR; up=FAST_UP; } else { decay=SLOW_DECAY_FACTOR; up=SLOW_UP; } double old_val=avg * decay; double result=(old_val + val * up) / 2; avg=result; return result * (1 + SAFETY_BUFFER); } -- 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

13 years, 8 months

2
6
0 / 0

[JBoss JIRA] Created: (JGRP-1054) NAKACK: retransmission timeouts based on actual retransmission values

by Bela Ban (JIRA)

NAKACK: retransmission timeouts based on actual retransmission values --------------------------------------------------------------------- Key: JGRP-1054 URL: https://jira.jboss.org/jira/browse/JGRP-1054 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 Currently, timeouts in NAKACK are static, e.g. 300,600,1200. The goal is to make the retransmission timeouts a function of the actual average retransmission times. Ideally, we maintain rolling averages of actual retransmission times per sender and adjust the retransmit timeout based on these values. This would dynamically slow down retransmission on heavy traffic/congetion/message loss etc, and speed it up when those problems disappear again -- 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

13 years, 8 months

2
6
0 / 0

[JBoss JIRA] Created: (JGRP-592) Pluggable policy for picking coordinator

by Bela Ban (JIRA)

Pluggable policy for picking coordinator ---------------------------------------- Key: JGRP-592 URL: http://jira.jboss.com/jira/browse/JGRP-592 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.6 Make policy to pick coordinator pluggable. Pick new coordinator after existing coordinator crashes by calling this policy. Default policy is to pick the next in line. Other policies could pick the next in line from a set of pinned coordinator, so certain members can never become coordinators. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

4
7
0 / 0

[JBoss JIRA] Created: (JBAS-8517) Add support for two phase bundle deployments

by Thomas Diesler (JIRA)

Add support for two phase bundle deployments -------------------------------------------- Key: JBAS-8517 URL: https://jira.jboss.org/browse/JBAS-8517 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: OSGi integration Reporter: Thomas Diesler Fix For: 7.0.0.M1 In one deploy cycle, bundles must first get installed and then started. It generally needs to be discussed how multiple phase deployments should be handled. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

5
24
0 / 0

[JBoss JIRA] Created: (JBRULES-2700) Allow setting globals for access by the scoring rules

by Wouter Horré (JIRA)

Allow setting globals for access by the scoring rules ----------------------------------------------------- Key: JBRULES-2700 URL: https://jira.jboss.org/browse/JBRULES-2700 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-planner Reporter: Wouter Horré Assignee: Mark Proctor Currently, it is not possible to set a global variable in the working memory used by the solver. If a scoring rule needs an external helper for calculating scores (e.g. a dependency injected with OSGi DS), a workaround using a static variable in some class accessible by the scoring rules is needed. The easiest implementation is probably a new method in the Solver interface: public WorkingMemory getWorkingMemory(); which provides access to the working memory used by the solver. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
17
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2035) Upport JBPAPP-2811: EJB3 timer service doesn't retry on rollback

by Carlo de Wolf (JIRA)

Upport JBPAPP-2811: EJB3 timer service doesn't retry on rollback ---------------------------------------------------------------- Key: EJBTHREE-2035 URL: https://jira.jboss.org/jira/browse/EJBTHREE-2035 Project: EJB 3.0 Issue Type: Sub-task Reporter: Carlo de Wolf Assignee: Carlo de Wolf -- 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

13 years, 8 months

2
5
0 / 0

[JBoss JIRA] Created: (JBJCA-262) new validation warning - class are packaged inside RAR instead of JAR

by Jeff Zhang (JIRA)

new validation warning - class are packaged inside RAR instead of JAR --------------------------------------------------------------------- Key: JBJCA-262 URL: https://jira.jboss.org/jira/browse/JBJCA-262 Project: JBoss JCA Issue Type: Sub-task Components: Deployer Reporter: Jeff Zhang Assignee: Jeff Zhang -- 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

13 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JGRP-495) Memory leak in NAKACK

by Bela Ban (JIRA)

Memory leak in NAKACK --------------------- Key: JGRP-495 URL: http://jira.jboss.com/jira/browse/JGRP-495 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assigned To: Bela Ban Priority: Blocker Fix For: 2.5 Probably due to the changes introduced in NAKACK/NakReceiverWindow (http://jira.jboss.com/jira/browse/JGRP-281). To reproduce, run perf.Test on 2 nodes with 1 million 1K messages each. JProfiler shows that we are leaking Map.Entry instances in NAKACK. They seem to accumulate in xmit_table. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2301) Get rid of System.out.println statement

by Juraj Tomasov (JIRA)

Get rid of System.out.println statement --------------------------------------- Key: JBRULES-2301 URL: https://jira.jboss.org/jira/browse/JBRULES-2301 Project: Drools Issue Type: Quality Risk Security Level: Public (Everyone can see) Components: All Affects Versions: 5.1.0.M1 Reporter: Juraj Tomasov Assignee: Mark Proctor Priority: Minor System.out.println statement is currently used in 280 project files. I propose to replace them with logger. -- 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

13 years, 8 months

9
18
0 / 0

[JBoss JIRA] Created: (JGRP-364) When using TCP_NIO, starting two nodes at the same time causes one of the nodes not to join group

by Matthew Todd (JIRA)

When using TCP_NIO, starting two nodes at the same time causes one of the nodes not to join group ------------------------------------------------------------------------------------------------- Key: JGRP-364 URL: http://jira.jboss.com/jira/browse/JGRP-364 Project: JGroups Issue Type: Bug Affects Versions: 2.4 Environment: linux 2.6 kernel x86_64 running java 1.5.0_06 Reporter: Matthew Todd Assigned To: Bela Ban I am testing a jgroups tcp_nio configuration using the draw demo.If I start up my 3 nodes one by one then everything works fine. However if I start up node 1, then attempt to start node 2 and 3 in parallel then only node 2 will work. Node 3 will be isolated and not see the other nodes and logs the following message: org.jgroups.protocols.pbcast.ClientGmsImpl join WARNING: join(192.158.70.200:7802) sent to 192.158.70.200:7800 timed out, retrying I am starting the draw demo like this; java -cp jgroups-all.jar:commons-logging.jar:concurrent.jar:jmxri.jar org.jgroups.demos.Draw -props test.xml Here is the configuration for one of my nodes: <config> <TCP_NIO bind_addr="192.158.70.200" recv_buf_size="20000000" send_buf_size="640000" loopback="false" discard_incompatible_packets="true" max_bundle_size="64000" max_bundle_timeout="30" use_incoming_packet_handler="true" use_outgoing_packet_handler="true" down_thread="false" up_thread="false" enable_bundling="true" start_port="7800" end_port="7800" use_send_queues="false" sock_conn_timeout="300" skip_suspected_members="true" /> <MPING timeout="2000" num_initial_members="3" mcast_addr="229.6.7.8" bind_addr="192.158.70.200" down_thread="false" up_thread="false"/> <MERGE2 max_interval="100000" down_thread="false" up_thread="false" min_interval="20000"/> <FD_SOCK down_thread="false" up_thread="false"/> <VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/> <pbcast.NAKACK max_xmit_size="60000" use_mcast_xmit="false" gc_lag="0" retransmit_timeout="300,600,1200,2400,4800" down_thread="true" up_thread="true" discard_delivered_msgs="true"/> <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" down_thread="false" up_thread="false" max_bytes="400000"/> <pbcast.GMS print_local_addr="true" join_timeout="3000" down_thread="true" up_thread="true" join_retry_timeout="2000" shun="true" view_bundling="true"/>  <pbcast.STATE_TRANSFER/>  </config> Node 2 and 3 have the same configuration except the port they bind to has been changed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

5
16
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 2011