April 2014 - jboss-jira - Jboss List Archives

[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

12 years, 3 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

12 years, 3 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

12 years, 3 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

12 years, 3 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

12 years, 3 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-825) Message: add a flag to discard own multicast

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-825?page=com.atlassian.jira.plugin.s... ] Bela Ban resolved JGRP-825. --------------------------- Fix Version/s: 3.5 (was: Future) Resolution: Duplicate Issue In 3.5, messages are looped back by default, so this issue is moot > Message: add a flag to discard own multicast > -------------------------------------------- > > Key: JGRP-825 > URL: https://issues.jboss.org/browse/JGRP-825 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > If we have a group consisting of members {A,B,C} and A wants to multicast to the group, it will receive its own message too. To avoid this, A can set option LOCAL on its channel to false, meaning that all messages sent by A will get discarded by A's channel. > The problem here is that those messages need to get handled nevertheless (e.g. by NAKACK, including retransmissions), all the way up the stack, until they hit the channel - only to be discarded there. This is a waste of resources (CPU and memory). > A solution is to discard the multicast at the transport level. If a message has a flag LOCAL set to false, then TP discards it if > - the message is a multicast message and > - the sender of the message is the local member -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-859) Message: add LOOPBACK flag

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-859?page=com.atlassian.jira.plugin.s... ] Bela Ban resolved JGRP-859. --------------------------- Resolution: Duplicate Issue TP.loopback is always true by default, so this issue is moot > Message: add LOOPBACK flag > -------------------------- > > Key: JGRP-859 > URL: https://issues.jboss.org/browse/JGRP-859 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > When LOOPBACK is set in a message, the UNICAST.loopback and TP.loopback flags are overridden and a message is looped back up the stack, regardless of the value of the property. > This is useful for example for VIEW and SUSPECT messages, where a socket could be disconnected (e.g. cable plugged) and we still need to be able to receive our own messages. -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-859) Message: add LOOPBACK flag

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-859?page=com.atlassian.jira.plugin.s... ] Bela Ban updated JGRP-859: -------------------------- Fix Version/s: 3.5 (was: Future) > Message: add LOOPBACK flag > -------------------------- > > Key: JGRP-859 > URL: https://issues.jboss.org/browse/JGRP-859 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > When LOOPBACK is set in a message, the UNICAST.loopback and TP.loopback flags are overridden and a message is looped back up the stack, regardless of the value of the property. > This is useful for example for VIEW and SUSPECT messages, where a socket could be disconnected (e.g. cable plugged) and we still need to be able to receive our own messages. -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3139) Add MongoDB support for a batch repository type

by Cheng Fang (JIRA)

[ https://issues.jboss.org/browse/WFLY-3139?page=com.atlassian.jira.plugin.... ] Cheng Fang commented on WFLY-3139: ---------------------------------- Mongo item reader and writer are already supported through jberet-support. See JBERET-41 and JBERET-42. In fact, batch ItemReader, ItemProcessor and ItemWriter are to be implemented by application, and any such reader/processor/writer should just work with JBeret and WildFly, but jberet-support provides some common implementations for convenience. > Add MongoDB support for a batch repository type > ----------------------------------------------- > > Key: WFLY-3139 > URL: https://issues.jboss.org/browse/WFLY-3139 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Batch > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > JBeret now supports MongoDB for a repository type. WildFly needs to integrate the new repository type as another option. -- 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

12 years, 3 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 April 2014