2:40 a.m.
Cache corrupted by 64bit windows member
---------------------------------------
Key: JBCACHE-1432
URL: https://jira.jboss.org/jira/browse/JBCACHE-1432
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 2.2.1.CR1
Environment: Windows 64bit OS with either 32 or 64bit jvm
in cluster with any linux OS (32 or 64bit) with any linux jvm.
Reporter: Bill Middleton
Assignee: Manik Surtani
Fix For: 3.1.0
Hello. We've run into some trouble in attempting to bring a 64bit windows machine into
an existing cluster. The cluster has (had) two 64bit linux members and was running fine
when we attempted to insert a 64bit windows machine into the cluster. Anytime the 64bit
windows machine wrote a node, the node was thereafter unreadable by either of the original
cluster members. Exceptions of the following form were thrown by the other members (will
attach stacktrace as comment)
I attempted to get help on this issue in the user forum, but it seems that nobody else is
running 64bit windows as a cluster member with other OS's in the cluster. I hope
perhaps someone can at least confirm this now formally?
--
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
2:42 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1432) Cache corrupted by 64bit windows member
[
https://jira.jboss.org/jira/browse/JBCACHE-1432?page=com.atlassian.jira.p...
]
Bill Middleton commented on JBCACHE-1432:
-----------------------------------------
Here is the stacktrace we see.
[ERROR] AdjListJDBCCacheLoader.reportAndRethrowError(): - Failed to load node for fqn
/IntegrationModules
java.lang.Exception: Unable to load to deserialize result:
at
org.jboss.cache.loader.AdjListJDBCCacheLoader.loadNode(AdjListJDBCCacheLoader.java:397)
at org.jboss.cache.loader.AdjListJDBCCacheLoader.get(AdjListJDBCCacheLoader.java:97)
at
org.jboss.cache.interceptors.CacheLoaderInterceptor.loadData(CacheLoaderInterceptor.java:530)
at
org.jboss.cache.interceptors.CacheLoaderInterceptor.loadNode(CacheLoaderInterceptor.java:408)
[...]
Caused by:java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.readInt(Unknown Source)
at java.io.ObjectInputStream.readInt(Unknown Source)
at
org.jboss.cache.marshall.CacheMarshaller200.populateFromStream(CacheMarshaller200.java:740)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallHashMap(CacheMarshaller200.java:705)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:564)
at
org.jboss.cache.marshall.CacheMarshaller200.objectFromObjectStream(CacheMarshaller200.java:147)
at
org.jboss.cache.marshall.VersionAwareMarshaller.objectFromStream(VersionAwareMarshaller.java:176)
at
org.jboss.cache.loader.AdjListJDBCCacheLoader.unmarshall(AdjListJDBCCacheLoader.java:702)
at
org.jboss.cache.loader.AdjListJDBCCacheLoader.loadNode(AdjListJDBCCacheLoader.java:392)
Cache corrupted by 64bit windows member
---------------------------------------
Key: JBCACHE-1432
URL: https://jira.jboss.org/jira/browse/JBCACHE-1432
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 2.2.1.CR1
Environment: Windows 64bit OS with either 32 or 64bit jvm
in cluster with any linux OS (32 or 64bit) with any linux jvm.
Reporter: Bill Middleton
Assignee: Manik Surtani
Fix For: 3.1.0
Hello. We've run into some trouble in attempting to bring a 64bit windows machine
into an existing cluster. The cluster has (had) two 64bit linux members and was running
fine when we attempted to insert a 64bit windows machine into the cluster. Anytime the
64bit windows machine wrote a node, the node was thereafter unreadable by either of the
original cluster members. Exceptions of the following form were thrown by the other
members (will attach stacktrace as comment)
I attempted to get help on this issue in the user forum, but it seems that nobody else is
running 64bit windows as a cluster member with other OS's in the cluster. I hope
perhaps someone can at least confirm this now formally?
--
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
11:18 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1432) Cache corrupted by 64bit windows member
[
https://jira.jboss.org/jira/browse/JBCACHE-1432?page=com.atlassian.jira.p...
]
Bill Middleton commented on JBCACHE-1432:
-----------------------------------------
As reported on the forum, we've now confirmed that this bug is not related to
cacheloader. We turned off cacheloader and got the exact same problem.
Cache corrupted by 64bit windows member
---------------------------------------
Key: JBCACHE-1432
URL: https://jira.jboss.org/jira/browse/JBCACHE-1432
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 2.2.1.CR1
Environment: Windows 64bit OS with either 32 or 64bit jvm
in cluster with any linux OS (32 or 64bit) with any linux jvm.
Reporter: Bill Middleton
Assignee: Manik Surtani
Fix For: 3.1.0
Hello. We've run into some trouble in attempting to bring a 64bit windows machine
into an existing cluster. The cluster has (had) two 64bit linux members and was running
fine when we attempted to insert a 64bit windows machine into the cluster. Anytime the
64bit windows machine wrote a node, the node was thereafter unreadable by either of the
original cluster members. Exceptions of the following form were thrown by the other
members (will attach stacktrace as comment)
I attempted to get help on this issue in the user forum, but it seems that nobody else is
running 64bit windows as a cluster member with other OS's in the cluster. I hope
perhaps someone can at least confirm this now formally?
--
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
1:43 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1432) Cache corrupted by 64bit windows member
[
https://jira.jboss.org/jira/browse/JBCACHE-1432?page=com.atlassian.jira.p...
]
Bill Middleton commented on JBCACHE-1432:
-----------------------------------------
Neglected to provide the stacktrace without cacheloader enabled...
30 [ERROR] RequestCorrelator.receiveMessage(): - failed unmarshalling buffer into return
value
java.io.EOFException
at java.io.DataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream.readShort(Unknown Source)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:536)
at
org.jboss.cache.marshall.CacheMarshaller200.objectFromObjectStream(CacheMarshaller200.java:147)
at
org.jboss.cache.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:154)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:365)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:746)
at org.jgroups.JChannel.up(JChannel.java:1151)
at org.jgroups.mux.Multiplexer$Task.run(Multiplexer.java:1036)
at org.jgroups.mux.Multiplexer$ExecuteTask.run(Multiplexer.java:1060)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
java.lang.RuntimeException: java.io.EOFException
at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3951)
at org.jboss.cache.CacheImpl.remove(CacheImpl.java:1637)
at org.jboss.cache.CacheImpl.removeNode(CacheImpl.java:4376)
at org.jboss.cache.UnversionedNode.removeChild(UnversionedNode.java:489)
at com.bbvd.b2.pluglet.nodemanager.NodeManager.remove(NodeManager.java:989)
at
com.bbvd.b2.pluglet.nodemanager.NodeManager$1.subscriptionTerminated(NodeManager.java:1684)
at
edu.emory.mathcs.revents.toolkit.ReventViews$SubtreeEventProvider$SubtreeNotifier.subscriptionTerminated(ReventViews.java:609)
at
edu.emory.mathcs.revents.impl.srv.impl.EventProviderImpl$NotifierEntry.subscriptionTerminated(EventProviderImpl.java:1225)
at
edu.emory.mathcs.revents.impl.srv.impl.EventProviderImpl$TopicEntry.deleteSubscription(EventProviderImpl.java:561)
at
edu.emory.mathcs.revents.impl.srv.impl.SubscriptionImpl.terminatedByChannel(SubscriptionImpl.java:274)
at
edu.emory.mathcs.revents.impl.srv.impl.EventChannelSrvImpl.terminateSubscription(EventChannelSrvImpl.java:212)
at
edu.emory.mathcs.revents.toolkit.ReventViews$SubtreeEventChannelSrv.terminateSubscription(ReventViews.java:897)
at com.bbvd.b2.pluglet.nodemanager.NodeManager.unsubscribe(NodeManager.java:1266)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at edu.emory.mathcs.h2o.server.impl.H2OInterceptor.callNoCheck(H2OInterceptor.java:190)
at edu.emory.mathcs.h2o.server.impl.H2OInterceptor.doInvoke(H2OInterceptor.java:166)
at edu.emory.mathcs.h2o.server.impl.H2OInterceptor.access$000(H2OInterceptor.java:64)
at edu.emory.mathcs.h2o.server.impl.H2OInterceptor$1.call(H2OInterceptor.java:140)
at
edu.emory.mathcs.h2o.server.impl.ThreadController$ThreadControllerList.perform(ThreadController.java:537)
at edu.emory.mathcs.h2o.server.impl.H2OInterceptor.invoke(H2OInterceptor.java:138)
at
edu.emory.mathcs.rmix.InvocationTarget$MethodInvoker.invoke(InvocationTarget.java:396)
at
edu.emory.mathcs.rmix.spi.jrmpx.JrmpxServerRefImpl.doInvoke(JrmpxServerRefImpl.java:333)
at
edu.emory.mathcs.rmix.spi.jrmpx.JrmpxServerRefImpl.invoke(JrmpxServerRefImpl.java:325)
at
edu.emory.mathcs.rmix.spi.jrmpx.JrmpxServerRefImpl.invoke(JrmpxServerRefImpl.java:274)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException
at java.io.DataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream.readShort(Unknown Source)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:536)
at
org.jboss.cache.marshall.CacheMarshaller200.objectFromObjectStream(CacheMarshaller200.java:147)
at
org.jboss.cache.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:154)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:365)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:746)
at org.jgroups.JChannel.up(JChannel.java:1151)
at org.jgroups.mux.Multiplexer$Task.run(Multiplexer.java:1036)
at org.jgroups.mux.Multiplexer$ExecuteTask.run(Multiplexer.java:1060)
... 3 more
Fri Nov 07 16:08:31 CET 2008 [SEVERE] Problem removing the subscription: bill :
NodeManager.remove; nested exception is:
java.io.EOFException
java.rmi.RemoteException: NodeManager.remove; nested exception is:
java.io.EOFException
at com.bbvd.b2.pluglet.nodemanager.NodeManager.remove(NodeManager.java:1005)
at
com.bbvd.b2.pluglet.nodemanager.NodeManager$1.subscriptionTerminated(NodeManager.java:1684)
at
edu.emory.mathcs.revents.toolkit.ReventViews$SubtreeEventProvider$SubtreeNotifier.subscriptionTerminated(ReventViews.java:609)
at
edu.emory.mathcs.revents.impl.srv.impl.EventProviderImpl$NotifierEntry.subscriptionTerminated(EventProviderImpl.java:1225)
at
edu.emory.mathcs.revents.impl.srv.impl.EventProviderImpl$TopicEntry.deleteSubscription(EventProviderImpl.java:561)
at
edu.emory.mathcs.revents.impl.srv.impl.SubscriptionImpl.terminatedByChannel(SubscriptionImpl.java:274)
at
edu.emory.mathcs.revents.impl.srv.impl.EventChannelSrvImpl.terminateSubscription(EventChannelSrvImpl.java:212)
at
edu.emory.mathcs.revents.toolkit.ReventViews$SubtreeEventChannelSrv.terminateSubscription(ReventViews.java:897)
at com.bbvd.b2.pluglet.nodemanager.NodeManager.unsubscribe(NodeManager.java:1266)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at edu.emory.mathcs.h2o.server.impl.H2OInterceptor.callNoCheck(H2OInterceptor.java:190)
at edu.emory.mathcs.h2o.server.impl.H2OInterceptor.doInvoke(H2OInterceptor.java:166)
at edu.emory.mathcs.h2o.server.impl.H2OInterceptor.access$000(H2OInterceptor.java:64)
at edu.emory.mathcs.h2o.server.impl.H2OInterceptor$1.call(H2OInterceptor.java:140)
at
edu.emory.mathcs.h2o.server.impl.ThreadController$ThreadControllerList.perform(ThreadController.java:537)
at edu.emory.mathcs.h2o.server.impl.H2OInterceptor.invoke(H2OInterceptor.java:138)
at
edu.emory.mathcs.rmix.InvocationTarget$MethodInvoker.invoke(InvocationTarget.java:396)
at
edu.emory.mathcs.rmix.spi.jrmpx.JrmpxServerRefImpl.doInvoke(JrmpxServerRefImpl.java:333)
at
edu.emory.mathcs.rmix.spi.jrmpx.JrmpxServerRefImpl.invoke(JrmpxServerRefImpl.java:325)
at
edu.emory.mathcs.rmix.spi.jrmpx.JrmpxServerRefImpl.invoke(JrmpxServerRefImpl.java:274)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException
at java.io.DataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream.readShort(Unknown Source)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:536)
at
org.jboss.cache.marshall.CacheMarshaller200.objectFromObjectStream(CacheMarshaller200.java:147)
at
org.jboss.cache.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:154)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:365)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:746)
at org.jgroups.JChannel.up(JChannel.java:1151)
at org.jgroups.mux.Multiplexer$Task.run(Multiplexer.java:1036)
at org.jgroups.mux.Multiplexer$ExecuteTask.run(Multiplexer.java:1060)
... 3 more
Fri Nov 07 16:08:31 CET 2008 [FINE] NodeManager: bill is unsubscribing from node
/Users/bill
Fri Nov 07 16:08:31 CET 2008 [FINE] NodeManager: bill is unsubscribing from node
/Systems/B2/IntegrationModules
Fri Nov 07 16:08:31 CET 2008 [FINE] NodeManager: bill is unsubscribing from node
/Systems
Fri Nov 07 16:08:31 CET 2008 [FINE] NodeManager: bill is unsubscribing from node
/IntegrationModules
33097 [ERROR] InactiveRegionAwareRpcDispatcher.handle(): - exception marshalling object
java.io.EOFException
at java.io.DataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream.readShort(Unknown Source)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:582)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallMethodCall(CacheMarshaller200.java:642)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:541)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallMethodCall(CacheMarshaller200.java:642)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:541)
at
org.jboss.cache.marshall.CacheMarshaller200.objectFromObjectStream(CacheMarshaller200.java:147)
at
org.jboss.cache.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:154)
at
org.jboss.cache.marshall.InactiveRegionAwareRpcDispatcher.handle(InactiveRegionAwareRpcDispatcher.java:50)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:624)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:533)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:365)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:746)
at org.jgroups.JChannel.up(JChannel.java:1151)
at org.jgroups.mux.Multiplexer$Task.run(Multiplexer.java:1036)
at org.jgroups.mux.Multiplexer$ExecuteTask.run(Multiplexer.java:1060)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
33177 [ERROR] InactiveRegionAwareRpcDispatcher.handle(): - exception marshalling object
java.io.EOFException
at java.io.DataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream.readShort(Unknown Source)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:582)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallMethodCall(CacheMarshaller200.java:642)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:541)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallMethodCall(CacheMarshaller200.java:642)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:541)
at
org.jboss.cache.marshall.CacheMarshaller200.objectFromObjectStream(CacheMarshaller200.java:147)
at
org.jboss.cache.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:154)
at
org.jboss.cache.marshall.InactiveRegionAwareRpcDispatcher.handle(InactiveRegionAwareRpcDispatcher.java:50)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:624)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:533)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:365)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:746)
at org.jgroups.JChannel.up(JChannel.java:1151)
at org.jgroups.mux.Multiplexer$Task.run(Multiplexer.java:1036)
at org.jgroups.mux.Multiplexer$ExecuteTask.run(Multiplexer.java:1060)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
41419 [ERROR] InactiveRegionAwareRpcDispatcher.handle(): - exception marshalling object
java.io.EOFException
at java.io.DataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream.readShort(Unknown Source)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:582)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallMethodCall(CacheMarshaller200.java:642)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:541)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallMethodCall(CacheMarshaller200.java:642)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:541)
at
org.jboss.cache.marshall.CacheMarshaller200.objectFromObjectStream(CacheMarshaller200.java:147)
at
org.jboss.cache.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:154)
at
org.jboss.cache.marshall.InactiveRegionAwareRpcDispatcher.handle(InactiveRegionAwareRpcDispatcher.java:50)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:624)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:533)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:365)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:746)
at org.jgroups.JChannel.up(JChannel.java:1151)
at org.jgroups.mux.Multiplexer$Task.run(Multiplexer.java:1036)
at org.jgroups.mux.Multiplexer$ExecuteTask.run(Multiplexer.java:1060)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
41529 [ERROR] InactiveRegionAwareRpcDispatcher.handle(): - exception marshalling object
java.io.EOFException
at java.io.DataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream.readShort(Unknown Source)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:582)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallMethodCall(CacheMarshaller200.java:642)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:541)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallMethodCall(CacheMarshaller200.java:642)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:541)
at
org.jboss.cache.marshall.CacheMarshaller200.objectFromObjectStream(CacheMarshaller200.java:147)
at
org.jboss.cache.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:154)
at
org.jboss.cache.marshall.InactiveRegionAwareRpcDispatcher.handle(InactiveRegionAwareRpcDispatcher.java:50)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:624)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:533)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:365)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:746)
at org.jgroups.JChannel.up(JChannel.java:1151)
at org.jgroups.mux.Multiplexer$Task.run(Multiplexer.java:1036)
at org.jgroups.mux.Multiplexer$ExecuteTask.run(Multiplexer.java:1060)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
91351 [ERROR] InactiveRegionAwareRpcDispatcher.handle(): - exception marshalling object
java.io.EOFException
at java.io.DataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream.readShort(Unknown Source)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:582)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallMethodCall(CacheMarshaller200.java:642)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:541)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallMethodCall(CacheMarshaller200.java:642)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:541)
at
org.jboss.cache.marshall.CacheMarshaller200.objectFromObjectStream(CacheMarshaller200.java:147)
at
org.jboss.cache.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:154)
at
org.jboss.cache.marshall.InactiveRegionAwareRpcDispatcher.handle(InactiveRegionAwareRpcDispatcher.java:50)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:624)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:533)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:365)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:746)
at org.jgroups.JChannel.up(JChannel.java:1151)
at org.jgroups.mux.Multiplexer$Task.run(Multiplexer.java:1036)
at org.jgroups.mux.Multiplexer$ExecuteTask.run(Multiplexer.java:1060)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
91411 [ERROR] InactiveRegionAwareRpcDispatcher.handle(): - exception marshalling object
java.io.EOFException
at java.io.DataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream.readShort(Unknown Source)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:582)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallMethodCall(CacheMarshaller200.java:642)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:541)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallMethodCall(CacheMarshaller200.java:642)
at
org.jboss.cache.marshall.CacheMarshaller200.unmarshallObject(CacheMarshaller200.java:541)
at
org.jboss.cache.marshall.CacheMarshaller200.objectFromObjectStream(CacheMarshaller200.java:147)
at
org.jboss.cache.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:154)
at
org.jboss.cache.marshall.InactiveRegionAwareRpcDispatcher.handle(InactiveRegionAwareRpcDispatcher.java:50)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:624)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:533)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:365)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:746)
at org.jgroups.JChannel.up(JChannel.java:1151)
at org.jgroups.mux.Multiplexer$Task.run(Multiplexer.java:1036)
at org.jgroups.mux.Multiplexer$ExecuteTask.run(Multiplexer.java:1060)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Cache corrupted by 64bit windows member
---------------------------------------
Key: JBCACHE-1432
URL: https://jira.jboss.org/jira/browse/JBCACHE-1432
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 2.2.1.CR1
Environment: Windows 64bit OS with either 32 or 64bit jvm
in cluster with any linux OS (32 or 64bit) with any linux jvm.
Reporter: Bill Middleton
Assignee: Manik Surtani
Fix For: 3.1.0
Hello. We've run into some trouble in attempting to bring a 64bit windows machine
into an existing cluster. The cluster has (had) two 64bit linux members and was running
fine when we attempted to insert a 64bit windows machine into the cluster. Anytime the
64bit windows machine wrote a node, the node was thereafter unreadable by either of the
original cluster members. Exceptions of the following form were thrown by the other
members (will attach stacktrace as comment)
I attempted to get help on this issue in the user forum, but it seems that nobody else is
running 64bit windows as a cluster member with other OS's in the cluster. I hope
perhaps someone can at least confirm this now formally?
--
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
6:31 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1432) Cache corrupted by 64bit windows member
[
https://jira.jboss.org/jira/browse/JBCACHE-1432?page=com.atlassian.jira.p...
]
Bela Ban commented on JBCACHE-1432:
-----------------------------------
I created https://jira.jboss.org/jira/browse/JGRP-856 to make sure we don't rely on
byte ordering issues (big versus little endian) or 32 bit vs 64 bit issues. This is for
JGroups only though, we should create a corresponding issue for JBC
Cache corrupted by 64bit windows member
---------------------------------------
Key: JBCACHE-1432
URL: https://jira.jboss.org/jira/browse/JBCACHE-1432
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 2.2.1.CR1
Environment: Windows 64bit OS with either 32 or 64bit jvm
in cluster with any linux OS (32 or 64bit) with any linux jvm.
Reporter: Bill Middleton
Assignee: Manik Surtani
Fix For: 3.1.0
Hello. We've run into some trouble in attempting to bring a 64bit windows machine
into an existing cluster. The cluster has (had) two 64bit linux members and was running
fine when we attempted to insert a 64bit windows machine into the cluster. Anytime the
64bit windows machine wrote a node, the node was thereafter unreadable by either of the
original cluster members. Exceptions of the following form were thrown by the other
members (will attach stacktrace as comment)
I attempted to get help on this issue in the user forum, but it seems that nobody else is
running 64bit windows as a cluster member with other OS's in the cluster. I hope
perhaps someone can at least confirm this now formally?
--
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
7:57 a.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-1432) Cache corrupted by 64bit windows member
[
https://jira.jboss.org/jira/browse/JBCACHE-1432?page=com.atlassian.jira.p...
]
Manik Surtani updated JBCACHE-1432:
-----------------------------------
Component/s: (was: Cache loaders)
Labels: serialization (was: )
Cache corrupted by 64bit windows member
---------------------------------------
Key: JBCACHE-1432
URL: https://jira.jboss.org/jira/browse/JBCACHE-1432
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 2.2.1.CR1
Environment: Windows 64bit OS with either 32 or 64bit jvm
in cluster with any linux OS (32 or 64bit) with any linux jvm.
Reporter: Bill Middleton
Assignee: Manik Surtani
Fix For: 3.1.0
Hello. We've run into some trouble in attempting to bring a 64bit windows machine
into an existing cluster. The cluster has (had) two 64bit linux members and was running
fine when we attempted to insert a 64bit windows machine into the cluster. Anytime the
64bit windows machine wrote a node, the node was thereafter unreadable by either of the
original cluster members. Exceptions of the following form were thrown by the other
members (will attach stacktrace as comment)
I attempted to get help on this issue in the user forum, but it seems that nobody else is
running 64bit windows as a cluster member with other OS's in the cluster. I hope
perhaps someone can at least confirm this now formally?
--
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
9:28 a.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-1432) Cache corrupted by 64bit windows member
[
https://jira.jboss.org/jira/browse/JBCACHE-1432?page=com.atlassian.jira.p...
]
Manik Surtani updated JBCACHE-1432:
-----------------------------------
Fix Version/s: 3.2.0.GA
(was: 3.1.0.GA)
Cache corrupted by 64bit windows member
---------------------------------------
Key: JBCACHE-1432
URL: https://jira.jboss.org/jira/browse/JBCACHE-1432
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 2.2.1.CR1
Environment: Windows 64bit OS with either 32 or 64bit jvm
in cluster with any linux OS (32 or 64bit) with any linux jvm.
Reporter: Bill Middleton
Assignee: Manik Surtani
Fix For: 3.2.0.GA
Hello. We've run into some trouble in attempting to bring a 64bit windows machine
into an existing cluster. The cluster has (had) two 64bit linux members and was running
fine when we attempted to insert a 64bit windows machine into the cluster. Anytime the
64bit windows machine wrote a node, the node was thereafter unreadable by either of the
original cluster members. Exceptions of the following form were thrown by the other
members (will attach stacktrace as comment)
I attempted to get help on this issue in the user forum, but it seems that nobody else is
running 64bit windows as a cluster member with other OS's in the cluster. I hope
perhaps someone can at least confirm this now formally?
--
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
5:48 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1432) Cache corrupted by 64bit windows member
[
https://jira.jboss.org/jira/browse/JBCACHE-1432?page=com.atlassian.jira.p...
]
Bill Middleton commented on JBCACHE-1432:
-----------------------------------------
See
http://sourceforge.net/mailarchive/forum.php?thread_name=3da2061200026bfe...
seems others are finally seeing 64bit troubles as well. (Although this seems a jgroups
issue, or perhaps even lower, now)
Cache corrupted by 64bit windows member
---------------------------------------
Key: JBCACHE-1432
URL: https://jira.jboss.org/jira/browse/JBCACHE-1432
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 2.2.1.CR1
Environment: Windows 64bit OS with either 32 or 64bit jvm
in cluster with any linux OS (32 or 64bit) with any linux jvm.
Reporter: Bill Middleton
Assignee: Manik Surtani
Fix For: 3.2.0.GA
Hello. We've run into some trouble in attempting to bring a 64bit windows machine
into an existing cluster. The cluster has (had) two 64bit linux members and was running
fine when we attempted to insert a 64bit windows machine into the cluster. Anytime the
64bit windows machine wrote a node, the node was thereafter unreadable by either of the
original cluster members. Exceptions of the following form were thrown by the other
members (will attach stacktrace as comment)
I attempted to get help on this issue in the user forum, but it seems that nobody else is
running 64bit windows as a cluster member with other OS's in the cluster. I hope
perhaps someone can at least confirm this now formally?
--
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
5629
days inactive
5902
days old
jbosscache-issues@lists.jboss.org
7 comments
3 participants
participants (3)
-
Bela Ban (JIRA) -
Bill Middleton (JIRA)
-
Manik Surtani (JIRA)