Re: [infinispan-dev] 5.0.0.CR5
I'll be mainly working on perf bechmark, so no deliverables from me. On 7 Jun 2011, at 17:19, Manik Surtani wrote: > Hi guys > > What do we have in store for CR5? What's been committed since CR4, and > what's in the pipeline for CR5? Does a release on Monday (13th) make sense? > > Cheers > Manik > -- > Manik Surtani > ma...@jboss.org > twitter.com/maniksurtani > > Lead, Infinispan > http://www.infinispan.org > > > > > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Defining new commands in modules
Hi Galder. An easy way to test is to use Manik's sample ( https://github.com/infinispan/infinispan-sample-module). Just change the id of BulkDeleteCommand to a core command id (like 22). Israel On Mon, Jun 6, 2011 at 7:29 AM, Galder Zamarreño wrote: > Israel, do you have a test case for this? > > On Jun 6, 2011, at 7:23 AM, Israel Lacerra wrote: > > > Manik, > > > > I think there is a little problem. If a custom command use the same id of > a core command...no exception is thrown. > > > > cheers > > > > Israel > > > > On Thu, Mar 10, 2011 at 9:25 PM, Israel Lacerra > wrote: > > Manik, > > > > It's look pretty fine to me and will solve my problem :) > > > > Israel > > > > On Tue, Mar 8, 2011 at 11:43 AM, Manik Surtani wrote: > > > > On 7 Mar 2011, at 13:02, Mircea Markus wrote: > > > > > Nice stuff! > > > > What do you think from the perspective of having to implement your own > commands, say for the continuous query prototype you did? Does it fit with > that model? > > > > Also, any more feedback from module authors that need this (looking at > Sanne and Israel!)? If not, I'll go ahead and issue a pull req... > > > > Cheers > > Manik > > > > -- > > Manik Surtani > > ma...@jboss.org > > twitter.com/maniksurtani > > > > Lead, Infinispan > > http://www.infinispan.org > > > > > > > > > > ___ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > > ___ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > > > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] discussion about impact of using TransactionSynchronizationRegistry in AS7...
I just hit this case locally. http://pastie.org/2035067 This is running with a hacked AS7, in the sense that IronJacamar (JBJCA-594), Hibernate JPA and the EJB3.1 container are registering TSR interposed synchronizations (https://github.com/scottmarlow/jboss-as/commits/jpa_tsr). This is for a 2lc unit test running in AS7 (non-clustered). org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion is already running, meaning that we cannot expect org.infinispan.transaction.TransactionTable.enlist() to succeed in its transaction.registerSynchronization(). Scott On 06/01/2011 03:49 PM, Scott Marlow wrote: > I posted a message on the as7-dev ml > (http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/002254.html), > about switching to use the TransactionSynchronizationRegistry. > > Does Infinispan currently register Transaction synchronization objects? >Does Infinispan currently register synchronizations via > TransactionSynchronizationRegistry (TSR)? > > I'm trying to get a sense for, what would happen if container managed > (AS7) session beans were registered with the active JTA transaction via > the TSR. > > If AS7 switches to use the TSR, I think that Infinispan might need to > ensure that it doesn't attempt to register with the TX too late. > > See http://pastie.org/1836698 for an example of what would happen if a > TSR synchronization object is already present and someone tries to > register a TX synchronization after tx.commit has been started. > > > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] 5.0.0.CR5
Hi guys What do we have in store for CR5? What's been committed since CR4, and what's in the pipeline for CR5? Does a release on Monday (13th) make sense? Cheers Manik -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] fixing eviction with transactions (critical for Hibernate Search)
So, I removed all locking logic from EvictionManagerImpl, all my issues are solved and all of core tests look like no worse than usual. I'm still hoping to understand if there was an important reason to lock, or I will send a pull request ;) Sanne 2011/6/7 Sanne Grinovero : > 2011/6/7 Mircea Markus : >> >> On 7 Jun 2011, at 13:13, Sanne Grinovero wrote: >> >> Hello all, >> in this scenario we have the Infinispan Lucene Directory using >> batching (DummyTransaction), eviction and passivation to keep the >> amount of memory being used for the index under control; I'm using >> LIRS but experienced the same issue with all other strategies. >> >> As you can see from the following stacktrace, the batching ends by >> sending a commit request, so the status of the transaction is 8 >> (STATUS_COMMITTING) in this context. >> The new data is stored in the DataContainer, then the >> BoundedConcurrentHashMap notifies the EvictionManagerImpl as it has to >> evict some values, and this one attempts to acquire a lock on the >> to-be-evicted keys (which are obviously not the same I'm trying to >> store). >> Acquiring this lock is an invalid operation as the transaction is in >> commit state, and so this operation fails with an exception. >> >> Thread [Hibernate Search: Directory writer-1] (Suspended (breakpoint >> at line 92 in LockManagerImpl)) >> LockManagerImpl.lockAndRecord(Object, InvocationContext) line: 92 >> EvictionManagerImpl.acquireLock(InvocationContext, Object) line: 210 >> EvictionManagerImpl.onEntryEviction(Object, InternalCacheEntry) line: 170 >> EvictionManagerImpl.onEntryEviction(Map) line: >> 162 >> DefaultDataContainer$DefaultEvictionListener.onEntryEviction(Map) >> line: 201 >> BoundedConcurrentHashMap$Segment.notifyEvictionListener(Set>) >> line: 1176 >> BoundedConcurrentHashMap$Segment.put(K, int, V, boolean) line: 1011 >> BoundedConcurrentHashMap.put(K, V) line: 1556 >> DefaultDataContainer.put(Object, Object, long, long) line: 148 >> ReadCommittedEntry.commit(DataContainer) line: 177 >> LockingInterceptor.commitEntry(CacheEntry, boolean) line: 389 >> LockingInterceptor.cleanupLocks(InvocationContext, boolean) line: 367 >> LockingInterceptor.visitCommitCommand(TxInvocationContext, >> CommitCommand) line: 98 >> CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 >> CacheStoreInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, >> VisitableCommand) line: 119 >> CacheStoreInterceptor.visitCommitCommand(TxInvocationContext, >> CommitCommand) line: 148 >> CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 >> CacheLoaderInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, >> VisitableCommand) line: 119 >> CacheLoaderInterceptor(CommandInterceptor).handleDefault(InvocationContext, >> VisitableCommand) line: 133 >> CacheLoaderInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, >> CommitCommand) line: 116 >> CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 >> NotificationInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, >> VisitableCommand) line: 119 >> NotificationInterceptor.visitCommitCommand(TxInvocationContext, >> CommitCommand) line: 56 >> CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 >> TxInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, >> VisitableCommand) line: 119 >> TxInterceptor.visitCommitCommand(TxInvocationContext, CommitCommand) line: >> 142 >> CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 >> CacheMgmtInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, >> VisitableCommand) line: 119 >> CacheMgmtInterceptor(CommandInterceptor).handleDefault(InvocationContext, >> VisitableCommand) line: 133 >> CacheMgmtInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, >> CommitCommand) line: 116 >> CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 >> InvocationContextInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, >> VisitableCommand) line: 119 >> InvocationContextInterceptor.handleAll(InvocationContext, >> VisitableCommand) line: 96 >> InvocationContextInterceptor.handleDefault(InvocationContext, >> VisitableCommand) line: 63 >> InvocationContextInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, >> CommitCommand) line: 116 >> CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 >> BatchingInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, >> VisitableCommand) line: 119 >> BatchingInterceptor.handleDefault(InvocationContext, >> VisitableCommand) line: 77 >> BatchingInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, >> CommitCommand) line: 116 >> CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 >> InterceptorChain.invoke(InvocationContext, VisitableCommand) line: 274 >> TransactionCoordinator.commit(LocalTransaction, boolean) line: 136 >> TransactionXaAdapter.commit
Re: [infinispan-dev] Transport related configuration timeouts
On 11-06-07 5:00 AM, Galder Zamarreño wrote: > On Jun 6, 2011, at 3:52 PM, Vladimir Blagojevic wrote: > >> It is, *however* repl timeout can cause state transfer to timeout due to >> locking of that processing lock in DistSync and that is why I think state >> transfer timeout has to be at least as long as repl timeout. > Well, the processing lock in DistSync is governed by the > distributedSyncTimeout, not the repl timeout. So, the relationships is really > between dist sync timeout and state transfer timeout. > > Btw, what is the relationship between dist sync timeout and repl timeout to > be precise? > > DistSync is used primarily during state transfer to stop incoming and > outgoing requests while state transfer is going on. This is a bit messy and I am not sure I admit! I'll report back when I have a more definite answer! ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] fixing eviction with transactions (critical for Hibernate Search)
2011/6/7 Mircea Markus : > > On 7 Jun 2011, at 13:13, Sanne Grinovero wrote: > > Hello all, > in this scenario we have the Infinispan Lucene Directory using > batching (DummyTransaction), eviction and passivation to keep the > amount of memory being used for the index under control; I'm using > LIRS but experienced the same issue with all other strategies. > > As you can see from the following stacktrace, the batching ends by > sending a commit request, so the status of the transaction is 8 > (STATUS_COMMITTING) in this context. > The new data is stored in the DataContainer, then the > BoundedConcurrentHashMap notifies the EvictionManagerImpl as it has to > evict some values, and this one attempts to acquire a lock on the > to-be-evicted keys (which are obviously not the same I'm trying to > store). > Acquiring this lock is an invalid operation as the transaction is in > commit state, and so this operation fails with an exception. > > Thread [Hibernate Search: Directory writer-1] (Suspended (breakpoint > at line 92 in LockManagerImpl)) > LockManagerImpl.lockAndRecord(Object, InvocationContext) line: 92 > EvictionManagerImpl.acquireLock(InvocationContext, Object) line: 210 > EvictionManagerImpl.onEntryEviction(Object, InternalCacheEntry) line: 170 > EvictionManagerImpl.onEntryEviction(Map) line: > 162 > DefaultDataContainer$DefaultEvictionListener.onEntryEviction(Map) > line: 201 > BoundedConcurrentHashMap$Segment.notifyEvictionListener(Set>) > line: 1176 > BoundedConcurrentHashMap$Segment.put(K, int, V, boolean) line: 1011 > BoundedConcurrentHashMap.put(K, V) line: 1556 > DefaultDataContainer.put(Object, Object, long, long) line: 148 > ReadCommittedEntry.commit(DataContainer) line: 177 > LockingInterceptor.commitEntry(CacheEntry, boolean) line: 389 > LockingInterceptor.cleanupLocks(InvocationContext, boolean) line: 367 > LockingInterceptor.visitCommitCommand(TxInvocationContext, > CommitCommand) line: 98 > CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 > CacheStoreInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, > VisitableCommand) line: 119 > CacheStoreInterceptor.visitCommitCommand(TxInvocationContext, > CommitCommand) line: 148 > CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 > CacheLoaderInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, > VisitableCommand) line: 119 > CacheLoaderInterceptor(CommandInterceptor).handleDefault(InvocationContext, > VisitableCommand) line: 133 > CacheLoaderInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, > CommitCommand) line: 116 > CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 > NotificationInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, > VisitableCommand) line: 119 > NotificationInterceptor.visitCommitCommand(TxInvocationContext, > CommitCommand) line: 56 > CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 > TxInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, > VisitableCommand) line: 119 > TxInterceptor.visitCommitCommand(TxInvocationContext, CommitCommand) line: > 142 > CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 > CacheMgmtInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, > VisitableCommand) line: 119 > CacheMgmtInterceptor(CommandInterceptor).handleDefault(InvocationContext, > VisitableCommand) line: 133 > CacheMgmtInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, > CommitCommand) line: 116 > CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 > InvocationContextInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, > VisitableCommand) line: 119 > InvocationContextInterceptor.handleAll(InvocationContext, > VisitableCommand) line: 96 > InvocationContextInterceptor.handleDefault(InvocationContext, > VisitableCommand) line: 63 > InvocationContextInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, > CommitCommand) line: 116 > CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 > BatchingInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, > VisitableCommand) line: 119 > BatchingInterceptor.handleDefault(InvocationContext, > VisitableCommand) line: 77 > BatchingInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, > CommitCommand) line: 116 > CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 > InterceptorChain.invoke(InvocationContext, VisitableCommand) line: 274 > TransactionCoordinator.commit(LocalTransaction, boolean) line: 136 > TransactionXaAdapter.commit(Xid, boolean) line: 124 > DummyTransaction.runCommitTx() line: 312 > DummyTransaction.commit() line: 99 > BatchModeTransactionManager(DummyBaseTransactionManager).commit() line: 97 > BatchContainer.resolveTransaction(BatchContainer$BatchDetails, > boolean) line: 131 > BatchContainer.endBatch(boolean, boolean) line: 108 > BatchContainer.endBatch(boolean) line: 93 >
Re: [infinispan-dev] fixing eviction with transactions (critical for Hibernate Search)
On 7 Jun 2011, at 13:13, Sanne Grinovero wrote: > Hello all, > in this scenario we have the Infinispan Lucene Directory using > batching (DummyTransaction), eviction and passivation to keep the > amount of memory being used for the index under control; I'm using > LIRS but experienced the same issue with all other strategies. > > As you can see from the following stacktrace, the batching ends by > sending a commit request, so the status of the transaction is 8 > (STATUS_COMMITTING) in this context. > The new data is stored in the DataContainer, then the > BoundedConcurrentHashMap notifies the EvictionManagerImpl as it has to > evict some values, and this one attempts to acquire a lock on the > to-be-evicted keys (which are obviously not the same I'm trying to > store). > Acquiring this lock is an invalid operation as the transaction is in > commit state, and so this operation fails with an exception. > > Thread [Hibernate Search: Directory writer-1] (Suspended (breakpoint > at line 92 in LockManagerImpl)) > LockManagerImpl.lockAndRecord(Object, InvocationContext) line: 92 > EvictionManagerImpl.acquireLock(InvocationContext, Object) line: 210 > EvictionManagerImpl.onEntryEviction(Object, InternalCacheEntry) line: > 170 > EvictionManagerImpl.onEntryEviction(Map) > line: 162 > > DefaultDataContainer$DefaultEvictionListener.onEntryEviction(Map) > line: 201 > > BoundedConcurrentHashMap$Segment.notifyEvictionListener(Set>) > line: 1176 > BoundedConcurrentHashMap$Segment.put(K, int, V, boolean) line: > 1011 > BoundedConcurrentHashMap.put(K, V) line: 1556 > DefaultDataContainer.put(Object, Object, long, long) line: 148 > ReadCommittedEntry.commit(DataContainer) line: 177 > LockingInterceptor.commitEntry(CacheEntry, boolean) line: 389 > LockingInterceptor.cleanupLocks(InvocationContext, boolean) line: 367 > LockingInterceptor.visitCommitCommand(TxInvocationContext, > CommitCommand) line: 98 > CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 > > CacheStoreInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, > VisitableCommand) line: 119 > CacheStoreInterceptor.visitCommitCommand(TxInvocationContext, > CommitCommand) line: 148 > CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 > > CacheLoaderInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, > VisitableCommand) line: 119 > > CacheLoaderInterceptor(CommandInterceptor).handleDefault(InvocationContext, > VisitableCommand) line: 133 > > CacheLoaderInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, > CommitCommand) line: 116 > CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 > > NotificationInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, > VisitableCommand) line: 119 > NotificationInterceptor.visitCommitCommand(TxInvocationContext, > CommitCommand) line: 56 > CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 > > TxInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, > VisitableCommand) line: 119 > TxInterceptor.visitCommitCommand(TxInvocationContext, CommitCommand) > line: 142 > CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 > > CacheMgmtInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, > VisitableCommand) line: 119 > > CacheMgmtInterceptor(CommandInterceptor).handleDefault(InvocationContext, > VisitableCommand) line: 133 > > CacheMgmtInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, > CommitCommand) line: 116 > CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 > > InvocationContextInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, > VisitableCommand) line: 119 > InvocationContextInterceptor.handleAll(InvocationContext, > VisitableCommand) line: 96 > InvocationContextInterceptor.handleDefault(InvocationContext, > VisitableCommand) line: 63 > > InvocationContextInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, > CommitCommand) line: 116 > CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 > > BatchingInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, > VisitableCommand) line: 119 > BatchingInterceptor.handleDefault(InvocationContext, > VisitableCommand) line: 77 > > BatchingInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, > CommitCommand) line: 116 > CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 > InterceptorChain.invoke(InvocationContext, VisitableCommand) line: 274 > TransactionCoordinator.commit(LocalTransaction, boolean) line: 136
[infinispan-dev] fixing eviction with transactions (critical for Hibernate Search)
Hello all, in this scenario we have the Infinispan Lucene Directory using batching (DummyTransaction), eviction and passivation to keep the amount of memory being used for the index under control; I'm using LIRS but experienced the same issue with all other strategies. As you can see from the following stacktrace, the batching ends by sending a commit request, so the status of the transaction is 8 (STATUS_COMMITTING) in this context. The new data is stored in the DataContainer, then the BoundedConcurrentHashMap notifies the EvictionManagerImpl as it has to evict some values, and this one attempts to acquire a lock on the to-be-evicted keys (which are obviously not the same I'm trying to store). Acquiring this lock is an invalid operation as the transaction is in commit state, and so this operation fails with an exception. Thread [Hibernate Search: Directory writer-1] (Suspended (breakpoint at line 92 in LockManagerImpl)) LockManagerImpl.lockAndRecord(Object, InvocationContext) line: 92 EvictionManagerImpl.acquireLock(InvocationContext, Object) line: 210 EvictionManagerImpl.onEntryEviction(Object, InternalCacheEntry) line: 170 EvictionManagerImpl.onEntryEviction(Map) line: 162 DefaultDataContainer$DefaultEvictionListener.onEntryEviction(Map) line: 201 BoundedConcurrentHashMap$Segment.notifyEvictionListener(Set>) line: 1176 BoundedConcurrentHashMap$Segment.put(K, int, V, boolean) line: 1011 BoundedConcurrentHashMap.put(K, V) line: 1556 DefaultDataContainer.put(Object, Object, long, long) line: 148 ReadCommittedEntry.commit(DataContainer) line: 177 LockingInterceptor.commitEntry(CacheEntry, boolean) line: 389 LockingInterceptor.cleanupLocks(InvocationContext, boolean) line: 367 LockingInterceptor.visitCommitCommand(TxInvocationContext, CommitCommand) line: 98 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 CacheStoreInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 CacheStoreInterceptor.visitCommitCommand(TxInvocationContext, CommitCommand) line: 148 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 CacheLoaderInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 CacheLoaderInterceptor(CommandInterceptor).handleDefault(InvocationContext, VisitableCommand) line: 133 CacheLoaderInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, CommitCommand) line: 116 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 NotificationInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 NotificationInterceptor.visitCommitCommand(TxInvocationContext, CommitCommand) line: 56 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 TxInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 TxInterceptor.visitCommitCommand(TxInvocationContext, CommitCommand) line: 142 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 CacheMgmtInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 CacheMgmtInterceptor(CommandInterceptor).handleDefault(InvocationContext, VisitableCommand) line: 133 CacheMgmtInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, CommitCommand) line: 116 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 InvocationContextInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 InvocationContextInterceptor.handleAll(InvocationContext, VisitableCommand) line: 96 InvocationContextInterceptor.handleDefault(InvocationContext, VisitableCommand) line: 63 InvocationContextInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, CommitCommand) line: 116 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 BatchingInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 BatchingInterceptor.handleDefault(InvocationContext, VisitableCommand) line: 77 BatchingInterceptor(AbstractVisitor).visitCommitCommand(TxInvocationContext, CommitCommand) line: 116 CommitCommand.acceptVisitor(InvocationContext, Visitor) line: 60 InterceptorChain.invoke(InvocationContext, VisitableCommand) line: 274 TransactionCoordinator.commit(LocalTransaction, boolean) line: 136 TransactionXaAdapter.commit(Xid, boolean) line: 124 DummyTransaction.runCommitTx() line: 312 DummyTransaction.commit() line: 9
Re: [infinispan-dev] Transport related configuration timeouts
On Jun 6, 2011, at 3:52 PM, Vladimir Blagojevic wrote: > On 11-06-06 6:06 AM, Galder Zamarreño wrote: >> Hmmm, I don't think the replication timeout has an effect during state >> transfer. Repl timeout is for individual rpc calls. >> > > It is, *however* repl timeout can cause state transfer to timeout due to > locking of that processing lock in DistSync and that is why I think state > transfer timeout has to be at least as long as repl timeout. Well, the processing lock in DistSync is governed by the distributedSyncTimeout, not the repl timeout. So, the relationships is really between dist sync timeout and state transfer timeout. Btw, what is the relationship between dist sync timeout and repl timeout to be precise? DistSync is used primarily during state transfer to stop incoming and outgoing requests while state transfer is going on. > >> Rehashing on the other hand is RPC based but the timeout is controlled by >> rehashRpcTimeout. Not sure what replTimeout has to do here. >> > > You are right. One can explicitly set rehashRpcTimeout to less than > replTimeout and that is ok. > >> Apart from that, another suggestion: >> >> flushLockTimeout < shutDownTimeout (async) < >> *cacheStopTimeout* > > Yep that one makes sense. Let's put this verification code in and things will > clear up further as we go along. > https://issues.jboss.org/browse/ISPN-1153 > > > > -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
