June 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-394) Performance enhancements

by Bela Ban (JIRA)

Performance enhancements ------------------------ Key: JGRP-394 URL: http://jira.jboss.com/jira/browse/JGRP-394 Project: JGroups Issue Type: Task Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 - NAKACK.handleMessage(): NakReceiver.add() --> Retransmitter.add() --> TimeScheduler.add() is quite costly; we also iterate through a linear list when removing a message from the Retransmitter ! -- 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

18 years, 11 months

2
7
0 / 0

[JBoss JIRA] Created: (JGRP-281) Investigate whether sent messages need to be buffered in NAKACK

by Bela Ban (JIRA)

Investigate whether sent messages need to be buffered in NAKACK --------------------------------------------------------------- Key: JGRP-281 URL: http://jira.jboss.com/jira/browse/JGRP-281 Project: JGroups Issue Type: Task Affects Versions: 2.3 SP1, 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 NAKACK buffers sent messages in sent-table and received messages in received-table. We might be able to discard sent-table entirely because received-table will contain a message sent by oneself ! Once we have loopback in place by default, we can be sure that any message sent by P will be in P's received-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

18 years, 11 months

2
10
0 / 0

[JBoss JIRA] Created: (JGRP-461) Add highest_deliverable to NakreceiverWindow

by Bela Ban (JIRA)

Add highest_deliverable to NakreceiverWindow -------------------------------------------- Key: JGRP-461 URL: http://jira.jboss.com/jira/browse/JGRP-461 Project: JGroups Issue Type: Sub-task Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 Currently, we use highest_delivered (= removed) seqno, highest_deliverable would purge more messages faster, if we have a slow receiver (slow to call receive()) -- 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

18 years, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-487) Rewrite Retransmitter

by Bela Ban (JIRA)

Rewrite Retransmitter --------------------- Key: JGRP-487 URL: http://jira.jboss.com/jira/browse/JGRP-487 Project: JGroups Issue Type: Task Affects Versions: 2.5 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6 Attachments: Retransmitter.java The old Retransmitter is (a) too complex and (b) uses a linear list of Entries as retransmission list, which has a cost proportional to the number of messages in the retransmit buffer. We should switch to using simple scheduled futures with the TimeScheduler for retransmissions and cancel the futures when a message has been acked. The new Retransmitter.java is attached -- 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

18 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-462) NAKACK: remove bundling for retransmitted messages

by Bela Ban (JIRA)

NAKACK: remove bundling for retransmitted messages -------------------------------------------------- Key: JGRP-462 URL: http://jira.jboss.com/jira/browse/JGRP-462 Project: JGroups Issue Type: Task Affects Versions: 2.4.1 SP1 Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.5 In NAKACK, all retransmitted messages are sent in batches (governed by max_xmit_size). This is redundant, as TP also provides bundling. A quick change of code showed that individual retransmissions is as fast as batched retransmission. This functionality can therefore be removed -- 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

18 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-510) NAKACK: adjust retransmission times based on statistics

by Bela Ban (JIRA)

NAKACK: adjust retransmission times based on statistics ------------------------------------------------------- Key: JGRP-510 URL: http://jira.jboss.com/jira/browse/JGRP-510 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.6 NAKACK can maintain a rolling average of the time it takes for a missing message to get retransmitted (time between sending the XMIT-REQ and reception of the missing message). This can be done per sender. The retransmit_timeout values can be based on the rolling average, e.g. make this completely dynamic: instead of a set of retransmit timeouts we only define a retransmit_timeout, e.g. 30ms. If a message is not able to get retransmitted the first time, we simply double that value (exponential backoff), until a max limit is reached. When we discover that the rolling timeout is less than 30ms (e.g. 4ms), then we lower the retransmission timeout, e.g. to 4 ms (plus possibly a safety time, say 2ms), to a total of 6ms. This will make message retransmission faster, since we don't have to wait for 30ms to ask for retransmission. OTOH, if the rolling average increases, we can also increase our retransmission timeout, to avoid overloading the network with spurious retransmission requests. RESULT: message retransmission is more dynamic: - Retransmit timeout is *per sender* - On low retransmission ack times, we ask for retransmission sooner, therefore increasing message rates - On high retransmission ack times, we throttle retransmission timeouts (and use exponential backoff), therefore reducing traffic -- 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

18 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (JBRULES-678) Remove spring dependency

by Geoffrey De Smet (JIRA)

Remove spring dependency ------------------------ Key: JBRULES-678 URL: http://jira.jboss.com/jira/browse/JBRULES-678 Project: JBoss Rules Issue Type: Task Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Once the configuration xml is extracted this should be a peice of cake -- 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

18 years, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (JBRULES-642) Extract solver configuration

by Geoffrey De Smet (JIRA)

Extract solver configuration ---------------------------- Key: JBRULES-642 URL: http://jira.jboss.com/jira/browse/JBRULES-642 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Mark Proctor Priority: Critical Preferable into an xml file. Should help to make the integration tests easier to do. -- 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

18 years, 11 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-4422) org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host

by Richard Achmatowicz (JIRA)

org.jboss.test.util.test.TwiddleUnitTestCase can't connect to host ------------------------------------------------------------------ Key: JBAS-4422 URL: http://jira.jboss.com/jira/browse/JBAS-4422 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Affects Versions: JBossAS-4.2.0.CR2 Environment: x86, Windows 2003 , Sun and BEA JVM Reporter: Richard Achmatowicz Priority: Trivial 1. The test testGet() in org.jboss.test.util.test.TwideleUnitTestCase builds a twiddle command line, execs the command line and checks that the output received from the server macthes the expected output. Comamnd lines are built, based on OS type: there is one for Windows and one for UNIX. The command line built when executing on Windows is: > cmd /C twiddle get "jboss.system:type=Server" "Started" and the response should be "Started=true" It appears that twiddle had an option for specifying the server host, but this option has been commented out. When executing the test on Windows, twiddle tries by default to connect to the server using localhost:1099. 2. When the testsuite is run using the parameters node0/node1 to specify the host IP addresses, localhost:1099 is not available and the test fails. (please see the linked issue JBPAPP-176 for more details) -- 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

18 years, 11 months

3
6
0 / 0

[JBoss JIRA] Created: (JGRP-491) Multiplexer should execute getState for all registered MuxChannel under one FLUSH phase

by Vladimir Blagojevic (JIRA)

Multiplexer should execute getState for all registered MuxChannel under one FLUSH phase --------------------------------------------------------------------------------------- Key: JGRP-491 URL: http://jira.jboss.com/jira/browse/JGRP-491 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1, 2.5 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Fix For: 2.6 The idea behind MuxChannel state transfer listeners is to trigger all state transfers together and have all or none result for all registered MuxChannels. As currently implemented underlying plumbing with will trigger each transfer under *separate* FLUSH. In order to have it done under one flush we have to do manual flushing in Multiplexer (startFlush/stopFlush) for these transfers T and we should retrofit FLUSH protocol *not to* trigger flushing for each GET_STATE from T. We have two options: a) add requireFlush field in StateTransferInfo - that is then passed down with GET_STATE - this requires changing signature of JChannel.getState b) retrofit FLUSH to detect special handling of GET_STATE - at state requester A we record that we requested GET_STATE and if another GET_STATE arrives from A while channel is already flushed do not trigger another flush -- 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

18 years, 11 months

1
1
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 June 2007