Re: NPE in coyote InternalNioOutputBuffer
a) are not thread-safe
b) are cached and reused for subsequent incoming requests.
Thanks for helpful response.
I did not expect these tomcat features...
Now I am reinspecting my implementation and I have found one place that
seems fuzzy to me.
public void onTimeout(AsyncEvent ae) throws IOException {
ae.getAsyncContext().getResponse().getWriter().write(no changes);
}
There is not much in the documentation.
AsyncListener has method onTimeout. I am using it to inform subscribers
that there is no change. Is it legal to sent back some response on timeout
(like no changes) ? No recycle can happen during this action ? I have
looked in the sources and request recycle is called after this listener is
executed.
I just want to be sure that this order is always the same and any other
tomcat feature will not interfere.
best regards
Peter Cipov
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
NPE in coyote InternalNioOutputBuffer
Hello
I have the commet application - some sort of event bus where requests are
turned in async mode then stored in internal cache and when event occures
/ or request times out response is sent back to subscriber (it is handled
with my executor worker threads).
It worked fine until I have added a line with calling flushBuffer on
response object. My goal was to mark the connection as commited - I am
checking whether I have already written to this response
(response.isCommited()) in some other part of my code.
Now errors like these pop out in my logs
java.lang.NullPointerException
at
org.apache.coyote.http11.InternalNioOutputBuffer.addToBB(InternalNioOutputBuffer.java:210)
at
org.apache.coyote.http11.InternalNioOutputBuffer.commit(InternalNioOutputBuffer.java:202)
at
org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:765)
at org.apache.coyote.Response.action(Response.java:174)
at org.apache.coyote.Response.sendHeaders(Response.java:354)
at
org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:330)
at
org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:306)
at org.apache.catalina.connector.Response.flushBuffer(Response.java:568)
at
org.apache.catalina.connector.ResponseFacade.flushBuffer(ResponseFacade.java:307)
my code calling flushBuffer() on HttpResponse object
worker thread
public void send(HttpServletResponse response) { // calling from worker
threads
if (response.isCommitted()) {
throw new IOException(ERROR);
}
response.getWriter().print(RESPONSE);
response.flushBuffer(); // FAILED HERE
}
Did I miss some curtial lesson about flushing async responses ?
PS.
By the way that NPE should never occur - Is it a BUG ? I am using Tomcat
7.0.28 (current in debian 7.0 Wheezy)
--
Peter Cipov
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Null pointer when calling getRemoteAddr in exception handling
Hello, I have encountered ambiguous feature/bug of request ...servlet code ... throw new LoginException(String.format(Login failed for user %s from IP %s (%s), principalName, request.getRemoteAddr(), type ), ex); .. throws java.lang.NullPointerException at org.apache.coyote.http11.Http11AprProcessor.actionInternal(Http11AprProcessor.java:272) at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:834) at org.apache.coyote.Request.action(Request.java:346) at org.apache.catalina.connector.Request.getRemoteAddr(Request.java:1280) at org.apache.catalina.connector.RequestFacade.getRemoteAddr(RequestFacade.java:517) but this equivalent code works as it should ...servlet code ... String remoteAddr = request.getRemoteAddr(); throw new LoginException(String.format(Login failed for user %s from IP %s (%s), principalName, remoteAddr, type ), ex); .. Is this correct behavior ? -- Peter Cipov - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Multiple session cookies names
Hello, I would like to use multiple session cookie names in tomcat and tomcat chooses http attribute. For example: SESSION_APP_CLIENT - for fronted application SESSION_APP_ADMIN - for admin part I would like to have separate sessions for security reasons and for possibility to have opened tab per application module in browser (one for user, and one for admin) with separate sessions. I have an application deployed on root level and I am using tomcat 7. In current state, tomcat uses standard JSESSIONID or string value defined context.xml It is there a way to accomplish this? Best Regards -- Peter Cipov - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple session cookies names
Can you be more specific please ? Dne Mon, 17 Oct 2011 12:00:18 +0200 Mark Thomas ma...@apache.org napsal(a): On 17/10/2011 10:31, Peter Cipov wrote: Hello, I would like to use multiple session cookie names in tomcat and tomcat chooses http attribute. For example: SESSION_APP_CLIENT - for fronted application SESSION_APP_ADMIN - for admin part I would like to have separate sessions for security reasons and for possibility to have opened tab per application module in browser (one for user, and one for admin) with separate sessions. I have an application deployed on root level and I am using tomcat 7. In current state, tomcat uses standard JSESSIONID or string value defined context.xml It is there a way to accomplish this? Yes. Read the servlet 3 spec and/or the Context configuration docs. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Method to discover client disconnection on tomcat 7.0.16 with async servlet
Hello,
I have encountered this rather strange problem in tomcat 7:
I have a servlet that process requests witch asynchronous API
(async-supported=true):
AsyncContext async = req.startAsync(req, resp);
async.addListener(...);
async.setTimeout(8*60*1000);
addToMap(id, async.getResponse());
I store response in some map for further reuse.
Problem comes when user closes connection (standard socket.close()) before
timeout. There is no signal from server that this happened, and everything
works the same way.
on async signal do { // every few sec.
try {
writer = response.getWriter();
writer.print(object);
writer.flush();
} catch(Exception ex) {
//invalid connection do something
}
}
This part of code was used as for sending response. Invalid connections
should be discovered when
IOExceptions was thrown while flushing. But there is no exception when
client disconnects before timeout. Writer is flushing somewhere without
exception. The only exception that is thrown is timeout exception after 8
minutes. So it is doing lot of redundant calls before handling.
This code works as I wish with CometProcessor.
So is there some way to discover that client has closed connection or this
is the standard behavior.
I used tomcat 7.0.16 with APR (windows 7)
Peter Cipov
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
