John ROM wrote:
> In the code above
> BaseSelectionKeyHandler.postProcess(SelectionKey key) gets called
> sometimes with key=null
>
> because sometimes the businesslogic thread is faster than the WorkerThread
Hum...I wasn't able to reproduce the problem. Let me investigate more....
Thanks!!!
-- jeanfrancois
>
>> -----Ursprüngliche Nachricht-----
>> Von: Jeanfrancois Arcand [mailto:Jeanfrancois.Arcand_at_Sun.COM]
>> Gesendet: Montag, 7. Juli 2008 17:54
>> An: users_at_grizzly.dev.java.net
>> Betreff: Re: WG: Re: WG: Re: WG: Re: WG: Re: Asynchronous Request
>> Processing with TCPIP
>>
>>
>>
>> John ROM wrote:
>>>>> Problem is I cannot call resume() because the grizzly
>>>>> workerthread (protocolParser) might still be using the same context.
>>>> I see. But why are you resuming? Is it because you need more read
>>>> operations?
>>>>
>>> Well I am only resuming because I want to be nice and give grizzly the
>> used
>>> context back for its context pool.
>> Great :-)
>>
>>
>>> Before the suspend method I just got handles to the things I needed from
>>> context for the new businesslogic Thread. Like selection key and
>> asyncWriter... But since I am
>>> writing a tutorial I thought readers are used to the Context concept and
>> so I should stick to it
>>> and not create a new holder Object.
>>>
>>> I am doing something like this:
>>>
>>> private void dispatch(final Message msg, final Context workerCtx) {
>>>
>>> workerCtx.suspend();
>>>
>> workerCtx.setKeyRegistrationState(Context.KeyRegistrationState.REGISTER);
>>> executorService.execute(new Runnable() {
>>> public void run() {
>>> doBusinessLogic(msg,workerCtx)
>>> workerCtx.resume();
>>> }
>>> });
>>>
>>> }
>>>
>>> Well maybe I should really just copy the things I need from the context
>> and
>>> give it to the businessLogic Thread like
>>>
>>>
>> doBusinessLogic(msg,workerCtx.getSelectionKey(),workerCtx.getAsyn,workCtx.getSelectorHandler())
>>
>> But the code above looks quite good IMO and should work. Let me take a
>> look at the ProtocolParser implementation to see what's happening there
>> :-). I suspect the continuousExecution is the issue and we might need to
>> adapt the suspend/resume implementation based on that.
>>
>> Thanks!
>>
>> -- Jeanfrancois
>>
>>
>>
>>
>>
>>>
>>> Many Greetings
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>