Hi,
>
> Hello Jeanfrancois, Alexey
> since I have a good testcase I could try to work on the patch.
> But no time today (-:
>
> I see a little problem with me doing it because reycling and giving
> Context back to pool
> is often not one method. So I might need to patch
> Controller,ContextTask,maybe a little of
> Context suspend-resume logic.
>
> So I would just make a patch as a suggestion and build a testcase in
> the samples module
>
> So I would add two methods
>
> increaseRefCount()
> decreaseRefCount()
> and Context.recyle will only do its job when refcount ==1
>
> I would not care about Thread racing conditions because the worst
> which could
> happen is that a Context might not get recycled.
>
> What do you think?
IMHO, using AtomicInteger we can avoid thread racing problems, or
there are usecases I missed during vacation? :))
Otherwise I agree with you proposal! :)
Thanks.
WBR,
Alexey.
>
>
>
>
>> Von: Oleksiy Stashok [mailto:Oleksiy.Stashok_at_Sun.COM]
>> Gesendet: Mittwoch, 9. Juli 2008 11:27
>> An: users_at_grizzly.dev.java.net
>> Betreff: Re: WG: Re: Fwd: WG: Re: WG: Re: WG: Re: WG: Re:
>> Asynchronous
>> Request Processing with TCPIP
>>
>> Hello guys,
>>
>> I'm back from vacation, so sorry for jumping to the discussion :))
>>
>>
>>> Or maybe a reference counter in Context which starts at 1.
>>> when suspend is called counter ++;
>>> In recycle then counter -- and when counter ==0 do a real
>>> recycle.
>>> would that work?
>>
>> I like the idea, it looks much better to me than 'context copying'
>> and
>> will perform better. We just need to make sure, that the Context
>> never
>> get lost - at some point it MUST be recycled.
>> Patches are appreciated ;)
>>
>> Thank you!
>>
>> WBR,
>> Alexey.
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ________________________________
>>>>
>>>> Von: Jeanfrancois Arcand [mailto:Jeanfrancois.Arcand_at_Sun.COM]
>>>> Gesendet: Di 08.07.2008 22:30
>>>> An: users_at_grizzly.dev.java.net
>>>> Betreff: Re: Fwd: WG: Re: WG: Re: WG: Re: WG: Re: Asynchronous
>>>> Request
>>>> Processing with TCPIP
>>>>
>>>>
>>>>
>>>>
>>>> Salut,
>>>>
>>>> John ROM wrote:
>>>>> Hi Jeanfrancois,
>>>>> I think the right way to go if one wants other threads beside
>>>> workerthread to use
>>>>> Context is to give Context knowledge of what threads are using
>>>>> Context.
>>>>> Context then gets recycled when the thread calling Context.recyle
>>>>> is the
>>>> last one using it.
>>>>> So the contract would be if one Thread wants to use Context it has
>>>>> to
>>>> register and
>>>>> afterwords unregister with Context......
>>>>>
>>>>> What do you think?
>>>>
>>>> That's doable, although it will be quite complicated to get the
>>>> list of
>>>> thread that are referencing that object. Or do I miss something?
>>>>
>>>> Thanks!
>>>>
>>>> -- Jeanfrancois
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> Salut,
>>>>>
>>>>> John ROM wrote:
>>>>>> Hi Jeanfrancois,
>>>>>>
>>>>>> So I really now think that I just should and do a :
>>>>>> (in com.sun.grizzly.filter.MessageDispatcher)
>>>>>>
>>>>>> final Context
>>>> copyContext
>>>> =
>>>> workerCtx.getController().pollContext(workerCtx.getSelectionKey());
>>>>>> workerCtx.copyTo(copyContext);
>>>>>>
>>>>>> // and then when I am finished
>>>>>> //
>>>>>> copyContext.getController().returnContext(copyContext);
>>>>>
>>>>> What about this proposal:
>>>>>
>>>>> When calling suspend/resume, we never recycled the object. If an
>>>>> implementation wants to recycle those, we can either add a new API
>>>>> like
>>>>> recycleAndReturn(), which will internally call the
>>>>> controller.returnContext().
>>>>>
>>>>> What peoples thinks?
>>>>>
>>>>> A+
>>>>>
>>>>> -- Jeanfrancois
>>>>>
>>>>>
>>>>>
>>>>>> Many Greetings John
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>
>>>>
>>>>
>>>
>>> --
>>> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
>>> Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
> --
> GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
> Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>