Nice to meet you, everyone.
I'm Eugene Chung from TmaxSoft. I am taking over for Mr.Paek as an EG
member.
I've sent this e-mail to "jsr340-experts_at_servlet-spec.java.net" but it's
denied by SYMPA. :-)
So I choose the users list.
Recently, I'm implementing the new NIO features based on Public Review.
And I want to address some issues which should be handled by specification.
1. AsyncContext.dispatch() and nonblocking mode
If an application calls AsyncContext.dispatch() after using
nonblocking mode, what should we do?
As we know, asynchronous dispatch means that the container assigns a
container-managed thread to that context.
So it doesn't seem to need nonblocking mode anymore like traditional
servlet.
And if the target of dispatch is a jsp file, application developers
must consider about NIO in jsp. This might be a burden for them.
I think there could be two options.
a. Change to blocking mode implicitly
b. Throw ISE when AsyncContext.dispatch() is called after nonblocking
mode is started
2. AsyncContext.complete() and nonblocking write
What behaviour of AsyncContext.complete() on nonblocking write mode
is desirable? If some data is remained in the internal buffer, should
the container return complete() after all data remained is flushed or
just return even if it is not completely flushed? In latter case, the
container must flush data with other thread.
3. Restriction on 'void' bulk write methods
Application developers should aware that they shall NOT modify their
buffers right after ServletOutputStream.write(byte[]) is returned.
They must wait until ServletOutputStream.isReady() is true. Then they
can modify their buffer again.
If we permit this, it's definitely memory copy overhead.
I read about this restriction somewhere in the EG mailing list but I
couldn't find any written warnings in the API or spec..
4. Thread that has event ownership
AsyncContext can be used by an application-managed thread (pool). The
container don't know what it will be.
Application developers may want that event methods of read and write
listeners are called by their own threads.
If this requirement can happen, I think we may need to provide API
like setReadListener(ReadListener, ThreadPool).
ThreadPool can be java.util.concurrent.Executor or JSR 236
ManagedExecutorService(actually it's also Executor).
Best regards,
Eugene Chung (Korean : 정의근)