[JBoss JIRA] Commented: (JGRP-130) Problems with reincarnation
by Anton Melser (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-130?page=comments#action_12352399 ]
Anton Melser commented on JGRP-130:
-----------------------------------
Is there an ETA on this functionality/2.6?
> Problems with reincarnation
> ---------------------------
>
> Key: JGRP-130
> URL: http://jira.jboss.com/jira/browse/JGRP-130
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 2.2.9
> Reporter: Bela Ban
> Assigned To: Bela Ban
> Fix For: 2.6
>
>
> Problems with reincarnation
> ===========================
> Author: Bela Ban
> Version: $Id$
> The identity of a JGroups member is always the IP address and a port. The port is usually chosen by the OS, unless
> bind_port is set (not set by default).
> Let's say a member's address is hostA:5000. When that member dies and is restarted, the OS will likely assign a
> higher port, say 5002. This depends on how many other processes requested a port in between the start and restart
> of the member.
> JGroups relies on the fact that the assignment of ports by the OS is always (not necessarily monotonically)
> *increasing* across a single machine. If this is not the case, then the following problems can occur:
> 1. Restart:
> When a member P crashes and then is restarted, if FD is used and P is restarted *before* it is excluded,
> then we have a new member *under the same old address* ! Since it lost all of its state (e.g. retransmission table),
> retransmission requests sent to the new P will fail.
> 2. Shunning:
> Regarding shunning: a member keeps its last N (default is 100) ports used, and makes sure it doesn't reuse one of
> those already-used ports when it is shunned. However, this is process-wide and *not* machine-wide, e.g. when we have
> processes P1 on A:5000 and P2 on A:5002 (on machine A), and both of them are shunned at the same time,
> when they rejoin, P1 does not use port 5000, but might use port 5002, and P2 doesn't use 5002, but might use 5000, so
> they could assume each other's identity !
> Both problems cannot be solved by remembering the last 100 ports: in case #1, this list is lost because we start a
> new process and in case #2, the list is process-wide, but not machine-wide.
> Again, these problems occur *only* when the OS reuses previously assigned ports.
> SOLUTION:
> A: Use temporary storage (per host) to store the last N addresses assigned on a given host. This makes sure we
> don't reuse previous addresses
> B: Use logical addresses, such as java.rmi.VMID or java.rmi.server.UID, which are unique over time for a given host.
> Then, it doesn't matter what ports we use because the ports are not used to determine a member's identity.
> The JIRA task for logical addresses is http://jira.jboss.com/jira/browse/JGRP-129.
--
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, 4 months
[JBoss JIRA] Resolved: (JBAS-3265) Problem with empty classname in classloader
by Scott M Stark (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3265?page=all ]
Scott M Stark resolved JBAS-3265.
---------------------------------
Fix Version/s: JBossAS-5.0.0.Beta2
Resolution: Done
Reject null or empty class names with a CNFE
> Problem with empty classname in classloader
> -------------------------------------------
>
> Key: JBAS-3265
> URL: http://jira.jboss.com/jira/browse/JBAS-3265
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMX
> Affects Versions: JBossAS-4.0.4.GA
> Reporter: Adrian Brock
> Assigned To: Scott M Stark
> Fix For: JBossAS-5.0.0.Beta2, JBossAS-4.2.0.CR1
>
>
> The RepositoryClassLoader doesn't handle empty classnames correctly.
> It eventually breaks when it tries to do the array name handling here:
> // If this is an array class, use Class.forName to resolve it
> if( name.charAt(0) == '[' )
> {
> result = Class.forName(name, true, this);
> removeFromClassBlackList(name);
> return result;
> }
> 17:04:42,858 ERROR [STDERR] java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> 17:04:42,860 ERROR [STDERR] at java.lang.String.charAt(String.java:444)
> 17:04:42,861 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClassLocally(RepositoryClassLoader.java:169)
> 17:04:42,862 ERROR [STDERR] at org.jboss.mx.loading.UnifiedLoaderRepository3.loadClassFromClassLoader(UnifiedLoaderRepository3.java:263)
> 17:04:42,862 ERROR [STDERR] at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:270)
> 17:04:42,864 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:475)
> 17:04:42,865 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:377)
> 17:04:42,865 ERROR [STDERR] at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> The classloader should just reject a null or empty ("") classname in loadClass()
> with a meaningful error message.
> I suspect the null is handled by the cache since the cache is a Concurrent HashMap
> which won't accept null as a key.
--
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, 4 months
[JBoss JIRA] Resolved: (JBAS-2249) Cleanup the org.jboss.naming packaging
by Scott M Stark (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2249?page=all ]
Scott M Stark resolved JBAS-2249.
---------------------------------
Resolution: Done
The NamingService is no longer needed. A protocol independent service can be created using just the NamingBeanImpl:
<mbean code="org.jnp.server.NamingBeanImpl"
name="jboss:service=NamingBeanImpl"
xmbean-dd="resource:xmdesc/NamingBean-xmbean.xml">
</mbean>
> Cleanup the org.jboss.naming packaging
> --------------------------------------
>
> Key: JBAS-2249
> URL: http://jira.jboss.com/jira/browse/JBAS-2249
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Build System, Naming
> Reporter: Scott M Stark
> Assigned To: Scott M Stark
> Fix For: JBossAS-4.2.0.CR1
>
>
> Trying to use the jndi naming service in a minimal configuration requires the full jboss.jar. The naming classes should just be merged into the naming module and jnpserver.jar.
--
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, 4 months
[JBoss JIRA] Created: (JBAS-4049) Consider removing Subject mixin from FIELD granularity session Pojos
by Brian Stansberry (JIRA)
Consider removing Subject mixin from FIELD granularity session Pojos
--------------------------------------------------------------------
Key: JBAS-4049
URL: http://jira.jboss.com/jira/browse/JBAS-4049
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-5.0.0.Beta2, JBossAS-4.2.0.CR1
FIELD granularity replication uses a Subject mixin to the pojo to notify the session when an attribute is changed.
Consider dropping this in place of having the CacheListener detect the cache change and notify the session (via the JBossCacheManager).
Pro:
1) Simpler instrumentation. Classes instrumented a la the PojoCache examples (which don't add the Subject mixin) will work. The PojoCache examples can be the sole reference point for how to instrument classes.
2) For sure detects all changes in the pojo. Not sure if the Subject thing catches changes to collections of non-pojos.
Con:
Perhaps a bit slower, as the mechanism to look up and notify the session is more cumbersome.
--
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, 4 months
[JBoss JIRA] Created: (JBAS-4067) Collection modifications do not trigger FieldBasedClusterdSession version update
by Brian Stansberry (JIRA)
Collection modifications do not trigger FieldBasedClusterdSession version update
--------------------------------------------------------------------------------
Key: JBAS-4067
URL: http://jira.jboss.com/jira/browse/JBAS-4067
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Priority: Minor
Fix For: JBossAS-5.0.0.Beta2, JBossAS-4.2.0.CR1
FIELD granularity session replication relies on the AOP Subject/Observer pattern to detect changes in session attribute pojos and trigger a notification to the session object. The notification marks the session dirty, which in turn causes a replication of an updated version int for the session. Other nodes use the version int to detect if their locally cached session is out of sync with the distributed cache.
Using Subject/Observer breaks down with collections. The registration of the session as Observer happens as part of the setAttribute call. But if an object is added to a collection following that call, it will not be observed. Also, the collection itself is not normally aspectized.
Test case for this is FieldBasedTestCase.testCollectionModification().
Effect is not critical. The changed session content *is* replicated. The missing replication is the session version. This would only be an issue if session stickiness were not working correctly, and:
1) Session starts out on cluster node A, with last request leaving it at version, say, 5.
2) Session fails over to cluster node B. Modifications occur as described above, leaving session at version 6.
3) Session fails back over to cluster node A. Manager on A thinks its locally cached session is OK, so it doesn't read the version from the cache.
Fix is to use the CacheListener to note events in the cache and mark the session dirty. Leave the Subject/Observer solution in place in case the same POJO is stored in multiple session (in which case the cache listener event would only notify a single session.)
--
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, 4 months