12:02 p.m.
JBossCache classes fail serialization compatibility tests
---------------------------------------------------------
Key: JBAS-3772
URL: http://jira.jboss.com/jira/browse/JBAS-3772
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Reporter: Ryan Campbell
Assigned To: Brian Stansberry
Priority: Blocker
Fix For: JBossAS-4.0.5.GA
The serialVersionUID's changed for the following classes between JBoss 4.0.4 &
JBoss 4.0.5:
serialVersionUID error for org.jboss.cache.OptimisticTreeNode, 404 -5988969949899616983,
current: 7000622696587912654
serialVersionUID error for org.jboss.cache.ReplicationException, 404 1652498986885131620,
current: -2141504272926290430
Please confirm if these classes are serialized in any way, and if customers will
experience faults if running both versions of JBoss, or using 4.0.4 client jars against a
4.0.5 server.
--
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
11:10 a.m.
New subject: [JBoss JIRA] Updated: (JBAS-3772) JBossCache classes fail serialization compatibility tests
[ http://jira.jboss.com/jira/browse/JBAS-3772?page=all ]
Ryan Campbell updated JBAS-3772:
--------------------------------
Workaround Description: Upgrade the jboss-cache.jar in JBoss 4.0.4 or on any clients
to JBossCache1.4.0.SP1. This has been certified with JBoss 4.0.4.
Description:
The serialVersionUID's changed for the following classes between JBoss 4.0.4 &
JBoss 4.0.5:
serialVersionUID error for org.jboss.cache.OptimisticTreeNode, 404 -5988969949899616983,
current: 7000622696587912654
serialVersionUID error for org.jboss.cache.ReplicationException, 404 1652498986885131620,
current: -2141504272926290430
Impact:
The following are the scenarios where ReplicationException would be thrown and thereafter
could be serialized. None of the following affect the primary use of JBC in 4.0.x, which
is for HttpSession replication.
1) Cache A tries to replicate to Cache B. REPL_SYNC. Replication fails because B is
suspected at the JGroups layer, or because B doesn't reply before the configured
timeout. Cache A will throw ReplicationException which will propagate out of the cache and
into caller code. If that caller code then serializes the exception to a JVM with a
different JBC version on the classpath, you have a problem. Note that
ReplicationException won't be thrown with REPL_ASYNC, so not an issue there.
The likely caller code for that kind of scenario would be an EJB with a remote client.
EJB2 containers don't use JBC themselves; it would have to be a session bean impl
using JBC.
EJB3 containers do use JBC directly. The integration layer (StatefulTreeCache) will wrap
the ReplicationException in RuntimeException and rethrow it. It will then propagate to the
client. This would require standardizing on JBC 1.4.0.SP1.
This would usually only be a problem with a client in a 3rd JVM, not part of the cluster,
because EJB calls originating on a node in the cluster are going to be made locally.
2) REPL_SYNC. Cache A replicates a list of changes to Cache B as part of a prepare() call
(during tx commit). B starts a local tx to apply the changes. During the course of
applying the changes the local tx gets marked rollback only. B will detect this and throw
a ReplicationException which will be serialized and returned to A.
This is an obscure case. The JBC code itself won't ever mark the tx rollback only.
User code would have to implement TreeCacheListener and do something to access the tx
context. A contrived example of how this could happen would be a TreeCacheListener that
calls into a CMT REQUIRES session bean. The local tx would propagate and could be marked
for rollback. Not a common scenario.
3) OPTIMISTIC_SYNC. Same as #2, but optimistic locking was just an unsupported beta
feature in 1.2.4.SP2, so backwards compatibility is not supported.
was:
The serialVersionUID's changed for the following classes between JBoss 4.0.4 &
JBoss 4.0.5:
serialVersionUID error for org.jboss.cache.OptimisticTreeNode, 404 -5988969949899616983,
current: 7000622696587912654
serialVersionUID error for org.jboss.cache.ReplicationException, 404 1652498986885131620,
current: -2141504272926290430
Please confirm if these classes are serialized in any way, and if customers will
experience faults if running both versions of JBoss, or using 4.0.4 client jars against a
4.0.5 server.
Priority: Major (was: Blocker)
Workaround: [Workaround Exists]
JBossCache classes fail serialization compatibility tests
---------------------------------------------------------
Key: JBAS-3772
URL: http://jira.jboss.com/jira/browse/JBAS-3772
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Clustering
Reporter: Ryan Campbell
Assigned To: Brian Stansberry
Fix For: JBossAS-4.0.5.GA
The serialVersionUID's changed for the following classes between JBoss 4.0.4 &
JBoss 4.0.5:
serialVersionUID error for org.jboss.cache.OptimisticTreeNode, 404 -5988969949899616983,
current: 7000622696587912654
serialVersionUID error for org.jboss.cache.ReplicationException, 404 1652498986885131620,
current: -2141504272926290430
Impact:
The following are the scenarios where ReplicationException would be thrown and thereafter
could be serialized. None of the following affect the primary use of JBC in 4.0.x, which
is for HttpSession replication.
1) Cache A tries to replicate to Cache B. REPL_SYNC. Replication fails because B is
suspected at the JGroups layer, or because B doesn't reply before the configured
timeout. Cache A will throw ReplicationException which will propagate out of the cache and
into caller code. If that caller code then serializes the exception to a JVM with a
different JBC version on the classpath, you have a problem. Note that
ReplicationException won't be thrown with REPL_ASYNC, so not an issue there.
The likely caller code for that kind of scenario would be an EJB with a remote client.
EJB2 containers don't use JBC themselves; it would have to be a session bean impl
using JBC.
EJB3 containers do use JBC directly. The integration layer (StatefulTreeCache) will wrap
the ReplicationException in RuntimeException and rethrow it. It will then propagate to the
client. This would require standardizing on JBC 1.4.0.SP1.
This would usually only be a problem with a client in a 3rd JVM, not part of the cluster,
because EJB calls originating on a node in the cluster are going to be made locally.
2) REPL_SYNC. Cache A replicates a list of changes to Cache B as part of a prepare()
call (during tx commit). B starts a local tx to apply the changes. During the course of
applying the changes the local tx gets marked rollback only. B will detect this and throw
a ReplicationException which will be serialized and returned to A.
This is an obscure case. The JBC code itself won't ever mark the tx rollback only.
User code would have to implement TreeCacheListener and do something to access the tx
context. A contrived example of how this could happen would be a TreeCacheListener that
calls into a CMT REQUIRES session bean. The local tx would propagate and could be marked
for rollback. Not a common scenario.
3) OPTIMISTIC_SYNC. Same as #2, but optimistic locking was just an unsupported beta
feature in 1.2.4.SP2, so backwards compatibility is not supported.
--
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
1:56 p.m.
New subject: [JBoss JIRA] Resolved: (JBAS-3772) JBossCache classes fail serialization compatibility tests
[ http://jira.jboss.com/jira/browse/JBAS-3772?page=all ]
Ryan Campbell resolved JBAS-3772.
---------------------------------
Resolution: Deferred
JBossCache classes fail serialization compatibility tests
---------------------------------------------------------
Key: JBAS-3772
URL: http://jira.jboss.com/jira/browse/JBAS-3772
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Clustering
Reporter: Ryan Campbell
Assigned To: Brian Stansberry
Fix For: JBossAS-4.0.5.GA
The serialVersionUID's changed for the following classes between JBoss 4.0.4 &
JBoss 4.0.5:
serialVersionUID error for org.jboss.cache.OptimisticTreeNode, 404 -5988969949899616983,
current: 7000622696587912654
serialVersionUID error for org.jboss.cache.ReplicationException, 404 1652498986885131620,
current: -2141504272926290430
Impact:
The following are the scenarios where ReplicationException would be thrown and thereafter
could be serialized. None of the following affect the primary use of JBC in 4.0.x, which
is for HttpSession replication.
1) Cache A tries to replicate to Cache B. REPL_SYNC. Replication fails because B is
suspected at the JGroups layer, or because B doesn't reply before the configured
timeout. Cache A will throw ReplicationException which will propagate out of the cache and
into caller code. If that caller code then serializes the exception to a JVM with a
different JBC version on the classpath, you have a problem. Note that
ReplicationException won't be thrown with REPL_ASYNC, so not an issue there.
The likely caller code for that kind of scenario would be an EJB with a remote client.
EJB2 containers don't use JBC themselves; it would have to be a session bean impl
using JBC.
EJB3 containers do use JBC directly. The integration layer (StatefulTreeCache) will wrap
the ReplicationException in RuntimeException and rethrow it. It will then propagate to the
client. This would require standardizing on JBC 1.4.0.SP1.
This would usually only be a problem with a client in a 3rd JVM, not part of the cluster,
because EJB calls originating on a node in the cluster are going to be made locally.
2) REPL_SYNC. Cache A replicates a list of changes to Cache B as part of a prepare()
call (during tx commit). B starts a local tx to apply the changes. During the course of
applying the changes the local tx gets marked rollback only. B will detect this and throw
a ReplicationException which will be serialized and returned to A.
This is an obscure case. The JBC code itself won't ever mark the tx rollback only.
User code would have to implement TreeCacheListener and do something to access the tx
context. A contrived example of how this could happen would be a TreeCacheListener that
calls into a CMT REQUIRES session bean. The local tx would propagate and could be marked
for rollback. Not a common scenario.
3) OPTIMISTIC_SYNC. Same as #2, but optimistic locking was just an unsupported beta
feature in 1.2.4.SP2, so backwards compatibility is not supported.
--
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
1:56 p.m.
New subject: [JBoss JIRA] Updated: (JBAS-3772) JBossCache classes fail serialization compatibility tests
[ http://jira.jboss.com/jira/browse/JBAS-3772?page=all ]
Ryan Campbell updated JBAS-3772:
--------------------------------
Workaround Description:
Upgrade the jboss-cache.jar in JBoss 4.0.4 or on any clients to JBossCache1.4.0.GA. This
has been certified with JBoss 4.0.4.
This issue may also be present with JBoss 4.0.3SP1 and earlier. The same workaround
applies, but also requires that jboss-serialization.jar (JBoss Serialization 1.0.3.GA) be
added to the server/*/lib directory.
was:Upgrade the jboss-cache.jar in JBoss 4.0.4 or on any clients to JBossCache1.4.0.SP1.
This has been certified with JBoss 4.0.4.
JBossCache classes fail serialization compatibility tests
---------------------------------------------------------
Key: JBAS-3772
URL: http://jira.jboss.com/jira/browse/JBAS-3772
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Clustering
Reporter: Ryan Campbell
Assigned To: Brian Stansberry
Fix For: JBossAS-4.0.5.GA
The serialVersionUID's changed for the following classes between JBoss 4.0.4 &
JBoss 4.0.5:
serialVersionUID error for org.jboss.cache.OptimisticTreeNode, 404 -5988969949899616983,
current: 7000622696587912654
serialVersionUID error for org.jboss.cache.ReplicationException, 404 1652498986885131620,
current: -2141504272926290430
Impact:
The following are the scenarios where ReplicationException would be thrown and thereafter
could be serialized. None of the following affect the primary use of JBC in 4.0.x, which
is for HttpSession replication.
1) Cache A tries to replicate to Cache B. REPL_SYNC. Replication fails because B is
suspected at the JGroups layer, or because B doesn't reply before the configured
timeout. Cache A will throw ReplicationException which will propagate out of the cache and
into caller code. If that caller code then serializes the exception to a JVM with a
different JBC version on the classpath, you have a problem. Note that
ReplicationException won't be thrown with REPL_ASYNC, so not an issue there.
The likely caller code for that kind of scenario would be an EJB with a remote client.
EJB2 containers don't use JBC themselves; it would have to be a session bean impl
using JBC.
EJB3 containers do use JBC directly. The integration layer (StatefulTreeCache) will wrap
the ReplicationException in RuntimeException and rethrow it. It will then propagate to the
client. This would require standardizing on JBC 1.4.0.SP1.
This would usually only be a problem with a client in a 3rd JVM, not part of the cluster,
because EJB calls originating on a node in the cluster are going to be made locally.
2) REPL_SYNC. Cache A replicates a list of changes to Cache B as part of a prepare()
call (during tx commit). B starts a local tx to apply the changes. During the course of
applying the changes the local tx gets marked rollback only. B will detect this and throw
a ReplicationException which will be serialized and returned to A.
This is an obscure case. The JBC code itself won't ever mark the tx rollback only.
User code would have to implement TreeCacheListener and do something to access the tx
context. A contrived example of how this could happen would be a TreeCacheListener that
calls into a CMT REQUIRES session bean. The local tx would propagate and could be marked
for rollback. Not a common scenario.
3) OPTIMISTIC_SYNC. Same as #2, but optimistic locking was just an unsupported beta
feature in 1.2.4.SP2, so backwards compatibility is not supported.
--
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
6659
days inactive
6660
days old
3 comments
1 participants
participants (1)
-
Ryan Campbell (JIRA)