Peter,
Your question is very interesting. Looking at it from an individual server
basis it is quite a tractable problem. But the distributed aspect of it is
the one that is worrisome. Im not going to address the distributed state
issue here as I would need a lot of detailsed info before I can offer a
suggestion.
Here are some observations I can offer:
1. At a very gross level a WebServer functions similar to a single server of
yours except for the fact that a webserver talks http and is essentially
stateless (but connection oriented). In your case since you mentioned UDP I
presume your server would be connectionless but Im not sure about stateless
(I hope it is for your sake!).
2. I presume you have an internal
request-receiver(s?)/request-dispatcher(s)/request-consumer(s?) model that
queues up the incoming requests (do some intelligent assignment of requests
to different queue(s)). Some basic queueing theory based work should give
you an idea the number of worker threads you need absolutely at any point to
satisfy your Mean Time To Response etc. JMS is a possible message oriented
solution for you in this area. There are several product available that
implement JMS. Especially if you want to solve the non-blocking I/O problem
with Java (You need shove the request into a queue and let go or else you
will have to have threads for each connection).
3. The way threading works from within the Java VM is a bit different from
using (say) POSIX or native threading libraries. Here I completely agree
with Michael's statements.
4. From a Server Side Java perspective my (and only my!) personal opinion is
that I dont think EJBs are for you at this point in time. It is essentially
for connection-oriented clients and there are a good amount of threading
(and io) restrictions that will hamper you if you are going to rely on fine
control of threads to help you ensure performance.
Suggestions:
1. You could try looking at a pure java webserver implementation (available
on the net) to get to the guts of a high performance http request server and
modify it. You could potentially have a UDPServlet that acts as the UDP
based request controller with a helper mechanism to intelligently dispatch
the messages to queues. JMS could come in handy here. I would suggest you do
this as a prototype effort before you make any hard technology committments.
2. Since Im a bit of a Java enthusiast and its always easier said than done,
I would say that you could make this happen in a clustered hardware setup.
There are quite a few EAI products that are Java based and handle huge
volumes of request and are used in B2B/B2C integration environments that
perform. High performance VMs (e.g. Tower/J) also help a lot.
But if you are not an experienced Java person or do not have the right
skilled Java folks and an experienced architect knowledgeable the server
side Java technologies, I would just move the whole thing over to a POSIX
based implementation if portability is the issue; more so if your management
is breathing down your shoulder!.
hope this helped,
keshava
-----Original Message-----
From: Michael Prescott [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 30, 2000 1:44 PM
To: [EMAIL PROTECTED]
Subject: Re: highly scalable network server app
If you're going to be doing something along these lines, I highly recommend
that you read O'Reilly's "Java Threads" (Oaks & Wong).
It provides a very comprehensive grounding in threading issues in Java,
and - given the nature of your questions - will probably give you more
insight into whether you want to do this project in Java than one-off
questions on this list.
Michael
-----Original Message-----
From: A mailing list about Java Server Pages specification and reference
[mailto:[EMAIL PROTECTED]]On Behalf Of skeptical
Sent: Wednesday, August 30, 2000 12:28 PM
To: [EMAIL PROTECTED]
Subject: Re: highly scalable network server app
yes, the transactions are very small. what i want to do is to service
multiple simultaneous udp requests. the number would be in the millions for
the whole distributed system but on one server it will probably be around
10k. i'd also want to create a thread pool instead of having 10k threads
recv'ing on 10k sockets. on windows nt and c++, you'd use i/o completion
port that creates a thread pool for you to service multiple socket i/o. how
can we do that in java?
tks,
peter
----- Original Message -----
From: "Geert Van Damme" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 30, 2000 9:22 PM
Subject: Re: highly scalable network server app
> Do you really mean millions? I hope these are rather small transactions
;-)
> (is that millions simultaneous, or millions per hour or millions per day?)
>
> Server side java approaches the speed of C++ (or better). but I wouldn't
do
> this for a first project in java. I'm afraid you will always think it
would
> have been better in C++
> I would do it in Java, maybe you better do it in C.
>
> Geert Van Damme
>
>
> > -----Original Message-----
> > From: A mailing list about Java Server Pages specification and reference
> > [mailto:[EMAIL PROTECTED]]On Behalf Of skeptical
> > Sent: woensdag 30 augustus 2000 15:13
> > To: [EMAIL PROTECTED]
> > Subject: highly scalable network server app
> >
> >
> > dear all: is there a mailing list that discusses the above topic? i am
new
> > to java but am very familiar with c++, windows nt. i need to write a
> > distributed server app that can service millions of udp
> > connections. i know
> > how to do it on windows nt using c++ (using w2k thread pooling,
> > iocp, etc.).
> > i am attracted to the write once run anywhere concept of java and
> > would like
> > to investigate the possibility of writing such system using java.
> > has anyone
> > done this? is it possible/recommended on java?
> >
> > tks,
> > peter
> >
> > ==================================================================
> > =========
> > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> > JSP-INTEREST".
> > Some relevant FAQs on JSP/Servlets can be found at:
> >
> > http://java.sun.com/products/jsp/faq.html
> > http://www.esperanto.org.nz/jsp/jspfaq.html
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
> >
> >
>
>
===========================================================================
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
