[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: TUX and a Java servlet engine



Michael K. Johnson wrote:


<thinking out loud, and having no knowledge of Tux>

Perhaps a simple Tux module could be written to read the entire client message and post that to the servlet-runner via TCP.
The servlet-runner could spawn a worker thread who would prepare the entire response event/message and ask the servlet-runner
to talk to Tux over TCP to have Tux send the response out.


Um, that's roughly what you can do already with TUX server delegation
that Jakob rejected.

I'm talking about something completely different.
Jakob was dissappointed because Tux would be handing off data to Apache, which would then hand off data to the servlet runner, which would hand off data to the Java servlet. Using TUX here would only slow things down.


What I presented would give you many less steps, and potentially many less threads running:

TUX hands off packets to an asynchronous-aware servlet runner written in Java via TCP sockets, the servlet-runner schedules an execute thread to do the work while a "sendToTUX" thread wait()s on an outgoing queue which is filled by the execute thread servlet code.

When you remove Apache in this manner, you remove:
1. one thread to one socket limitation
2. apache->servlet-runner communication (whatever native or TCP mechanisms are used involve system call overhead)
3. servlet-runner->apache communication (same overhead as #2)


Ramblings about why #1 is important:

Anyone who is building something as simple as a ICQ-type chat server knows Linux can't handle more than
256 simultaneous connections under Linux because of the 512/2 NRTASKS limitation (unless you build a custom kernel). The #1 benefit solves this.


Anyone who has tried to get 500 connected clients up under Java knows this is impossible with native threads
under Linux even if you increase NRTASKS. The solution to 5000+ simultaneously connected clients is in non-blocking I/O. I'm assuming TUX uses /dev/poll or provides similar functionality .. if it doesn't, TUX is probably the wrong approach because from all the data I've seen /dev/poll is the only thing that works (vs select() or poll() above 500 simultaneous connections, which means you are better off with Matt Welsh's Java (using Native methods) NBIO library which uses /dev/poll.


P.S. I know /dev/poll isn't in standard linux-2.4.0-pre11. (Too bad...)






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []