April 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-587) Lightweight FLUSH for state transfer

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-587?page=com.atlassian.jira.plugin.s... ] Bela Ban reopened JGRP-587: --------------------------- > Lightweight FLUSH for state transfer > ------------------------------------ > > Key: JGRP-587 > URL: https://issues.jboss.org/browse/JGRP-587 > Project: JGroups > Issue Type: Feature Request > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: Future > > > We should investigate introduction of lightweight FLUSH in Multiplexer. Lightweight FLUSH would introduce stop-the-world model to only specific mux application leaving other mux applications unaffected. For example, if there are three mux applications A,B, and C and we need to FLUSH only application C, lightweight FLUSH would block all message sending for C only while applications A and B are unaffected. > For Multiplexer, JOIN's will still need to block everyone, because we're actually creating the underlying JChannel. > For state transfer on the Multiplexer, the example should be: > - Members {A,B,C}. A and B have services X and Y, C has only service Y > - Service B.X requests a state transfer (MuxChannel.getState()) > - The FLUSH needs to be qualified with the service-id: FLUSH(X) > - A, B and C receive a START-FLUSH(X) message, which invokes A.X.block(), B.X.block(). > - For C, since there is no X service, Multiplexer.block() simply returns > - When A has received all FLUSH-OK messages from A, B and C, we transfer the state from A.X to B.X > - Then we terminate the FLUSH by sending a STOP-FLUSH(x) to {A,B,C} > - This again calls A.X.unblock(), B.X.unblock() and is a no-op for C > This allows other services, e.g. Y, to be unaffected (ie., non-blocked) by the flushing of A.X -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-587) Lightweight FLUSH for state transfer

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-587?page=com.atlassian.jira.plugin.s... ] Bela Ban updated JGRP-587: -------------------------- Fix Version/s: 3.5 (was: Future) > Lightweight FLUSH for state transfer > ------------------------------------ > > Key: JGRP-587 > URL: https://issues.jboss.org/browse/JGRP-587 > Project: JGroups > Issue Type: Feature Request > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 3.5 > > > We should investigate introduction of lightweight FLUSH in Multiplexer. Lightweight FLUSH would introduce stop-the-world model to only specific mux application leaving other mux applications unaffected. For example, if there are three mux applications A,B, and C and we need to FLUSH only application C, lightweight FLUSH would block all message sending for C only while applications A and B are unaffected. > For Multiplexer, JOIN's will still need to block everyone, because we're actually creating the underlying JChannel. > For state transfer on the Multiplexer, the example should be: > - Members {A,B,C}. A and B have services X and Y, C has only service Y > - Service B.X requests a state transfer (MuxChannel.getState()) > - The FLUSH needs to be qualified with the service-id: FLUSH(X) > - A, B and C receive a START-FLUSH(X) message, which invokes A.X.block(), B.X.block(). > - For C, since there is no X service, Multiplexer.block() simply returns > - When A has received all FLUSH-OK messages from A, B and C, we transfer the state from A.X to B.X > - Then we terminate the FLUSH by sending a STOP-FLUSH(x) to {A,B,C} > - This again calls A.X.unblock(), B.X.unblock() and is a no-op for C > This allows other services, e.g. Y, to be unaffected (ie., non-blocked) by the flushing of A.X -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-587) Lightweight FLUSH for state transfer

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-587?page=com.atlassian.jira.plugin.s... ] Bela Ban resolved JGRP-587. --------------------------- Resolution: Out of Date Duplicated by fork-channels > Lightweight FLUSH for state transfer > ------------------------------------ > > Key: JGRP-587 > URL: https://issues.jboss.org/browse/JGRP-587 > Project: JGroups > Issue Type: Feature Request > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 3.5 > > > We should investigate introduction of lightweight FLUSH in Multiplexer. Lightweight FLUSH would introduce stop-the-world model to only specific mux application leaving other mux applications unaffected. For example, if there are three mux applications A,B, and C and we need to FLUSH only application C, lightweight FLUSH would block all message sending for C only while applications A and B are unaffected. > For Multiplexer, JOIN's will still need to block everyone, because we're actually creating the underlying JChannel. > For state transfer on the Multiplexer, the example should be: > - Members {A,B,C}. A and B have services X and Y, C has only service Y > - Service B.X requests a state transfer (MuxChannel.getState()) > - The FLUSH needs to be qualified with the service-id: FLUSH(X) > - A, B and C receive a START-FLUSH(X) message, which invokes A.X.block(), B.X.block(). > - For C, since there is no X service, Multiplexer.block() simply returns > - When A has received all FLUSH-OK messages from A, B and C, we transfer the state from A.X to B.X > - Then we terminate the FLUSH by sending a STOP-FLUSH(x) to {A,B,C} > - This again calls A.X.unblock(), B.X.unblock() and is a no-op for C > This allows other services, e.g. Y, to be unaffected (ie., non-blocked) by the flushing of A.X -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3258) Upgrade jboss-remote-naming to 2.0.1.Final or later

by Michael Reynolds (JIRA)

[ https://issues.jboss.org/browse/WFLY-3258?page=com.atlassian.jira.plugin.... ] Michael Reynolds commented on WFLY-3258: ---------------------------------------- in maven central it is only up to 2.0.0.Final and the one in JBoss repository is 2.0.1.Final-SNAPSHOT. What do you need to do in that case? They need to do a 2.0.1.Final release first. > Upgrade jboss-remote-naming to 2.0.1.Final or later > --------------------------------------------------- > > Key: WFLY-3258 > URL: https://issues.jboss.org/browse/WFLY-3258 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: 8.0.0.Final > Reporter: Brad Maxwell > Assignee: David Lloyd > Priority: Blocker > > Upgrade jboss-remote-naming to 2.0.1.Final or later to resolve linked issues -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-696) Incorporate RedHat clustering documentation into JGroups manual

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-696?page=com.atlassian.jira.plugin.s... ] Bela Ban updated JGRP-696: -------------------------- Fix Version/s: 3.5 (was: Future) > Incorporate RedHat clustering documentation into JGroups manual > --------------------------------------------------------------- > > Key: JGRP-696 > URL: https://issues.jboss.org/browse/JGRP-696 > Project: JGroups > Issue Type: Sub-task > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.5 > > > Incorporate relevant sections into the manual. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-696) Incorporate RedHat clustering documentation into JGroups manual

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-696?page=com.atlassian.jira.plugin.s... ] Bela Ban closed JGRP-696. ------------------------- > Incorporate RedHat clustering documentation into JGroups manual > --------------------------------------------------------------- > > Key: JGRP-696 > URL: https://issues.jboss.org/browse/JGRP-696 > Project: JGroups > Issue Type: Sub-task > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.5 > > > Incorporate relevant sections into the manual. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-789) Can't manage classloader for threads created by TP.ProtocolAdapter

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-789?page=com.atlassian.jira.plugin.s... ] Bela Ban reopened JGRP-789: --------------------------- to move to 3.5 and close it there > Can't manage classloader for threads created by TP.ProtocolAdapter > ------------------------------------------------------------------ > > Key: JGRP-789 > URL: https://issues.jboss.org/browse/JGRP-789 > Project: JGroups > Issue Type: Bug > Reporter: Brian Stansberry > Assignee: Bela Ban > Fix For: Future > > > TP.ProtocolAdapter is creating a ThreadFactory, but the JGRP-764 solution of adding a classloader management decorator to that ThreadFactory can't be applied. Problem is the thread factory decoration is done following channel creation but before connect(), but TP.ProtocolAdapter isn't even created until the connect phase. It's created in Configurator.startProtocolStack(). > Once this TP.ProtocolAdapter thread factory exists, all protocols higher in the stack will use it. I find this leads to a classloader leak to the GMS$ViewHandler.thread during channel disconnect (see JBAS-5414). > I believe the correct solution to this is to create the TP.ProtocolAdapter in Configurator.connectProtocols(). The TP.ProtocolAdapter constructor takes cluster_name and address params though, and those aren't known until Channel.connect(). They aren't needed until then, either though. :) The address could be provided during the connect phase as part of Configurator.startProtocolStack(), the way it's provided to above_prot now. The cluster_name will presumably come down with the CONNECT event. > Besides fixing this problem, I think adding the TP.ProtocolAdapter during channel creation is conceptually cleaner. It's really another protocol in the stack, so having it have a lifecycle similar to the others seems good. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-789) Can't manage classloader for threads created by TP.ProtocolAdapter

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-789?page=com.atlassian.jira.plugin.s... ] Bela Ban resolved JGRP-789. --------------------------- Fix Version/s: 3.5 (was: Future) Resolution: Won't Fix > Can't manage classloader for threads created by TP.ProtocolAdapter > ------------------------------------------------------------------ > > Key: JGRP-789 > URL: https://issues.jboss.org/browse/JGRP-789 > Project: JGroups > Issue Type: Bug > Reporter: Brian Stansberry > Assignee: Bela Ban > Fix For: 3.5 > > > TP.ProtocolAdapter is creating a ThreadFactory, but the JGRP-764 solution of adding a classloader management decorator to that ThreadFactory can't be applied. Problem is the thread factory decoration is done following channel creation but before connect(), but TP.ProtocolAdapter isn't even created until the connect phase. It's created in Configurator.startProtocolStack(). > Once this TP.ProtocolAdapter thread factory exists, all protocols higher in the stack will use it. I find this leads to a classloader leak to the GMS$ViewHandler.thread during channel disconnect (see JBAS-5414). > I believe the correct solution to this is to create the TP.ProtocolAdapter in Configurator.connectProtocols(). The TP.ProtocolAdapter constructor takes cluster_name and address params though, and those aren't known until Channel.connect(). They aren't needed until then, either though. :) The address could be provided during the connect phase as part of Configurator.startProtocolStack(), the way it's provided to above_prot now. The cluster_name will presumably come down with the CONNECT event. > Besides fixing this problem, I think adding the TP.ProtocolAdapter during channel creation is conceptually cleaner. It's really another protocol in the stack, so having it have a lifecycle similar to the others seems good. -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-698) Incorporate wiki documentation into the manual

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-698?page=com.atlassian.jira.plugin.s... ] Bela Ban updated JGRP-698: -------------------------- Fix Version/s: 3.5 (was: Future) > Incorporate wiki documentation into the manual > ---------------------------------------------- > > Key: JGRP-698 > URL: https://issues.jboss.org/browse/JGRP-698 > Project: JGroups > Issue Type: Sub-task > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.5 > > > The JGroups wiki contains a lot of up-to-the-minute information on JGroups protocols, configuration and other aspects. Incorporate relevant elements into the manual to improve content and scope. > -- 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

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-698) Incorporate wiki documentation into the manual

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-698?page=com.atlassian.jira.plugin.s... ] Bela Ban closed JGRP-698. ------------------------- > Incorporate wiki documentation into the manual > ---------------------------------------------- > > Key: JGRP-698 > URL: https://issues.jboss.org/browse/JGRP-698 > Project: JGroups > Issue Type: Sub-task > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.5 > > > The JGroups wiki contains a lot of up-to-the-minute information on JGroups protocols, configuration and other aspects. Incorporate relevant elements into the manual to improve content and scope. > -- 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

10 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2014