[infinispan-dev] Transport related configuration timeouts

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] Transport related configuration timeouts

Vladimir Blagojevic
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Transport related configuration timeouts

Vladimir Blagojevic
This is of course related to Infinispan 5.0
http://docs.jboss.org/infinispan/5.0/apidocs/config.html
On 11-05-31 3:09 PM, Vladimir Blagojevic wrote:

> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Transport related configuration timeouts

Mircea Markus
In reply to this post by Vladimir Blagojevic

On 31 May 2011, at 14:09, Vladimir Blagojevic wrote:

> 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!
looks good to me! What do you think should be done when they are not correct? Warning? Or even ConfigException perhaps?
>
> Regards,
> Vladimir
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Transport related configuration timeouts

Vladimir Blagojevic
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.
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Transport related configuration timeouts

Mircea Markus

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Transport related configuration timeouts

Galder Zamarreno

On Jun 2, 2011, at 3:36 PM, Mircea Markus wrote:

>
> 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.

I think a warning is better. We could always change the numbers if we find inconsistencies so that they make sense.

>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Transport related configuration timeouts

Galder Zamarreno
In reply to this post by Vladimir Blagojevic

On May 31, 2011, at 3:09 PM, Vladimir Blagojevic wrote:

> 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

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*

>
>
> Am I overseeing something? Lets hear your thoughts in the area of your
> expertize!
>
> Regards,
> Vladimir
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Transport related configuration timeouts

Vladimir Blagojevic
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.

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





_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Transport related configuration timeouts

Galder Zamarreno

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Transport related configuration timeouts

Vladimir Blagojevic
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev