December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JGRP-130) Problems with reincarnation

by r p (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-130?page=comments#action_12349128 ] r p commented on JGRP-130: -------------------------- As Bela points out we can easily reproduce this condition. Our ideal configuration (for a variety of reasons, esp. network configuration at our datacenters) is a know TCP port for group members. A FIX for this in 2.5 would be greatly appreciated. > Problems with reincarnation > --------------------------- > > Key: JGRP-130 > URL: http://jira.jboss.com/jira/browse/JGRP-130 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.9 > Reporter: Bela Ban > Assigned To: Bela Ban > Fix For: 2.6 > > > Problems with reincarnation > =========================== > Author: Bela Ban > Version: $Id$ > The identity of a JGroups member is always the IP address and a port. The port is usually chosen by the OS, unless > bind_port is set (not set by default). > Let's say a member's address is hostA:5000. When that member dies and is restarted, the OS will likely assign a > higher port, say 5002. This depends on how many other processes requested a port in between the start and restart > of the member. > JGroups relies on the fact that the assignment of ports by the OS is always (not necessarily monotonically) > *increasing* across a single machine. If this is not the case, then the following problems can occur: > 1. Restart: > When a member P crashes and then is restarted, if FD is used and P is restarted *before* it is excluded, > then we have a new member *under the same old address* ! Since it lost all of its state (e.g. retransmission table), > retransmission requests sent to the new P will fail. > 2. Shunning: > Regarding shunning: a member keeps its last N (default is 100) ports used, and makes sure it doesn't reuse one of > those already-used ports when it is shunned. However, this is process-wide and *not* machine-wide, e.g. when we have > processes P1 on A:5000 and P2 on A:5002 (on machine A), and both of them are shunned at the same time, > when they rejoin, P1 does not use port 5000, but might use port 5002, and P2 doesn't use 5002, but might use 5000, so > they could assume each other's identity ! > Both problems cannot be solved by remembering the last 100 ports: in case #1, this list is lost because we start a > new process and in case #2, the list is process-wide, but not machine-wide. > Again, these problems occur *only* when the OS reuses previously assigned ports. > SOLUTION: > A: Use temporary storage (per host) to store the last N addresses assigned on a given host. This makes sure we > don't reuse previous addresses > B: Use logical addresses, such as java.rmi.VMID or java.rmi.server.UID, which are unique over time for a given host. > Then, it doesn't matter what ports we use because the ports are not used to determine a member's identity. > The JIRA task for logical addresses is http://jira.jboss.com/jira/browse/JGRP-129. -- 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

19 years, 7 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBMESSAGING-287) RemotingTest.testConnectionListener() invalid

by Juha Lindfors (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-287?page=all ] Juha Lindfors reassigned JBMESSAGING-287: ----------------------------------------- Assignee: Juha Lindfors (was: Ovidiu Feodorov) > RemotingTest.testConnectionListener() invalid > --------------------------------------------- > > Key: JBMESSAGING-287 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-287 > Project: JBoss Messaging > Issue Type: Bug > Components: Tests and Performance > Reporter: Ovidiu Feodorov > Assigned To: Juha Lindfors > Priority: Minor > Fix For: 1.0.2.CR1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > I commented out that test because I wanted a clean test run for the release and also because I think the test is invalid. > After the client connects I assume there is a separate thread that renews the lease on server, so even if the main thread sleeps for 5 secs, the client renews its lease and the ConnectionListener doesn't get called. Please verify my assumption and either fix the test or remove it. -- 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

19 years, 7 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBMESSAGING-355) Remove possibility of delivery race conditions

by Juha Lindfors (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-355?page=all ] Juha Lindfors reassigned JBMESSAGING-355: ----------------------------------------- Assignee: Juha Lindfors (was: Tim Fox) > Remove possibility of delivery race conditions > ---------------------------------------------- > > Key: JBMESSAGING-355 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-355 > Project: JBoss Messaging > Issue Type: Task > Reporter: Tim Fox > Assigned To: Juha Lindfors > Fix For: 1.0.2.CR1 > > Attachments: race-condition.log > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Currently race conditions can occur on message delivery where the delivery is acknowledged or cancelled before the call to handle has returned. > In ChannelState we defensively program against this by synchronizing on the returned delivery and by dealing with the situation where the delivery does not exist in the channel state and ignoring. > See ChannelSupport::deliver() and ChannelState.cancelDelivery. > This approach has the following problems: > Complexity of code to maintain and understand. > Where acks return quickly we are likely to get contention on the lock in ChannelSupport::deliver, thus reducing throughput. > A much simpler solution enables us to remove the possibility of such race conditions and remove the corresponding lock contention. > This can be done by adding a confirm() method on Delivery. > When the receiver receives the message in it's handle() call, before dispatching the message it calls Delivery::confirm. This results in the channel adding the delivery to the channel state. Thus we can be assured that the delivery exists before any acknowledgment or cancellation comes in. > This is a very simple change. -- 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

19 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-125) Ambiguity on setters

by Adrian Brock (JIRA)

Ambiguity on setters -------------------- Key: JBMICROCONT-125 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-125 Project: JBoss MicroContainer Issue Type: Task Components: BeanInfo Affects Versions: JBossMC_2_0_0 Beta Reporter: Adrian Brock There is an ambiguity when it comes to javabeans with only setters, e.g. setSomething(Integer); setSomething(String); Currently, the implementation cannot use the getter to decide which is the correct setter. Instead it says that 'something" is not a property if there are multiple setters. Maybe this can be relaxed and we let the Configurator pick which one based upon what users decides to use? -- 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

19 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-670) Redirection of connection if server is not failover server

by Ovidiu Feodorov (JIRA)

Redirection of connection if server is not failover server ---------------------------------------------------------- Key: JBMESSAGING-670 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-670 Project: JBoss Messaging Issue Type: Sub-task Components: JMS Clustering Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.0.Beta1 Redirection of connection if server is not failover server. Needs to cope with multiple hops. -- 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

19 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-516) Clustering

by Tim Fox (JIRA)

Clustering ---------- Key: JBMESSAGING-516 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-516 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.Beta1 Implement clustering as described in: http://wiki.jboss.org/wiki/Wiki.jsp?page=NewClusteringDesign -- 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

19 years, 7 months

2
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-615) Add sufficient tracing for a customer environment

by Tim Fox (JIRA)

Add sufficient tracing for a customer environment ------------------------------------------------- Key: JBMESSAGING-615 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-615 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Fix For: 1.2.0.Beta1 Ensure there is sufficient logging at trace level to ensure problems in a customer environment can be diagnosed. -- 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

19 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-519) Transparent failover / HA

by Tim Fox (JIRA)

Transparent failover / HA ------------------------- Key: JBMESSAGING-519 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-519 Project: JBoss Messaging Issue Type: Sub-task Reporter: Tim Fox -- 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

19 years, 7 months

3
11
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-671) Recreate delivery list on the server when failure occurs

by Ovidiu Feodorov (JIRA)

Recreate delivery list on the server when failure occurs -------------------------------------------------------- Key: JBMESSAGING-671 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-671 Project: JBoss Messaging Issue Type: Sub-task Components: JMS Clustering Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Critical Fix For: 1.2.0.Beta1 -- 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

19 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-687) Fix clone on HAAspect::performClientSideFailover

by Clebert Suconic (JIRA)

Fix clone on HAAspect::performClientSideFailover ------------------------------------------------ Key: JBMESSAGING-687 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-687 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.2.0.Beta1 Reporter: Clebert Suconic Assigned To: Ovidiu Feodorov Fix For: 1.2.0.Beta1 HAAspect::performClientSideFailover is cloning state.children because we are using the oldSession to create new objects. We should use newSession to create failedOver objects. This issue is somehow related to JBMESSAGING-686, as this will lead to faiilures when closing the connection. -- 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

19 years, 7 months

1
2
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 December 2006