Hi Matteo,
have you made any progress? Let me try to answer questions...sorry for
the delay
Matteo Mazzotti wrote:
> 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?)
The thread pool used in Grizzly, called Pipeline, is an home made thread
pool. At the time we wrote Grizzly, the java.util.concurrent.* one
weren't preforming as good as that one. Now we will soon move to an
Executor based one.
> Do you have a UML class diagram of your demo? It would help a lot in
> understanding the overall picture.
We unfortunately don't have any UML diagram.
>
> Last thing, have I got it right that a ThreadPool is used for connection
> handling?
Yes. Grizzly accept the connection on the same thread as the thread
running the Selector, and then spawn thread to process the request.
or is it used for Handlers processing?
By handlers, you means ProtocolFilter?
Thanks
-- Jeanfrancois
>
> 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
> <mailto: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
> <mailto:users-unsubscribe_at_grizzly.dev.java.net>
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
> <mailto:users-help_at_grizzly.dev.java.net>
>
>