Re: Stateless Pool and Stateful Pool Timeouts

[David Blevins <da...@visi.com>]

When you work it back in, use the new Duration object I added.  It's  
pretty cool.

Also you can eliminate the semaphore map by putting the bean's  
semaphore into the Container's Data object.

-David

On Jul 18, 2008, at 12:11 AM, Manu George wrote:

> Oops I am the culprit here :(. Let me make amends. I will try and get
> it fixed over the weekend.
>
> Regards
> Manu
>
> On Fri, Jul 18, 2008 at 11:07 AM, David Blevins <david.blevins@visi.com 
> > wrote:
>>
>> On Jul 17, 2008, at 5:29 AM, the666pack wrote:
>>
>>>
>>> Hello,
>>>
>>> i have a question regarding timeout values in openejb as the  
>>> documentation
>>> is somewhat sparse:
>>>
>>> the timeout for the stateless pool is defined as:
>>>
>>> "Specifies the time to wait between invocations. This
>>> value is measured in milliseconds. A value of 5 would
>>> result in a time-out of 5 milliseconds between invocations.
>>> A value of zero would mean no timeout."
>>>
>>> what exactly does the default value 0 now mean?
>>
>> It looks like that value is no longer used.  It used to configure  
>> the amount
>> of time a thread should block while waiting for a instance from the  
>> pool
>> when strict pooling is used.  Zero was meant to imply "wait for as  
>> long as
>> it takes", i.e. indefinitely.  Agree that description is terrible.
>>
>> The code was updated between 3.0-beta-2 and 3.0 final to fix the  
>> enforcement
>> of the StrictPooling option.  Looks like the timeout got left out  
>> of that
>> refactor.  We definitely should update the code to use the  
>> configurable
>> timeout again.
>>
>>
>>> the timeout for the stateful pool is defined as:
>>>
>>> "Specifies the time to wait between invocations. This
>>> value is measured in minutes. A value of 5 would
>>> result in a time-out of 5 minutes between invocations.
>>> A value of zero would mean no timeout."
>>>
>>> is this the time before the bean is passivated or is this timeout  
>>> before
>>> the
>>> bean gets removed from the container?
>>
>> It's the amount of inactive time to wait until the bean instance is
>> destroyed.  A value of zero would mean bean instances are never  
>> destroyed
>> due to timeout.  Passivation is triggered when reaching the  
>> PoolSize.  At
>> that point, the BulkPassivate value defines how many instances  
>> (oldest
>> first) we will remove from the pool and passivate to disk.    
>> Afterwards the
>> number of active instances will be X where 'X = PoolSize -  
>> BulkPassivate'
>>
>> We will definitely clean up those docs.  Thanks for asking for
>> clarification!
>>
>> -David
>>
>>
>

Re: Stateless Pool and Stateful Pool Timeouts

[Manu George <ma...@gmail.com>]

Ah Yes  I remember reading that thread now :). Thanks

On Tue, Jul 22, 2008 at 10:28 PM, David Blevins <da...@visi.com> wrote:
>
> On Jul 22, 2008, at 5:40 AM, Manu George wrote:
>
>> I had a look at this and am facing a certain behaviour that is
>> puzzling me. I create an EJB and from a client make a 1000 parallel
>> invocations. I set the poolSize as say 10 for the stateless container
>> but still all the 1000 invocations use only a single instance.
>> The ThreadPoolExecutor in ServicePool seems to be deciding how many
>> threads are executing in parallel and most of the time the execution
>> is happening serially. At much higher loads more instances are getting
>> created but that is decided by how many threads are being created by
>> the ThreadPoolExecutor. So the timeout variable which i worked back in
>> seems to be not to be getting used most of the time.
>
> It's actually getting decided by the client.  See this description from the
> "Remote client performance" thread.
>
> On Jul 13, 2008, at 5:41 PM, David Blevins wrote:
>
>> I also made it so the client can have at most one open connection per
>> server URL and all requests file through it.
>>
>> For the record you can actually get more connections per client by
>> slightly appending to your server url as so:
>>
>> ejbd://localhost:4201/a
>> ejbd://localhost:4201/b
>>
>> Everything after the "/" is currently ignored, but will allow you to get
>> another connection to the same server if you think you really need it.  I
>> actually saw pretty great performance with just one connection shared among
>> 10 client threads, but maybe you want a second connection open for very long
>> running requests as to not block up the shorter requests.
>
> I'd say the best way to test the pooling is to have a testcase that uses the
> LocalInitialContextFactory.  Then you can test as many threads as you need
> and have the container code more isolated than with including the
> client/server code as well.  Should also allow you to keep the test case in
> the openejb-core package.
>
> -David
>
>

Re: Stateless Pool and Stateful Pool Timeouts

[David Blevins <da...@visi.com>]

On Jul 22, 2008, at 5:40 AM, Manu George wrote:

> I had a look at this and am facing a certain behaviour that is
> puzzling me. I create an EJB and from a client make a 1000 parallel
> invocations. I set the poolSize as say 10 for the stateless container
> but still all the 1000 invocations use only a single instance.
> The ThreadPoolExecutor in ServicePool seems to be deciding how many
> threads are executing in parallel and most of the time the execution
> is happening serially. At much higher loads more instances are getting
> created but that is decided by how many threads are being created by
> the ThreadPoolExecutor. So the timeout variable which i worked back in
> seems to be not to be getting used most of the time.

It's actually getting decided by the client.  See this description  
from the "Remote client performance" thread.

On Jul 13, 2008, at 5:41 PM, David Blevins wrote:

> I also made it so the client can have at most one open connection  
> per server URL and all requests file through it.
>
> For the record you can actually get more connections per client by  
> slightly appending to your server url as so:
>
> ejbd://localhost:4201/a
> ejbd://localhost:4201/b
>
> Everything after the "/" is currently ignored, but will allow you to  
> get another connection to the same server if you think you really  
> need it.  I actually saw pretty great performance with just one  
> connection shared among 10 client threads, but maybe you want a  
> second connection open for very long running requests as to not  
> block up the shorter requests.

I'd say the best way to test the pooling is to have a testcase that  
uses the LocalInitialContextFactory.  Then you can test as many  
threads as you need and have the container code more isolated than  
with including the client/server code as well.  Should also allow you  
to keep the test case in the openejb-core package.

-David

Re: Stateless Pool and Stateful Pool Timeouts

[Manu George <ma...@gmail.com>]

I had a look at this and am facing a certain behaviour that is
puzzling me. I create an EJB and from a client make a 1000 parallel
invocations. I set the poolSize as say 10 for the stateless container
but still all the 1000 invocations use only a single instance.
The ThreadPoolExecutor in ServicePool seems to be deciding how many
threads are executing in parallel and most of the time the execution
is happening serially. At much higher loads more instances are getting
created but that is decided by how many threads are being created by
the ThreadPoolExecutor. So the timeout variable which i worked back in
seems to be not to be getting used most of the time.

To  illustrate this. Suppose my timeout is 10secs and i have an ejb
method that executes for 9 secs (sleeps) During this period there is
no other thread that is getting instantiated by the Executor. So 1
thread executes at a time and no timeout also happens as the wait is
in the THread:PooledExecutor. It looks like some defect in the
executor but some advice on this subject will be appreciated

Regards
Manu

On Fri, Jul 18, 2008 at 4:50 PM, Manu George <ma...@gmail.com> wrote:
> Sure thanks. I will have a look at the Duration Object.
>
> Regards
> Manu
>
> On Fri, Jul 18, 2008 at 3:11 PM, David Blevins <da...@visi.com> wrote:
>> When you work it back in, use the new Duration object I added.  It's pretty
>> cool.
>>
>> Also you can eliminate the semaphore map by putting the bean's semaphore
>> into the Container's Data object.
>>
>> -David
>>
>> On Jul 18, 2008, at 12:11 AM, Manu George wrote:
>>
>>> Oops I am the culprit here :(. Let me make amends. I will try and get
>>> it fixed over the weekend.
>>>
>>> Regards
>>> Manu
>>>
>>> On Fri, Jul 18, 2008 at 11:07 AM, David Blevins <da...@visi.com>
>>> wrote:
>>>>
>>>> On Jul 17, 2008, at 5:29 AM, the666pack wrote:
>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> i have a question regarding timeout values in openejb as the
>>>>> documentation
>>>>> is somewhat sparse:
>>>>>
>>>>> the timeout for the stateless pool is defined as:
>>>>>
>>>>> "Specifies the time to wait between invocations. This
>>>>> value is measured in milliseconds. A value of 5 would
>>>>> result in a time-out of 5 milliseconds between invocations.
>>>>> A value of zero would mean no timeout."
>>>>>
>>>>> what exactly does the default value 0 now mean?
>>>>
>>>> It looks like that value is no longer used.  It used to configure the
>>>> amount
>>>> of time a thread should block while waiting for a instance from the pool
>>>> when strict pooling is used.  Zero was meant to imply "wait for as long
>>>> as
>>>> it takes", i.e. indefinitely.  Agree that description is terrible.
>>>>
>>>> The code was updated between 3.0-beta-2 and 3.0 final to fix the
>>>> enforcement
>>>> of the StrictPooling option.  Looks like the timeout got left out of that
>>>> refactor.  We definitely should update the code to use the configurable
>>>> timeout again.
>>>>
>>>>
>>>>> the timeout for the stateful pool is defined as:
>>>>>
>>>>> "Specifies the time to wait between invocations. This
>>>>> value is measured in minutes. A value of 5 would
>>>>> result in a time-out of 5 minutes between invocations.
>>>>> A value of zero would mean no timeout."
>>>>>
>>>>> is this the time before the bean is passivated or is this timeout before
>>>>> the
>>>>> bean gets removed from the container?
>>>>
>>>> It's the amount of inactive time to wait until the bean instance is
>>>> destroyed.  A value of zero would mean bean instances are never destroyed
>>>> due to timeout.  Passivation is triggered when reaching the PoolSize.  At
>>>> that point, the BulkPassivate value defines how many instances (oldest
>>>> first) we will remove from the pool and passivate to disk.   Afterwards
>>>> the
>>>> number of active instances will be X where 'X = PoolSize - BulkPassivate'
>>>>
>>>> We will definitely clean up those docs.  Thanks for asking for
>>>> clarification!
>>>>
>>>> -David
>>>>
>>>>
>>>
>>
>>
>

Re: Stateless Pool and Stateful Pool Timeouts

[Manu George <ma...@gmail.com>]

Sure thanks. I will have a look at the Duration Object.

Regards
Manu

On Fri, Jul 18, 2008 at 3:11 PM, David Blevins <da...@visi.com> wrote:
> When you work it back in, use the new Duration object I added.  It's pretty
> cool.
>
> Also you can eliminate the semaphore map by putting the bean's semaphore
> into the Container's Data object.
>
> -David
>
> On Jul 18, 2008, at 12:11 AM, Manu George wrote:
>
>> Oops I am the culprit here :(. Let me make amends. I will try and get
>> it fixed over the weekend.
>>
>> Regards
>> Manu
>>
>> On Fri, Jul 18, 2008 at 11:07 AM, David Blevins <da...@visi.com>
>> wrote:
>>>
>>> On Jul 17, 2008, at 5:29 AM, the666pack wrote:
>>>
>>>>
>>>> Hello,
>>>>
>>>> i have a question regarding timeout values in openejb as the
>>>> documentation
>>>> is somewhat sparse:
>>>>
>>>> the timeout for the stateless pool is defined as:
>>>>
>>>> "Specifies the time to wait between invocations. This
>>>> value is measured in milliseconds. A value of 5 would
>>>> result in a time-out of 5 milliseconds between invocations.
>>>> A value of zero would mean no timeout."
>>>>
>>>> what exactly does the default value 0 now mean?
>>>
>>> It looks like that value is no longer used.  It used to configure the
>>> amount
>>> of time a thread should block while waiting for a instance from the pool
>>> when strict pooling is used.  Zero was meant to imply "wait for as long
>>> as
>>> it takes", i.e. indefinitely.  Agree that description is terrible.
>>>
>>> The code was updated between 3.0-beta-2 and 3.0 final to fix the
>>> enforcement
>>> of the StrictPooling option.  Looks like the timeout got left out of that
>>> refactor.  We definitely should update the code to use the configurable
>>> timeout again.
>>>
>>>
>>>> the timeout for the stateful pool is defined as:
>>>>
>>>> "Specifies the time to wait between invocations. This
>>>> value is measured in minutes. A value of 5 would
>>>> result in a time-out of 5 minutes between invocations.
>>>> A value of zero would mean no timeout."
>>>>
>>>> is this the time before the bean is passivated or is this timeout before
>>>> the
>>>> bean gets removed from the container?
>>>
>>> It's the amount of inactive time to wait until the bean instance is
>>> destroyed.  A value of zero would mean bean instances are never destroyed
>>> due to timeout.  Passivation is triggered when reaching the PoolSize.  At
>>> that point, the BulkPassivate value defines how many instances (oldest
>>> first) we will remove from the pool and passivate to disk.   Afterwards
>>> the
>>> number of active instances will be X where 'X = PoolSize - BulkPassivate'
>>>
>>> We will definitely clean up those docs.  Thanks for asking for
>>> clarification!
>>>
>>> -David
>>>
>>>
>>
>
>