Re: [Simpleweb-Support] parallelism?

[Juraj B. <ast...@gm...>]

Hello,

  thank you for your last reply.

> The responses will seem slow if you have set a bad
> default wait peroid. This is the length of time an
> inactive connection is put to sleep. So, if you open
> the connection and don't write anything for a couple
> of milliseconds then the connection is put to sleep.
> To configure this property the following can be used:
>
> ProtocolHandler myProtocolHandler = new
> MyProtocolHandler();
>
> PipelineHandler handler =
> PipelineHandlerFactory.getInstance(myProtocolHandler,
> 20, 100);

Thank you, this will probably help.

So one question, if I read from protocol Request input stream, will it block?

> With regards to the request and response events sent
> to the pipeline handler they are sent my many threads
> so you should not synchronize the protocol handler as
> this will cause blocking and thus serialization of
> your request processing. Also, why are you creating a
> new thread within the protocol handler???

I thought, that I have to exit from handler as soon as possible,
because I thought
other events are processed from the pipeline by the same thread, but it's
because I was evaluating http://docs.safehaus.org/display/ASYNCWEB/Home

I've read that documentation and mixed it up.

I've fixed it up.

My protocol handler is not synchronized, but the question is, does Simple
do some requests statistics? (I need connections per second). Creating a
new thread just for incrementing counter does not seem to be a good idea
to me and it has to be synchronized. If I could get that information from the
pipeline, it would be great.

> If you want to use it as a reverse proxy you are
> better off sending the request with the thread
> dispacthed to the protocol handler, and then queuing
> request socket.

Are there some classes, that would enable me to do this? (MessageQueue)?

I'm just studying javadocs, but there are plenty of classes and it
takes a while to
get the whole picture.

> After the request is sent you can
> queue the socket and have another thread pool read in
> the response perform some processing/translation of
> the response and deliver it over the socket. This
> would ensure that you do not limit the number of
> outstanding request with the number of threads used in
> the server.

Yes, that's what I would like to do.


   Thanks,

      Juraj.