[JBoss JIRA] (ISPN-2032) MarshalledValue improvements
by Manik Surtani (JIRA)
Manik Surtani created ISPN-2032:
-----------------------------------
Summary: MarshalledValue improvements
Key: ISPN-2032
URL: https://issues.jboss.org/browse/ISPN-2032
Project: Infinispan
Issue Type: Enhancement
Components: Core API, Marshalling
Affects Versions: 5.1.4.FINAL
Reporter: Manik Surtani
Assignee: Galder Zamarreño
Fix For: 5.1.x, 5.2.0.ALPHA1, 5.2.0.FINAL
Improve MarshalledValues by using custom streams (instead of ExposedByteArrayOutputStream) which incurs a penalty of the JDK's BAOS constructor when allocating the initial byte array which is then thrown away. This patch also changes the signature of getRaw() to return the reusable buffer and prevent an unnecessary array copy.
--
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
11 years, 8 months
[JBoss JIRA] (ISPN-2096) Duplicate join requests break destabilizes the cluster
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2096:
----------------------------------
Summary: Duplicate join requests break destabilizes the cluster
Key: ISPN-2096
URL: https://issues.jboss.org/browse/ISPN-2096
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.1.5.FINAL
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 5.2.0.ALPHA1
When the coordinator receives a {{CacheViewControlCommand(REQUEST_JOIN)}} command from a node that's already a member of the cache, it should just ignore it. Currently it tries to install a new cache view with a duplicate member, and the new cache view installation fails with this error:
{noformat}
[13:37:08,442] [WARN] (CacheViewControlCommand.java:141) - ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=Demo, type=PREPARE_VIEW, sender=ppl-poz-nb0074/testy, newViewId=2, newMembers=[PPL-POZ-NB0074-33316, PPL-POZ-NB0074-33316], oldViewId=1, oldMembers=[PPL-POZ-NB0074-33316]}
java.lang.IllegalStateException: Cannot prepare new view CacheView{viewId=2, members=[PPL-POZ-NB0074-33316, PPL-POZ-NB0074-33316]} on cache Demo, we are currently preparing view CacheView{viewId=2, members=[PPL-POZ-NB0074-33316, PPL-POZ-NB0074-33316]}
at org.infinispan.cacheviews.CacheViewInfo.prepareView(CacheViewInfo.java:102)
at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:481)
at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
{noformat}
--
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
11 years, 8 months
[JBoss JIRA] (ISPN-1948) Invalid magic number
by Michal Linhard (JIRA)
Michal Linhard created ISPN-1948:
------------------------------------
Summary: Invalid magic number
Key: ISPN-1948
URL: https://issues.jboss.org/browse/ISPN-1948
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.1.3.CR1
Reporter: Michal Linhard
Assignee: Galder Zamarreño
Here we have the good old "invalid magic number" problem again (JDG 6.0.0.ER5 testing):
https://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-RESILIENCE/...
{code}
2012-03-26 15:18:43,524 253444 ERROR [org.jboss.smartfrog.edg.loaddriver.DriverNode] (Client-477:) Error doing PUT(key410977) to node node02 (lastOpTime 1 ms)
org.infinispan.client.hotrod.exceptions.InvalidResponseException:: Invalid magic number. Expected 0xa1 and received 0x0
at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:92)
at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:78)
at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:72)
at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:52)
at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:41)
at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:68)
at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:219)
at org.infinispan.CacheSupport.put(CacheSupport.java:52)
at org.jboss.qa.edg.adapter.HotRodAdapter$HotRodRemoteCacheAdapter.put(HotRodAdapter.java:249)
at org.jboss.qa.edg.adapter.HotRodAdapter$HotRodRemoteCacheAdapter.put(HotRodAdapter.java:234)
at org.jboss.smartfrog.edg.loaddriver.DriverNodeImpl$ClientThread.makeRequest(DriverNodeImpl.java:244)
at org.jboss.smartfrog.edg.loaddriver.DriverNodeImpl$ClientThread.run(DriverNodeImpl.java:375)
{code}
The exception repeats many times in the log and the "received" part of "Expected 0xa1 and received 0xXX" takes on different values.
Also happens in both PUT and GET operations.
--
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
11 years, 8 months
[JBoss JIRA] Created: (ISPN-1346) Transactional listeners method order problem
by Tomas Fecko (JIRA)
Transactional listeners method order problem
--------------------------------------------
Key: ISPN-1346
URL: https://issues.jboss.org/browse/ISPN-1346
Project: Infinispan
Issue Type: Bug
Components: Listeners
Affects Versions: 5.0.0.FINAL
Environment: fedora, windows
Reporter: Tomas Fecko
Assignee: Manik Surtani
I'm using listeners as from the @Listener javadoc examples. When I register listener on VM where the cache is and put items to it, the methods of my listener are called in this order:
@TransactionRegistered
startTransaction
@CacheEntryCreated
handleEvent
@CacheEntryCreated
handleEvent
@TransactionCompleted
endTransaction
which is as it should be, but when I register listener on second node, and put to cache in first node, methods on listener on second node are called in order:
handleEvent
handleEvent
startTransaction
endTransaction
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months