Craig McClanahan wrote:
>
> Greg Barish wrote:
>
> > I am still having problems trying to get Apache & JServ to scale to even
> > 10 simultaneous connections on Solaris when I'm using a sychronized doPost().
> >
> > Before I get into a description of the problem, it would seem to me that
> > JServ should be able to queue up connections to doPost()'s which need
> > to be serialized. Can someone tell me what it _should_ do for such cases?
> > Suppose 1000 clients attempt to POST on a servlet which has a synchronized
> > doPost() that takes over a minute to complete? What _should_ happen?
>
> [remainder of the example snipped]
>
> This one isn't that tough, once you understand what's going on. The bottom
> line: do not synchronize doPost() (or service(), or doGet()) if you expect
> scalable performance in *any* servlet engine.
>
> Why? Because, in most servlet engines, the engine creates a single instance of
> your servlet and tries to invoke it on multiple threads (to handle simultaneous
> requests). If your doPost() is not synchronized, this works great -- but by
> adding the "synchronized" tag, you are effectively single threading the requests
> through that one instance.
This seems like a recipe for problems to come in the future. If people have
the option to synchronize doPost(), I would think that some people will probably
experiment (like I did) with using it as a quick-and-dirty way to achieve
serialization of requests which involve accessing a resource which does not
support concurrency (like a dedicated socket).
What I was hoping to do was to leverage some existing part of either Apache or
JServ to funnel requests into a queue so that I could support concurrency
(no HTTP 500s being returned) but still implement serially. The obvious
downside is that client requests will take awhile to process since everything
is being serialized, but the nature of app is such that this behavior is okay.
I could have written the "queue-the-requests" behavior code myself, but I was
hoping to leverage something which I thought might already be there.
So I guess what I'm complaining about is not lack of _scalability_ (since the
design of the app I have to implement is inherently not scalable), but one
lack of _availability_.
Your advice of "don't synchronize, but SingleThread it instead" seems
reasonable. Thanks. I thought I had tried that and still gotten the same
behavior, but I will revist this -- with renewed enthusiasm. :-)
Thanks for your advice.
>
> What if you *really* need a synchronized doPost() method? (This is really a
> fundamental design issue, but I will assume for a moment that you have a valid
> reason for wanting it.)
I definitely do. It's a resource I do not own which refuses to allow
concurrent access.
--
::: Greg Barish ([EMAIL PROTECTED]) :::::::::::::::::::::::::::::::::::::::
----------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html/>
Problems?: [EMAIL PROTECTED]
