[JBoss JIRA] (ISPN-2546) StateChunk with isLastChunk=true not sent when all entries are sent ahead
by Radim Vansa (JIRA)
Radim Vansa created ISPN-2546:
---------------------------------
Summary: StateChunk with isLastChunk=true not sent when all entries are sent ahead
Key: ISPN-2546
URL: https://issues.jboss.org/browse/ISPN-2546
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.2.0.Beta4
Reporter: Radim Vansa
Assignee: Mircea Markus
Priority: Blocker
During a state transfer the entries are sent batched to chunks. However, if all entries are sent in the non-last chunk, the list in entriesBySegment.get(segmentId) is empty. The code for sending last chunks is following:
{code:title=OutboundTransferTask.sendEntries(...)}
...
if (isLast) {
for (int segmentId : segments) {
List<InternalCacheEntry> entries = entriesBySegment.get(segmentId);
if (entries == null) {
chunks.add(new StateChunk(segmentId, InfinispanCollections.<InternalCacheEntry>emptyList(), true));
}
}
}
...
{code}
See that the check is {{entries == null}} but not {{entries.isEmpty()}}.
This causes to leave some segments unfinished, never finishing the state transfer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-2025) NPE in Externalizer on shutdown
by Michal Linhard (JIRA)
Michal Linhard created ISPN-2025:
------------------------------------
Summary: NPE in Externalizer on shutdown
Key: ISPN-2025
URL: https://issues.jboss.org/browse/ISPN-2025
Project: Infinispan
Issue Type: Bug
Components: Marshalling
Affects Versions: 5.1.4.FINAL
Reporter: Michal Linhard
Assignee: Galder Zamarreño
I get this what I get when I'm shutting down one of the clustered nodes (default config standalone-ha.xml) of JDG 6.0.0.ER7
{code}
09:50:25,505 WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] Problems unmarshalling remote command from byte buffer: java.lang.NullPointerException
at org.infinispan.marshall.jboss.ExternalizerTable.readObject(ExternalizerTable.java:222)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37) [jboss-marshalling-1.3.13.GA-redhat-1.jar:1.3.13.GA-redhat-1]
at org.infinispan.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:154)
at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:114)
at org.infinispan.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:85)
at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:50)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:200)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:543) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.JChannel.up(JChannel.java:716) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.RSVP.up(RSVP.java:179) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.FlowControl.up(FlowControl.java:400) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:889) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:793) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:365) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:602) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:177) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.Discovery.up(Discovery.java:359) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.stack.Protocol.up(Protocol.java:363) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.TP.passMessageUp(TP.java:1180) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1728) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1710) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]
{code}
I've ran the instances out of the box by this commands, binding them to virtual ips on my laptop:
{code}
server1/bin/standalone.sh -b 192.168.11.101 -c standalone-ha.xml -Djboss.bind.address.management=192.168.11.101 -Djboss.node.name=node1
server2/bin/standalone.sh -b 192.168.11.102 -c standalone-ha.xml -Djboss.bind.address.management=192.168.11.102 -Djboss.node.name=node2
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-2553) JBossMarshaller can be used before properly initialized
by Radim Vansa (JIRA)
Radim Vansa created ISPN-2553:
---------------------------------
Summary: JBossMarshaller can be used before properly initialized
Key: ISPN-2553
URL: https://issues.jboss.org/browse/ISPN-2553
Project: Infinispan
Issue Type: Bug
Components: Marshalling
Affects Versions: 5.2.0.Beta4
Reporter: Radim Vansa
Assignee: Galder Zamarreño
The {{JBossMarshaller}} can be used before its {{start()}} method is called. I've noticed that with replicated cache without transactions, an OOB thread can start demarshalling {{SingleRpcCommand}} in {{CacheRpcCommandExternalizer}} but when it tries to create a new unmarshaller (through {{AbstractJBossMarshaller.startObjectInput(...)}} and the {{marshallerTL.initialValue()}} the {{baseCfg}} configuration is not fully initialized yet and this results in creating marshallers in {{PerThreadInstanceHolder}} with {{objectTable == null}}. Then, objects are deserialized to {{null}}.
I have verified this by inserting some log messages into constructors and start method:
{code}
19:49:02,404 INFO [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (pool-1-thread-1) Creating AbstractJBossMarshaller with org.jboss.marshalling.MarshallingConfiguration@1d296aa3: classExternalizerFactor
y=<org.infinispan.marshall.jboss.SerializeWithExtFactory@a18024a> exceptionListener=<null> instanceCount=16 classCount=8 bufferSize=512 version=3
19:49:02,409 INFO [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (pool-1-thread-1) Creating JBossMarshaller org.infinispan.marshall.jboss.JBossMarshaller@2e3e4d73
19:49:02,410 INFO [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (pool-1-thread-1) Starting JBossMarshaller
{code}
and into the thread-local initialization and to {{getUnmarshaller()}} just before {{factory.createUnmarshaller}}:
{code}
19:49:02,410 ERROR [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (OOB-49,rvansa-22965) No object table in org.jboss.marshalling.MarshallingConfiguration@7c4ed0bc: classExternalizerFactory=<org.infinisp
an.marshall.jboss.SerializeWithExtFactory@a18024a> exceptionListener=<null> instanceCount=16 classCount=8 bufferSize=512 version=3, base is org.jboss.marshalling.MarshallingConfiguration@1d296aa3: classExternali
zerFactory=<org.infinispan.marshall.jboss.SerializeWithExtFactory@a18024a> exceptionListener=<null> instanceCount=16 classCount=8 bufferSize=512 version=3
19:49:02,453 ERROR [org.infinispan.marshall.jboss.AbstractJBossMarshaller] (OOB-49,rvansa-22965) Unmarshaller with cfg org.jboss.marshalling.MarshallingConfiguration@7c4ed0bc: classExternalizerFactory=<org.infin
ispan.marshall.jboss.SerializeWithExtFactory@a18024a> exceptionListener=<null> instanceCount=16 classCount=8 bufferSize=512 version=3
{code}
See that the timestamps for {{start()}} and thread-local initialization are same, and the base configuration ({{baseCfg}}) does not have {{objectTable}} initialized.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-2368) Two rebalances in parallel
by Radim Vansa (JIRA)
Radim Vansa created ISPN-2368:
---------------------------------
Summary: Two rebalances in parallel
Key: ISPN-2368
URL: https://issues.jboss.org/browse/ISPN-2368
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.2.0.Beta1
Reporter: Radim Vansa
Assignee: Mircea Markus
There is a bug in ClusterTopologyManagerImpl on line 353: the reference to cache topology is obtained prior to entering to the synchronized block, causing that two rebalances can start in parallel, effectively broking the state transfer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month