I don't use thread pool in the version 2. will be in v3. you can find v1
also.. that using 1thread by connection.. if you want to see the diff
between the version.
Last thing, have I got it right that a ThreadPool is used for connection
handling? or is it used for Handlers processing?
did find that yet.. need more feedback and investiguations.
2008/6/21 Matteo Mazzotti <m.mazzotti_at_p-tel.it>:
> Hi and thanks for your reply.
> I found one of your old posts, with a zip attachment (nio_quotegw_demo_v2).
> Is this the latest version of your migration guide?
> Also, I don't quite get what you mean by "pure grizzly" implementation. Is
> your ThreadPool version hand-made by you? (I mean, did you write your own
> thread pool?)
> Do you have a UML class diagram of your demo? It would help a lot in
> understanding the overall picture.
>
> Last thing, have I got it right that a ThreadPool is used for connection
> handling? or is it used for Handlers processing?
>
> thanks
> matteo
>
> ------------------------------
> *Da:* Survivant 00 [mailto:survivant00_at_gmail.com]
> *Inviato:* sabato 21 giugno 2008 13.31
> *A:* users_at_grizzly.dev.java.net
> *Oggetto:* Re: Newbie: preliminar clarifications
>
> hello Matteo.
>
> I had to do a similar thing. I started a migration guide to Grizzly.
>
> The first step I did was with 1 thread by connection and I did a second
> iteration to replace that by the Selector and event. The next step will be
> to add ThreadPool and the last one in Grizzly.
>
> I used permanent connection asynchone.. you can start by looking at my
> code.. I posted it here. Check the previous post in the mailing list.
>
> The demo I created it's a simulator of realtime stock application. We will
> get realtime quote on a stock. The server push to new update to the
> client.. no pooling.
>
> give me your comments on my code or questions. I'm working to setup a blog
> to the comments and how I did it..
>
> bye
> Sébastien.
>
> 2008/6/21 Matteo Mazzotti <m.mazzotti_at_p-tel.it>:
>
>> Hi all,
>> I've come across your framework more or less by chance.
>> I've read some blogs about it and some tutorials, but I need a final
>> clarification from you on whether this is actually the right framework for
>> my use case.
>>
>> I have to (re)write a TCP server (no HTTP) that is able to serve hundreds
>> of
>> clients at the same time.
>> What is not clear to me is whether Asynchronous and permanent connections
>> (which is what I need) are two contradictory terms, that is if one must
>> choose between one approach or the other.
>> I need a permanent connection because the client must be pushed data by
>> the
>> server (I'd say asynchronously, as the updates sent by the server don't
>> necessarily follow a client request).
>>
>> At the moment, my server implementation is based on the old
>> thread-per-connection paradigm, which I understand is a wasteful approach
>> and doesn't scale up. So the thread-per-event seems to be the right one
>> here.
>> Aother question: in the thread-per-event solution, a thread pool is used
>> to
>> take a thread from the pool, serve an event, "wake up" the appropriate
>> Handler (which is a thread too), then go back to sleep waiting for a new
>> event. If a Handler is a thread, and I have a Handler per client, in the
>> end
>> I still have a thread per connection, so what's the key difference ? Am I
>> missing something here? (maybe there can be a thread pool for Handlers
>> too?)
>>
>>
>> Thank you in advance,
>> Matteo
>>
>> Ps: I'm from Italy and I couldn't find any resource on grizzly on the
>> Italian blogosphere. I think I'll blog about it as soon as I get
>> knowledgeble enough
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>>
>