Salut,
glassfish_at_javadesktop.org wrote:
>> What I suspect is the WAP protocol (and the client) send the minimal bytes over the wire (which isn't including the parameters)
>
> Extend my performance logger with url data and it confirmed that.
> The long running request are mostly WAP POST request, so probably post params will be send later if the are invoked by getParameter.
>
>
>
>> The default time out (30 seconds) is just fine for WAP I'm pretty sure.
>
> Not shure about that, does above not mean:
> 1. An GlassFish thread, which does the communication with the WAP-Client, will be closed even if the request is not processed totally?
Yes. If you change the readTimeout value, it might happens. Imagine a
hacker that send one byte every 60 seconds....all the threads will lock
trying to read this slow client and that will create a denial of
service. Hence we put a max value the client can takes to send its
bytes. In your case, reducing the value will close connection and some
of your client will be broken.
> 2. If there are lot of WAP-Requests, then there are also many GlassFish threads opend and waiting. Should i increase some max thread value to have always possible free?
Yes that will help adding more threads as client are "slowly" sending
bytes. HAving a couple more will make other request faster because they
will not be queued.
A+
-- Jeanfrancois
> [Message sent by forum member 'hammoud' (hammoud)]
>
> http://forums.java.net/jive/thread.jspa?messageID=281996
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>