October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBJMX-105) Reassess response to JBJMX-101

by David Wade (JIRA)

Reassess response to JBJMX-101 ------------------------------ Key: JBJMX-105 URL: http://jira.jboss.com/jira/browse/JBJMX-105 Project: JBoss JMX Issue Type: Sub-task Affects Versions: JBossAS-4.0.0 Reporter: David Wade The suggested work around for the NullPointerException reported in JBJMX-101 is a bit of a cop-out and disregards the often quite complex deployment environments in which we often find ourselves where communicating such a around is neither trivial or professional looking. Can we reassess the original response with a view to perhaps fixing the issue? -- 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

17 years, 5 months

3
4
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-133) Multiplexer documentation

by Brian Stansberry (JIRA)

Multiplexer documentation ------------------------- Key: JBCLUSTER-133 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-133 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q4Y6 -- 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

17 years, 6 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-134) Buddy replication documentation for http sessions

by Brian Stansberry (JIRA)

Buddy replication documentation for http sessions ------------------------------------------------- Key: JBCLUSTER-134 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-134 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q4Y6 -- 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

17 years, 6 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-3647) Backport SingleRetryInterceptor to 3.2

by Scott M Stark (JIRA)

Backport SingleRetryInterceptor to 3.2 -------------------------------------- Key: JBAS-3647 URL: http://jira.jboss.com/jira/browse/JBAS-3647 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering, EJB2 Affects Versions: JBossAS-3.2.8.SP1 Reporter: Scott M Stark Assigned To: Brian Stansberry A 3.2.8.SP1 client attempting to connect to a 4.0.4 clustered bean fails with the following error due to the SingleRetryInterceptor not being available in 3.2.8.SP1: 2006-09-12 16:44:30,178 [Thread-0::] - javax.naming.CommunicationException. Root exception is java.lang.ClassNotFoundException: org.jboss.proxy.ejb.SingleRetryInterceptor (no security manager: RMI class loader disabled) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:318) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:132) at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:143) at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) We should backport this. -- 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

17 years, 6 months

4
4
0 / 0

[JBoss JIRA] Created: (JBAS-4505) Inter-jar dependencies between clustered EJBs leads to bean not accepting requests

by Brian Stansberry (JIRA)

Inter-jar dependencies between clustered EJBs leads to bean not accepting requests ---------------------------------------------------------------------------------- Key: JBAS-4505 URL: http://jira.jboss.com/jira/browse/JBAS-4505 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, EJB2 Affects Versions: JBossAS-4.2.0.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Scenario: 2 clustered EJB2 beans, A and B, deployed in A.jar and B.jar. A declares a dependency on B via a <depends> in jboss.xml. A.jar gets deployed before B.jar. Problem: The latch in bean A's HATarget that allows invocations to reach the bean never gets released. The bean is available in JNDI, but any thread that attempts to invoke on it will block (forever) on the latch. The bean becomes a black hole for threads. Cause: ProxyFactoryHA registers a JMX NotificationListener to listen for a service started event. Receipt of that event triggers release of the latch. Problem is it listeners for the start of the EJB module (A.jar) rather than the target bean. Reason for this is described in the ProxyFactoryHA.create() method: // ************************************************************************ // NOTE: We could also subscribe for the container service events instead of the // ejbModule service events. This problem comes from beans using other beans // in the same ejbModule: we may receive an IllegalStateException thrown // by the Container implementation. Using ejbModule events solve this // problem. // ************************************************************************ this.container.getServer (). addNotificationListener (this.container.getEjbModule ().getServiceName (), new ProxyFactoryHA.StateChangeListener (), filter, null); My interpretation of the comment is that if you allow access to the bean before the entire module is started, and the bean calls into a 2nd bean in the same module, then a request could come it via the 1st bean that tries to prematurely access the 2nd bean. Waiting for the entire module to start is intended to prevent this. The assumption here is that all beans within the module will complete the start phase before the module itself. Problem is the depends element on a bean breaks this assumption. What happens is you get the following start order: A.jar bean B bean A B.jar Effect is the notification for A.jar start happens before the HATarget for bean A even exists. The latch that A's HATarget later creates will thus never get released. -- 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

17 years, 6 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-4390) Prevent response completion until replication returns

by Brian Stansberry (JIRA)

Prevent response completion until replication returns ----------------------------------------------------- Key: JBAS-4390 URL: http://jira.jboss.com/jira/browse/JBAS-4390 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Brian Stansberry Even with synchronous replication, the client can read and receive the response before replication completes. This means they can send another request that potentially fails over and sees inconsistent session state. Need to investigate how to cleanly prevent the sending of the response (or at least the final flush of the response body) until the replication completes. Preventing sending of response headers is probably too much to try to do; perhaps just preventing the close of the response output stream. By "replication completes" I mean: w/ instant mode and REPL_SYNC -- the full synchronous replication with acknowledgement of receipt by the foreign nodes w/ instant mode and REPL_ASYNC -- until JGroups has pushed the replication message onto the wire w/ interval mode -- basically instantaneous. i.e. as soon as the session is marked for replication. -- 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

17 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4604) NamingContext does not take potential AutoDiscoveryAddress XML property overrides when sending discovery requests

by Galder Zamarreno (JIRA)

NamingContext does not take potential AutoDiscoveryAddress XML property overrides when sending discovery requests ----------------------------------------------------------------------------------------------------------------- Key: JBAS-4604 URL: http://jira.jboss.com/jira/browse/JBAS-4604 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, Naming Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA Reporter: Galder Zamarreno Assigned To: Brian Stansberry Priority: Minor Bug in org.jnp.interfaces.NamingContext: discoverServer(Hashtable) method String group = DEFAULT_DISCOVERY_GROUP_ADDRESS; ... String discoveryGroup = (String) serverEnv.get(JNP_DISCOVERY_GROUP); if (discoveryGroup != null) group = discoveryGroup; ... iaGroup = InetAddress.getByName(group); .... if (trace) log.trace("Sending discovery packet(" + data + ") to: " + iaGroup + ":" + port); NamingContext code does not take in account possible system property overrides coming from: <attribute name="AutoDiscoveryAddress">${jboss.partition.udpGroup:230.0.0.4}</attribute> AutoDiscoveryAddress used to send discovery messages is controlled via the the default value, 230.0.0.4 or jnp.discoveryGroup property. So, if user sets jboss.partition.udpGroup=224.0.0.1 on startup, DetachedHANamingService$AutomaticDiscovery will listen on 224.0.0.1 while NamingContext sends discovery requests to 230.0.0.4 -- 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

17 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-4524) Use JBoss Serialization to serialize non-serializable objects in a clustered web application session.

by Ricardo Arguello (JIRA)

Use JBoss Serialization to serialize non-serializable objects in a clustered web application session. ----------------------------------------------------------------------------------------------------- Key: JBAS-4524 URL: http://jira.jboss.com/jira/browse/JBAS-4524 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-4.0.5.GA Reporter: Ricardo Arguello Assigned To: Brian Stansberry Priority: Optional If you have a clustered web application (<distributable/>) you can't put non-serializable objects in an HttpSession. JBoss Serialization could be used to support this, as it can serialize non-serializable objects. Initial support for JBoss Serialization was added in JBAS-2921. -- 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

17 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4757) Need a new LBP for Redistirbution of Load When Cluster Membership Changes

by Jimmy Wilson (JIRA)

Need a new LBP for Redistirbution of Load When Cluster Membership Changes ------------------------------------------------------------------------- Key: JBAS-4757 URL: http://jira.jboss.com/jira/browse/JBAS-4757 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA Reporter: Jimmy Wilson Assigned To: Brian Stansberry Priority: Minor Possible implementations: 1) Return to original target. Note I believe this won't work for RMI-based targets (could be wrong). 2) Everyone randomly picks new targets when a new node joins. Bad as this causes max # of failovers. 3) Determine what the new servers are. Say 2 out of 6 are new. Calc a random and see if < .33; if so randomly pick one of the new servers as your target. -- 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

17 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-180) Calling getters/setters cluster wide - covenience feature

by Galder Zamarreno (JIRA)

Calling getters/setters cluster wide - covenience feature --------------------------------------------------------- Key: JBCLUSTER-180 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-180 Project: JBoss Clustering Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Galder Zamarreno Assigned To: Brian Stansberry Priority: Optional We'd like to check the values of an attirbute on all cluster nodes. Is there any quick way to do so? During the startup of your own JMX MBean service you first have to register it with HAPartition using registerRPCHandler method in HAPartition [1]. Provide a service name and your own MBean object as parameters. When checking a value of an attribute of your mbean in the whole cluster you would invoke HAPartition.callMethodOnCluster together with service name parameter provided for registerRPCHandler method. You have to expose this attribute as an operation However, it would be more convenient to just use getter or setter. thanks, -- 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

17 years, 6 months

3
5
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 October 2007