users@grizzly.java.net

Re: WG: Re: WG: Re: Fwd: WG: Re: WG: Re: WG: Re: WG: Re: Asynchronous Request Processing with TCPIP

From: John ROM <snake-john_at_gmx.de>
Date: Wed, 09 Jul 2008 12:46:57 +0200

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?



> 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