On 24 February 2011 14:40, Oleksiy Stashok <oleksiy.stashok_at_oracle.com>wrote:
> Hi Matt,
>
>
> I've been reading the documentation and it is *really* helpful. Thanks
> :-)
>
> Yeah, it was very tough to work on docs :)
>
>
It's worth it though as it will really help drive adoption and lower the
barrier to entry.
>
> Out of curiosity, on your blog you show performance for blocking and
> non-blocking use cases. What exactly is blocking/non-blocking as it seems to
> make quite a huge difference for the 65KB echo test runs? Reads? Writes?
> Both? Server only or client and server? Just wondering...
>
> It's HTTP Input/Output streams (HttpRequest.getInputStream(),
> HttpResponse.getOutputStream()), which may work in blocking or non-blocking
> modes.
> Blocking - is regular Servlet-like InputStream/OutputStream, Non-blocking -
> it's NIOInputStream/OutputStream implementation, which let us process **
> content** asynchronously, non-blocking way.
> For both cases HTTP **headers** are getting parsed/serialized
> non-blocking.
>
> The result are environment dependent, here I'm attaching what we observe on
> Linux.
>
>
Ok, thanks for the clarification.
>
> Also, sorry if this is a dumb question, is it possible to implement
> client-side protocol implementations using Grizzly 2.0 which are fully
> synchronous (blocking) and do not require any selector/worker threads? The
> reason I ask is that some J2EE environments don't like it when servlets
> spawn their own threads, even if they're long lived: I would like to have a
> client mode in our LDAP SDK which is fully synchronous and does not require
> selectors and/or workers to process IO events as results are returned from
> the remote LDAP server.
>
> Unfortunately no :) IMO in your usecase any NIO framework won't have
> advantage vs. plain java.net.Socket, or I'm missing something?
>
>
The only reason I was looking at this was to try and reuse our existing
Grizzly filter logic (LDAP, SASL, SSL). I may be able to refactor out our
filter logic so that it is independent of Grizzly but then we may lose some
perfs due to the additional abstraction.
Thanks again,
Matt