[JBoss JIRA] (ISPN-2822) Profile Infinispan when eviction enabled
by Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-2822?page=com.atlassian.jira.plugin.... ]
Anna Manukyan updated ISPN-2822:
--------------------------------
Attachment: File Store.zip
JDBC.zip
NO STORE.zip
FileStore.zip - contains the jprofiler snapshots when FileCacheStore was used;
JDBC.zip - is for JDBC CacheStore use;
No Store - is when the eviction is enabled, but no loaders are configured.
> Profile Infinispan when eviction enabled
> ----------------------------------------
>
> Key: ISPN-2822
> URL: https://issues.jboss.org/browse/ISPN-2822
> Project: Infinispan
> Issue Type: Task
> Reporter: Martin Gencur
> Assignee: Anna Manukyan
> Fix For: 5.3.0.Final
>
> Attachments: config.xml, Eviction Profiling Results.pdf, File Store.zip, JDBC.zip, NO STORE.zip
>
>
> Profile Infinispan for different eviction strategies (LRU, LIRS) and search for hot spots in the code (places where Infinispan spends most time when executing).
> Do this for two scenarios:
> 1) eviction enabled but no entries evicted (when the capacity is high)
> 2) eviction enabled and entries being evicted
--
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
11 years, 9 months
[JBoss JIRA] (ISPN-2989) View rollback never unlocks stateTransferLock
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2989?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-2989:
------------------------------------
If I remember correctly, we didn't unblock transactions on rollback because the coordinator was supposed to retry the cache view installation in less than 1 second, and re-acquiring the exclusive state transfer lock via StateTransferLock.blockNewTransactions was very expensive (because it had to wait on all the other running commands to finish).
When a cache view installation eventually finished successfully, it would unblock the transactions. If the coordinator died, another node was supposed to pick up the coordinator role and install the new view, releasing the state transfer lock at the end.
As such, I would close this issue as expected behaviour, and I would only try to fix the specific situations where the retry mechanism doesn't work properly.
> View rollback never unlocks stateTransferLock
> ---------------------------------------------
>
> Key: ISPN-2989
> URL: https://issues.jboss.org/browse/ISPN-2989
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.1.7.Final
> Reporter: Dennis Reed
> Assignee: Dan Berindei
>
> When a new cache view prepare fails and is rolled back (for example due to a TimeoutException), the state transfer lock is never released, causing all future operations to fail with a StateTransferInProgressException timeout.
--
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
11 years, 9 months
[JBoss JIRA] (ISPN-2898) Web Cache fails to start when multiple apps are trying to create it
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2898?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-2898:
------------------------------------
What is the lockAcquisitionTimeout on the caches being started? I think increasing that timeout should be a good enough workaround.
As for Infinispan code changes, we should add a global startupTimeout that should be used for the global cacheCreationLock acquisition instead of each cache's lockAcquisitionTimeout. Changing DefaultCacheManager.start() to start all the components in the global component registry, including the transport, would help as well.
> Web Cache fails to start when multiple apps are trying to create it
> -------------------------------------------------------------------
>
> Key: ISPN-2898
> URL: https://issues.jboss.org/browse/ISPN-2898
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.1.7.Final
> Reporter: Shay Matasaro
> Assignee: Dan Berindei
>
> When multiple apps are trying to create/connect to the web cache , the fist one get a lock on the cache manager, and prevents the others from starting it in a timely manner
--
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
11 years, 9 months
[JBoss JIRA] (ISPN-3003) Version 5.2.5.Final of infinispan-cdi test dependencies
by Gregor Kovač (JIRA)
[ https://issues.jboss.org/browse/ISPN-3003?page=com.atlassian.jira.plugin.... ]
Gregor Kovač updated ISPN-3003:
-------------------------------
Summary: Version 5.2.5.Final of infinispan-cdi test dependencies (was: Version 5.25 of infinispan-cdi test dependencies)
> Version 5.2.5.Final of infinispan-cdi test dependencies
> -------------------------------------------------------
>
> Key: ISPN-3003
> URL: https://issues.jboss.org/browse/ISPN-3003
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 5.2.5.Final
> Reporter: Gregor Kovač
> Assignee: Pete Muir
> Attachments: TestInfinispan.zip
>
>
> infinispan-cdi has a test dependency on infinispan-server-core:
> <dependency>
> <groupId>${project.groupId}</groupId>
> <artifactId>infinispan-server-core</artifactId>
> <type>test-jar</type>
> </dependency>
> which is wrong since it is missing the <scope>test</scope>, so every time I want to use infinispan-cdi in my projects I get:
> Failed to initialize ear modules: Unknown artifact type[test-jar]
--
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
11 years, 9 months
[JBoss JIRA] (ISPN-3003) Version 5.25 of infinispan-cdi test dependencies
by Gregor Kovač (JIRA)
[ https://issues.jboss.org/browse/ISPN-3003?page=com.atlassian.jira.plugin.... ]
Gregor Kovač updated ISPN-3003:
-------------------------------
Attachment: TestInfinispan.zip
Test application to demonstrate the issue
> Version 5.25 of infinispan-cdi test dependencies
> ------------------------------------------------
>
> Key: ISPN-3003
> URL: https://issues.jboss.org/browse/ISPN-3003
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 5.2.5.Final
> Reporter: Gregor Kovač
> Assignee: Pete Muir
> Attachments: TestInfinispan.zip
>
>
> infinispan-cdi has a test dependency on infinispan-server-core:
> <dependency>
> <groupId>${project.groupId}</groupId>
> <artifactId>infinispan-server-core</artifactId>
> <type>test-jar</type>
> </dependency>
> which is wrong since it is missing the <scope>test</scope>, so every time I want to use infinispan-cdi in my projects I get:
> Failed to initialize ear modules: Unknown artifact type[test-jar]
--
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
11 years, 9 months
[JBoss JIRA] (ISPN-3003) Version 5.25 of infinispan-cdi test dependencies
by Gregor Kovač (JIRA)
Gregor Kovač created ISPN-3003:
----------------------------------
Summary: Version 5.25 of infinispan-cdi test dependencies
Key: ISPN-3003
URL: https://issues.jboss.org/browse/ISPN-3003
Project: Infinispan
Issue Type: Bug
Components: CDI integration
Affects Versions: 5.2.5.Final
Reporter: Gregor Kovač
Assignee: Pete Muir
infinispan-cdi has a test dependency on infinispan-server-core:
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>infinispan-server-core</artifactId>
<type>test-jar</type>
</dependency>
which is wrong since it is missing the <scope>test</scope>, so every time I want to use infinispan-cdi in my projects I get:
Failed to initialize ear modules: Unknown artifact type[test-jar]
--
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
11 years, 9 months
[JBoss JIRA] (ISPN-2853) Asymmetric Transactional Clustered Cache causes NullPointerExceptions on non Clustered members
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2853?page=com.atlassian.jira.plugin.... ]
Adrian Nistor reassigned ISPN-2853:
-----------------------------------
Assignee: Adrian Nistor (was: Mircea Markus)
> Asymmetric Transactional Clustered Cache causes NullPointerExceptions on non Clustered members
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-2853
> URL: https://issues.jboss.org/browse/ISPN-2853
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.1.6.FINAL
> Reporter: William Burns
> Assignee: Adrian Nistor
> Fix For: 5.3.0.Final
>
> Attachments: Asymmetric.java
>
>
> We utilize Asymmetric clusters to prevent some unneeded communication between members that don't need to participate in the cluster cache. This works fine for the cache updates to not be sent to that node. However, I noticed that if you have this cache be transactional as well, then members that aren't clustered for this cache will get transaction prepare and commit messages which cause NullPointerExceptions since they don't have remote transactions configured for these nodes.
> Here is a sample test case that shows the error that is found.
> {code}
> 15164 [OOB-3,wburns-45269] TRACE org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher - Attempting to execute command: TxCompletionNotificationCommand{ xid=null, internalId=0, gtx=GlobalTransaction:<wburns-1521>:1:local, cacheName=asymmetric} [sender=wburns-1521]
> 15164 [OOB-3,wburns-45269] TRACE org.infinispan.remoting.InboundInvocationHandlerImpl - Calling perform() on TxCompletionNotificationCommand{ xid=null, internalId=0, gtx=GlobalTransaction:<wburns-1521>:1:local, cacheName=asymmetric}
> 15164 [OOB-3,wburns-45269] TRACE org.infinispan.commands.remote.recovery.TxCompletionNotificationCommand - Processing completed transaction GlobalTransaction:<wburns-1521>:1:local
> 15164 [OOB-3,wburns-45269] TRACE org.infinispan.remoting.InboundInvocationHandlerImpl - Exception executing command
> java.lang.NullPointerException
> at org.infinispan.transaction.TransactionTable.removeRemoteTransaction(TransactionTable.java:340)
> at org.infinispan.commands.remote.recovery.TxCompletionNotificationCommand.perform(TxCompletionNotificationCommand.java:92)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:127)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:136)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithRetry(InboundInvocationHandlerImpl.java:162)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:114)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
> at org.jgroups.JChannel.up(JChannel.java:716)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026)
> at org.jgroups.protocols.RSVP.up(RSVP.java:192)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:889)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:759)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:365)
> at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:602)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:177)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
> at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1180)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1728)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1710)
> 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)
> 15167 [OOB-3,wburns-45269] TRACE org.infinispan.remoting.InboundInvocationHandlerImpl - Unable to execute command, got invalid response ExceptionResponse
> 20170 [OOB-3,wburns-45269] TRACE org.infinispan.marshall.jboss.AbstractJBossMarshaller - Start unmarshaller after retrieving marshaller from thread local
> 20170 [OOB-3,wburns-45269] TRACE org.infinispan.marshall.VersionAwareMarshaller - Read version 510
> 20171 [OOB-3,wburns-45269] TRACE org.infinispan.marshall.jboss.AbstractJBossMarshaller - Start unmarshaller after retrieving marshaller from factory
> 20171 [OOB-3,wburns-45269] TRACE org.infinispan.marshall.VersionAwareMarshaller - Read version 510
> 20171 [OOB-3,wburns-45269] TRACE org.infinispan.marshall.jboss.AbstractJBossMarshaller - Stop unmarshaller
> 20171 [OOB-3,wburns-45269] TRACE org.infinispan.marshall.jboss.AbstractJBossMarshaller - Stop unmarshaller
> 20171 [OOB-3,wburns-45269] TRACE org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher - Attempting to execute command: TxCompletionNotificationCommand{ xid=null, internalId=0, gtx=GlobalTransaction:<wburns-1521>:2:local, cacheName=asymmetric} [sender=wburns-1521]
> 20171 [OOB-3,wburns-45269] TRACE org.infinispan.remoting.InboundInvocationHandlerImpl - Calling perform() on TxCompletionNotificationCommand{ xid=null, internalId=0, gtx=GlobalTransaction:<wburns-1521>:2:local, cacheName=asymmetric}
> 20171 [OOB-3,wburns-45269] TRACE org.infinispan.commands.remote.recovery.TxCompletionNotificationCommand - Processing completed transaction GlobalTransaction:<wburns-1521>:2:local
> 20171 [OOB-3,wburns-45269] TRACE org.infinispan.remoting.InboundInvocationHandlerImpl - Exception executing command
> java.lang.NullPointerException
> at org.infinispan.transaction.TransactionTable.removeRemoteTransaction(TransactionTable.java:340)
> at org.infinispan.commands.remote.recovery.TxCompletionNotificationCommand.perform(TxCompletionNotificationCommand.java:92)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:127)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:136)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithRetry(InboundInvocationHandlerImpl.java:162)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:114)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
> at org.jgroups.JChannel.up(JChannel.java:716)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026)
> at org.jgroups.protocols.RSVP.up(RSVP.java:192)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:889)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:759)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:365)
> at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:602)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:177)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
> at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1180)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1728)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1710)
> 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)
> 20173 [OOB-3,wburns-45269] TRACE org.infinispan.remoting.InboundInvocationHandlerImpl - Unable to execute command, got invalid response ExceptionResponse
> {code}
> As a side note, these NPE appear to not be propagated to the client, since they are sent with a response mode of GET_NONE. However we have a site that will every once in a while get the NPE sent back to the updating member which then causes a CacheException to occur forcing the original nodes transaction to be rolled back forcing a retry of the operation.
--
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
11 years, 9 months