While working on ISPN-83 I realized that we have to form equality relationships between all our transport related timeouts and verify that the make sense as configuration instance is being processed. Alphabetically we have the following timeouts in our configuration elements: <async>: flushLockTimeout, shutdownTimeout <deadlockDetection>: spinDuration <hash>: rehashRpcTimeout <locking>:lockAcquisitionTimeout <singletonStore>:pushStateTimeout <stateRetrieval>:logFlushTimeout, timeout, initialRetryWaitTime <sync>:replTimeout <transaction>:cacheStopTimeout <transport>: distributedSyncTimout My suggestions so far: flushLockTimeout< shutdownTimeout spinDuration< lockAcquisitionTimeout< replTimeout< rehashRpcTimeout replTimeout< distributedSyncTimout< <stateRetrieval>:timeout Am I overseeing something? Lets hear your thoughts in the area of your expertize! Regards, Vladimir _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

looks good to me! What do you think should be done when they are not correct? Warning? Or even ConfigException perhaps?

On 2 Jun 2011, at 14:33, Vladimir Blagojevic wrote: > On 11-06-02 11:42 AM, Mircea Markus wrote: >> looks good to me! What do you think should be done when they are not correct? Warning? Or even ConfigException perhaps? > > My initial gut feeling would be ConfigException but I can see that being a bit harsh so maybe a scary warning is fine as well. I think a warning should be enough.

_______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Hmmm, I don't think the replication timeout has an effect during state transfer. Repl timeout is for individual rpc calls.

Rehashing on the other hand is RPC based but the timeout is controlled by rehashRpcTimeout. Not sure what replTimeout has to do here.

Apart from that, another suggestion: flushLockTimeout< shutDownTimeout (async)< *cacheStopTimeout*

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.