users@grizzly.java.net

Re: Threading model

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Thu, 25 Sep 2008 16:09:22 -0400

Salut,

bsimonssays wrote:
> I'm working on a turn-based game server. The server needs to support:
>
> 1. Initializing a new game.
> 2. Allowing two players to register to play that game.
> 3. Once the players have registered the game begins:
> 3a. Player1 submits his move and the server updates both Player1 and Player2
> with the results of the move. The calculation of the result of the move
> will be somewhat intensive so I think it makes sense to do this in a
> non-WorkerThread.

Agree.


>
> The server needs to support a number of concurrently running games.
>
> If having the filter submit the job to another ThreadPool is legal, I will
> go with that model.
>

Yes it is. Grizzly Asynchronous Request Processing (ARP) is using that
trick to support technology like Comet, SOA/ESB, etc.


> My next problem will be sending the results back to Player2 after Player1
> submits his move. Can you suggest a good way of holding onto the output
> stream for both players? Can I hold a reference to the SelectableChannel
> for each player when they register?

Yes you can by telling Grizzly to no do anything with the connection:

ctx.setKeyRegistrationState(Context.KeyRegistrationState.NONE);

inside your last Filter, and store the SelectionKey so it can be reused
later.


How does that relate to the Context's
> reference count?

You can keep the context as well by calling Context.suspend(). See the
following thread for more info:

http://www.nabble.com/Re%3A-Asynchronous-Request-Processing-with-TCPIP-tt18391541.html#a18391541


A+

-- Jesnfrancois



>
> Thanks for all of your help,
> Bill
>
>
> Jeanfrancois Arcand-2 wrote:
>> Salut,
>>
>> bsimonssays wrote:
>>> I'm making a lot of progress with Grizzly. At this point my server has a
>>> custom protocol parser and echoes back the request that has been parsed.
>> Great!!
>>
>>> What I'm curious about now is what the best practice is for the threading
>>> model of processing a request. Do you typically do the business logic in
>>> the same Worker Thread that has called the filter?
>> It really based on your application/protocol. For GlassFish v3, we are
>> using the WorkerThread for processing the http requests, but in Sailfin
>> we are using another set of thread to process the SIP protocol requests.
>>
>>
>> Or is it common to have
>>> a thread pool that the filter submits jobs to?
>> I would think it is really based on your application. Can you share what
>> you are working on?
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>
>>> Thanks,
>>> Bill
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>>
>>
>