Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
true. lets see how it pans out in actual code, that might change our
perspective.
I was toying around with an alternative idea too, disallow any read
or write all together unless it is done on a worker thread. gives us
complete control, easier to implement.
public void CometEvent.notify(int operations);
operations = READ | WRITE | NOW;
READ - this is what we do now under the covers, this would give the
user the control, basically means, notify me when there is data to read
WRITE - notify me when I can write data
NOW - send me a worker thread my way, so that I can safely initiate a
blocking or non blocking read or write.
Ok, so it would call notify(WRITE) when the write "available" flag
becomes false. Also, do you have any idea of another name for the
"notify" method ?
oh crap, we are thinking way different :), I was thinking the other way
around
Here is one event chain
1. CometProcessor.event(CometEvent.BEGIN/null)
2. Servlet calls CometEvent.setBlocking(false);
3. Servlet calls CometEvent.notify(READ) - the servlet wants to be
notified when data is available
4. Data arrives on the socket
5. CometProcessor.event(CometEvent.NOTIFY/READ)
6. Servlet calls a CometEvent.getHttpServletRequest().read()
7. Servlet calls CometEvent.notify(READ|WRITE); - this servlet wants to
be notified when it can write or read data
8. CometProcessor.event(CometEvent.NOTIFY/WRITE);
9. Servlet calls a CometEvent.getHttpServletResponse().write(bbuf)
10. Under the hood, write is being done when it can write until the
buffer is empty
11. CometProcessor.event(CometEvent.NOTIFY/WRITE_COMPLETE)
12. Servlet calls CometEvent.notify(WRITE); - notify me when I can write
again
13. Data arrives on the socket again
14. CometProcessor.event(CometEvent.NOTIFY/READ);
so this whole time I thought the notify() method is a call from the
servlet to the container.
The Comet servlet "register" actions it wants to be notified of.
And basically, this way, we disallow any writes or reads from a "user"
thread when the Poller is in use.
There is tons of use cases here, I wanted to point out another, where it
is legal for a user thread to read/write.
1. CometProcessor.event(CometEvent.BEGIN/null)
2. Servlet calls CometEvent.setBlocking(false);
3. Servlet calls CometEvent.notify(NONE) - dont register me for any events
4. Servlet Background thread calls
CometEvent.getHttpServletRequest().read() - could return 0 if no data is
available
5. Servlet Background thread calls
CometEvent.getHttpServletResponse().write()
Servlet can call CometEvent.canWrite(), if returns false, subsequent
request to write will throw an exception
When write has been completed, CometEvent.NOTIFY/WRITE_COMPLETE is sent
to CometProcessor.event
One more use case, similar to above, but blocking
1. CometProcessor.event(CometEvent.BEGIN/null)
2. Servlet calls CometEvent.setBlocking(true);
3. Servlet calls CometEvent.notify(NONE) - dont register me for any events
4. Servlet Background thread calls
CometEvent.getHttpServletRequest().read() - will not return until data
is available
5. Servlet Background thread calls
CometEvent.getHttpServletResponse().write() - will not return until all
data has been written
Is this too convuluted? We could also relax on the first use case, that
when a CometEvent.NOTIFY/WRITE event arrives, the servlet doesn't have
to write right away,
but actually can invoke write using a background thread.
Another use case, the servlet wants to close down the connection
1. CometEvent.notify(NOW)
2. CometProcessor.event(CometEvent.NOTIFY/NOW)
3. Servlet calls CometEvent.close
do you feel like we are spinning circles, starting over or simply making
it too complex?
Filip
So main difference, Comet
Filip
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
