Hi Matt,
> I've been reading the documentation and it is *really* helpful. Thanks :-)
Yeah, it was very tough to work on docs :)
> 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.
> 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?
Thanks.
Alexey.
>
> Matt
>
>
> On 24 February 2011 12:06, Oleksiy Stashok <oleksiy.stashok_at_oracle.com
> <mailto:oleksiy.stashok_at_oracle.com>> wrote:
>
> Grizzly team is glad to announce Grizzly 2.0 release!
>
> http://grizzly.java.net
> http://blogs.sun.com/oleksiys/entry/grizzly_2_0_release
>
> Feedback is more than welcome!
> Thanks to all, who helped and contributed!
>
> Alexey.
>
>