[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 …
[View More]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
[View Less]
16 years, 2 months
[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 …
[View More]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
[View Less]
16 years, 2 months
[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, …
[View More]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
[View Less]
16 years, 2 months
[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
…
[View More]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
[View Less]
16 years, 2 months
[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 …
[View More]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
[View Less]
16 years, 2 months
[JBoss JIRA] Created: (JBAS-4629) Optimized replication of entities and extended persistence context in HttpSessions
by Brian Stansberry (JIRA)
Optimized replication of entities and extended persistence context in HttpSessions
----------------------------------------------------------------------------------
Key: JBAS-4629
URL: http://jira.jboss.com/jira/browse/JBAS-4629
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Clustering, Web (Tomcat) service
Reporter: Brian Stansberry
…
[View More] Assigned To: Brian Stansberry
Optimize replication of clustered web sessions that hold refs to managed entities and extended persistence contexts, while still ensuring that object identity is maintained between refs to an entity held as a session attribute and those held by the replicated EntityManager.
Currently object identity is maintained by serializing the entire session as one operation (and thus only works reliably if SESSION granularity is used). The entire EM is serialized, including entities that have been flushed to the db. This is inefficient, since the replication is only done to support failover and in the case of node failover, the flushed entities can be restored from the db or the EM's 2nd level cache.
Intent is to:
1) Use JBoss serialization in order to have the ability to alter the serialized form of entities and XPCs.
1) Have Hibernate's EM impl expose getUnflushedChanges()/setUnflushedChanges() methods to support replication of only the unflushed changes held in the XPC, rather than all data.
2) When writing the attributes in the session, check if the object is a managed entity; if so write it's id to the stream rather than the whole object.
3) Deserialization process needs to ensure that any EntityManager is deserialized before the managed entities.
4) Deserialization of a managed entity would involve reading the id from the stream, identifying the EntityManager and doing a find().
5) Sessions should be lazy-deserialized (i.e. only deserialize if needed to handle failover). This is the way web session clustering already works. This is critical, otherwise the cost of the find() operations would likely outweigh the benefits of reducing the amount of replicated data.
Additionally, intent is to allow registration with the container of an impl, say, "ManagedPersistenceContextSerializer". If registered, implementation of many of the steps above would be delegated. JBoss Seam would intend to register an implementation.
--
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
[View Less]
16 years, 2 months