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