February 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-1205) Retransmitter reset does not prevent new task addition after chanel close

by Vladimir Blagojevic (JIRA)

Retransmitter reset does not prevent new task addition after chanel close ------------------------------------------------------------------------- Key: JGRP-1205 URL: https://jira.jboss.org/browse/JGRP-1205 Project: JGroups Issue Type: Bug Affects Versions: 2.9, 2.8, 2.7, 2.6.15 Reporter: Vladimir Blagojevic Assignee: Bela Ban Fix For: 2.10 Sometimes, messages are being added to the Retransmitter *after* a channel has been . This can happen if OOB messages are being passed around at the time a channel leaving a group. The problem occurs in that messages are added after Retransmitter.reset(). Normally, the timer is also stopped when the channel is disconnected, but since the Timer is shared amongst all channels, any messages added to Retransmitter after reset() just continue to be requested because the timer that those tasks were scheduled on did not die. This can be solved by either specifically stopping the Retransmitter or giving each ProtocolAdapter their own Timer which is then shutdown on channel disconnect. Michael -- 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, 2 months

4
7
0 / 0

[JBoss JIRA] Updated: (JBAS-8849) Interceptors, decorators and alternatives should be per archive

by Ales Justin (JIRA)

[ https://issues.jboss.org/browse/JBAS-8849?page=com.atlassian.jira.plugin.... ] Ales Justin updated JBAS-8849: ------------------------------ Affects Version/s: 6.0.0.Final > Interceptors, decorators and alternatives should be per archive > --------------------------------------------------------------- > > Key: JBAS-8849 > URL: https://issues.jboss.org/browse/JBAS-8849 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld/CDI > Affects Versions: 6.0.0.Final > Reporter: Ales Justin > > Per 12.1 spec: > - Which alternatives, interceptors and decorators are enabled for *each* bean archive -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] Moved: (JBAS-8849) Interceptors, decorators and alternatives should be per archive

by Ales Justin (JIRA)

[ https://issues.jboss.org/browse/JBAS-8849?page=com.atlassian.jira.plugin.... ] Ales Justin moved WELD-847 to JBAS-8849: ---------------------------------------- Project: JBoss Application Server (was: Weld) Key: JBAS-8849 (was: WELD-847) Issue Type: Bug (was: Task) Component/s: Weld/CDI (was: Infrastructure) (was: Interceptors and Decorators) Security: Public > Interceptors, decorators and alternatives should be per archive > --------------------------------------------------------------- > > Key: JBAS-8849 > URL: https://issues.jboss.org/browse/JBAS-8849 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld/CDI > Reporter: Ales Justin > > Per 12.1 spec: > - Which alternatives, interceptors and decorators are enabled for *each* bean archive -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] Deleted: (JBAS-8848) Allow the setting of the community string stored in snmp traps in the SNMP adapter

by Masafumi Miura (JIRA)

[ https://issues.jboss.org/browse/JBAS-8848?page=com.atlassian.jira.plugin.... ] Masafumi Miura deleted JBAS-8848: --------------------------------- > Allow the setting of the community string stored in snmp traps in the SNMP adapter > ---------------------------------------------------------------------------------- > > Key: JBAS-8848 > URL: https://issues.jboss.org/browse/JBAS-8848 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Masafumi Miura > > The SNMP adapter includes the hardcoded "public" community with each generated trap. > The community string in traps is optional and in most cases of no use to a monitoring manager. A manager can always restrict the trap it receives based on the originating host/port combination. Those are set in snmp-adaptor.sar/managers.xml. > However, it would be nice to be able to set the community string in traps (or choose to not set it at all) per receiving manager. > This means that the configuration file for monitoring manager would have to be extended, e.g.: > <manager> > <address>localhost</address> > <port>1162</port> > <local-address></local-address> > <local-port></local-port> > <community>custom community string</community> <=== HERE > <version>1</version> > </manager> > For backwards compatibility, absense of the <community> element could be interpreted as "public", while an empty element could mean "no community string" -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-8848) Allow the setting of the community string stored in snmp traps in the SNMP adapter

by Masafumi Miura (JIRA)

Allow the setting of the community string stored in snmp traps in the SNMP adapter ---------------------------------------------------------------------------------- Key: JBAS-8848 URL: https://issues.jboss.org/browse/JBAS-8848 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: SNMP adapter Affects Versions: JBossAS-4.2.3.GA Reporter: Masafumi Miura The SNMP adapter includes the hardcoded "public" community with each generated trap. The community string in traps is optional and in most cases of no use to a monitoring manager. A manager can always restrict the trap it receives based on the originating host/port combination. Those are set in snmp-adaptor.sar/managers.xml. However, it would be nice to be able to set the community string in traps (or choose to not set it at all) per receiving manager. This means that the configuration file for monitoring manager would have to be extended, e.g.: <manager> <address>localhost</address> <port>1162</port> <local-address></local-address> <local-port></local-port> <community>custom community string</community> <=== HERE <version>1</version> </manager> For backwards compatibility, absense of the <community> element could be interpreted as "public", while an empty element could mean "no community string" -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-291) CoreGroupCommunicationService not compatible with RELAY protocol

by Paul Ferraro (JIRA)

CoreGroupCommunicationService not compatible with RELAY protocol ---------------------------------------------------------------- Key: JBCLUSTER-291 URL: https://issues.jboss.org/browse/JBCLUSTER-291 Project: JBoss Clustering Issue Type: Bug Security Level: Public (Everyone can see) Components: HA-Server-Core Affects Versions: HA-Server-Core 1.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: HA-Server-Core 1.0.1.Final Using the relay protocol in JGroups 2.12, CoreGroupCommunicationService.ClusterNodeFactoryImpl chokes (throws an IllegalStateException) when trying to determine the physical address (org.jgroups.stack.IpAddress) of a proxied member. Currently, the physical address is determined by sending a Event.GET_PHYSICAL_ADDRESS event down the stack. When the stack contains RELAY, a null is returned. The value returned by this downcall is used by ClusterNodeFactoryImpl to generate a meaningful name using the IP address and port as reported by JGroups. We need to either: * Have RELAY respond to GET_PHYSICAL_ADDRESS events with a meaningful address * Use some other mechanism to supply ClusterNode with a unique name -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-259) Customized Infinispan CacheManager impl

by Brian Stansberry (JIRA)

Customized Infinispan CacheManager impl --------------------------------------- Key: JBCLUSTER-259 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-259 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Components: HA-Server-Cache-ISPN Reporter: Brian Stansberry Fix For: HA-Server-Cache-ISPN 1.0.0.Final If necessary. ---- Inject ChannelFactory ---- Figure how to configure desired channel in Infinispan config ---- Figure how to inject desired channel after creating cache Aliasing if not supported yet via ISPN-316 Check for other AS 5 CacheManager features useful for retaining, e.g. not stopping caches at CacheManager stop? -- 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, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-283) Remove support for integrating with standalone Tomcat

by Brian Stansberry (JIRA)

Remove support for integrating with standalone Tomcat ----------------------------------------------------- Key: JBCLUSTER-283 URL: https://jira.jboss.org/browse/JBCLUSTER-283 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Components: HA-Server-Cache-SPI Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: HA-Server-Cache-SPI 3.0.0.Final Standalone tomcat support is years old, has never been finished and is getting in the way of clean implementations of new features. -- 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, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-284) Deprecate use of term "partition" (HAPartition, ClusterPartition, etc)

by Paul Ferraro (JIRA)

Deprecate use of term "partition" (HAPartition, ClusterPartition, etc) ---------------------------------------------------------------------- Key: JBCLUSTER-284 URL: https://jira.jboss.org/browse/JBCLUSTER-284 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: HA-Server-API 1.2.0.Final , HA-Server-Cache-JBC 2.3.0.Final, HA-Server-API 1.1.1GA, HA-Client 1.1.1.GA Reporter: Paul Ferraro Assignee: Paul Ferraro Priority: Minor Fix For: HA-Server-Cache-JBC 2.4.0.Final , HA-Server-API 2.0.0.Beta1, HA-Server-Core 1.0.0.Beta1, HA-Server-API 2.0.0.Final, HA-Client 2.0.0.BETA1 The term "partition" should be globally replaced by the term "cluster". This affects public interfaces (the deprecation of which need to be fully backwards compatible), public implementation classes, member variables, system properties, Javadocs, and clustering documentation. -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7941) ClusterPartition should not send service name twice per message

by Brian Stansberry (JIRA)

ClusterPartition should not send service name twice per message --------------------------------------------------------------- Key: JBAS-7941 URL: https://jira.jboss.org/jira/browse/JBAS-7941 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.M4 ClusterPartition uses a custom RpcDispatcher.Marshaller that encodes the serviceName of the target service in the first element of an Object[]. The service name is also encoded in the "name" property of the MethodCall that forms the second element of the Object[]. This is inefficient: 1) It increases the size of the over-the-wire message. 2) It forces each recipient to remove the serviceName from the MethodCall.name to figure out the actual method name. Change this so the sender's RpcDispatcher.Marshaller removes the serviceName from MethodCall.name before marshalling it. -- 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, 2 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2011