RE: Connection is closed when CometEvent.close is called during an event
-Original Message- From: Konstantin Kolinko Sent: Friday, June 11, 2010 4:46 AM To: Tomcat Users List Subject: Re: Connection is closed when CometEvent.close is called during an event Regarding Comet + Keep-Alive, if it does not work, it is worth filing an enhancement request against Tomcat 7. It would be easier if there were some sample code or better a test case. This new use case has to be tested. I have had a look at Tomcat 7 and recognized that with Tomcat 7 I would probably refactor my application to use Servlet 3 conforming asynchronous processing instead of the CometProcessor interface. I assume that keep alive will be supported in conjunction with async processing? Then, it would no longer make sense using the CometProcessor interface to implement long poll. However, I am not sure if it will be possible for us to change to Tomcat 7 soon. From the release notes I read that it requires Java 6 and I suspect that we will be bound to Java 5 for quite a while. Hence, is there also any interest in respective improvements for Tomcat 6? Then I could provide an example servlet as a patch. Regards, Matthias - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Connection is closed when CometEvent.close is called during an event
Konstantin Kolinko wrote: 2010/6/11 Reich, Matthias matthias.re...@siemens-enterprise.com: The concept of long poll is e.g. described in http://www.javaworld.com/javaworld/jw-03-2008/jw-03-asynchhttp .html?page=6 The sequence of events in my situation is as follows: - a poll request is received by the server - the CoyoteAdapter.service method is called and in turn invokes the servlet's event method with a BEGIN event - request.isComet() is still true when the control returns to the CoyoteAdapter.service method - some other thread writes a response and closes the Writer of the response - the CoyoteAdapter.event method is called and in turn invokes the servlet's event method with an END event - the servlet calls event.close() - when the control returns to the CoyoteAdapter.event method we have exactly this situation: response.isClosed() !request.isComet() status==SocketStatus.OPEN - thus, if the error flag is set in this situation, the connection will be closed, and a new connection must be opened by the browser for the subsequent poll request According to the above sequence I would expect that the connection is always closed if request.isComet() is still true when control returns to the CoyoteAdapter.service method after processing the BEGIN event - no matter how long it takes from then until the response is written. Surprisingly, I did not always observe this. Anyway, if the error flag is not set in this situation, the connection is kept open. --- C:\DOCUME~1\rm041693\LOCALS~1\Temp\CoyoteAdapter.java-revBASE. svn001.tmp.java Do Jun 10 22:22:20 2010 +++ D:\tomcat\TOMCAT_6_0_26\java\org\apache\catalina\connector\Coy oteAdapter.java Mo Jun 7 17:30:23 2010 @@ -215,7 +215,9 @@ //CometEvent.close was called during an event. request.getEvent().setEventType(CometEvent.EventType.END); request.getEvent().setEventSubType(null); - error = true; + // don't set the error flag - otherwise the socket will be closed + // whenever CometEvent.close is called during the event + // error = true; connector.getContainer().getPipeline().getFirst().event(reques t, response, request.getEvent()); } res.action(ActionCode.ACTION_COMET_END, null); Now I understand. Thank you. I would say that you are trying to combine Comet and Keep-Alive. Well, it actually was combined (maybe unintentionally) in 6.0.18. (I retested an older version of our application which uses 6.0.18 and didn't observe that connections were closed in similar situations.) Since 6.0.20, the connections are closed upon event.close(), but it took me some time to get aware of this because when the subsequent request fails due to the close, the browsers silently retry that request. In comet to send a portion of data (a response), you do writer.flush(). It sends the data over the wire. Doing event.close() terminates comet request processing. If it were possible not to close the connection, it were possible to alternate comet and non-comet processing of subsequent requests over the same connection, and to process different requests by different servlets. - some other thread writes a response and closes the Writer of the response Response object is not thread safe. You must write your response in the thread that received your EventType.READ event (or any other event) while you are processing that event. Otherwise, any random result might happen. Doesn't the sample code on the documentation page include async writes as well? When it gets a READ event from one connection it writes to all open connetions. With respect to all other connections, this is an async write. In a long poll scenario, closing the Writer seems to be the only way to trigger a further event (i.e. an END event) after the BEGIN event. BTW, for reference: There exists the following documentation page, http://tomcat.apache.org/tomcat-6.0-doc/aio.html#CometEvent and sample code in webapps/examples/WEB-INF/classes/chat/ChatServlet.java plus some helper JSPs. The sample is callable as http://localost:8080/examples/jsp/chat/chat.jsp in Tomcat 6.0.26 and earlier http://localost:8080/examples/jsp/chat/index.jsp in Tomcat 7 and in Tomcat 6.0.27 and later Regarding Comet + Keep-Alive, if it does not work, it is worth filing an enhancement request against Tomcat 7. It would be easier if there were some sample code or better a test case. This new use case has to be tested. I'll try to find the time to prepare something. In the repository (6.0.26) I have not detected any Comet related test cases. Are there any test cases you could recommend as an example of how I should organize it? What
RE: Connection is closed when CometEvent.close is called during an event
On 10/06/2010 9:49 PM, Konstantin Kolinko wrote:
2010/6/8 Reich, Matthias:
I modified the code (in 6.0.20 and 6.0.26) so that the
error flag is not set.
With that change Tomcat kept the connection open:
...
if (response.isClosed() || !request.isComet()) {
if (status==SocketStatus.OPEN) {
//CometEvent.close was called during an event.
request.getEvent().setEventType(CometEvent.EventType.END);
request.getEvent().setEventSubType(null);
// don't set the error flag here - otherwise the connection
will be closed
// whenever a long poll is answered already during event handling:
// error = true;
1. I think that I do not understand you. What is your meaning of long
poll? Can you describe your situation as a sequence of events how
they occur step-by-step on a timeline?
The concept of long poll is e.g. described in
http://www.javaworld.com/javaworld/jw-03-2008/jw-03-asynchhttp.html?page=6
The sequence of events in my situation is as follows:
- a poll request is received by the server
- the CoyoteAdapter.service method is called and in turn
invokes the servlet's event method with a BEGIN event
- request.isComet() is still true when the control returns
to the CoyoteAdapter.service method
- some other thread writes a response and closes the Writer
of the response
- the CoyoteAdapter.event method is called and in turn
invokes the servlet's event method with an END event
- the servlet calls event.close()
- when the control returns to the CoyoteAdapter.event method
we have exactly this situation:
response.isClosed() !request.isComet() status==SocketStatus.OPEN
- thus, if the error flag is set in this situation,
the connection will be closed, and a new connection must be opened
by the browser for the subsequent poll request
According to the above sequence I would expect that the connection
is always closed if request.isComet() is still true when control
returns to the CoyoteAdapter.service method after processing
the BEGIN event - no matter how long it takes from then
until the response is written.
Surprisingly, I did not always observe this.
Anyway, if the error flag is not set in this situation,
the connection is kept open.
2. The above fragment when using Comet should be equivalent to
if (response.isClosed()) {
if (status==SocketStatus.OPEN) {
//CometEvent.close was called during an event.
request.getEvent().setEventType(CometEvent.EventType.END);
request.getEvent().setEventSubType(null);
// don't set the error flag here - otherwise the connection
will be closed
// whenever a long poll is answered already during event handling:
// error = true;
Response#isClosed():
public boolean isClosed() {
return outputBuffer.isClosed();
}
No, it is not equivalent: response.isClosed() is true after closing
the Writer or OutputStream, whereas request.isComet() is true
until event.close() is called.
If you will not be able to send your answer, why not to close the
socket right away?
I was able to send the answer and would like to use the connection
also for the next poll request. (or for some other request
the browser decides to send through this connection)
3. It would be much more readable, if you provided your changes in the
unified diff format. (even better if it were generated with svn diff
command against sources retrieved from svn).
---
C:\DOCUME~1\rm041693\LOCALS~1\Temp\CoyoteAdapter.java-revBASE.svn001.tmp.java
Do Jun 10 22:22:20 2010
+++
D:\tomcat\TOMCAT_6_0_26\java\org\apache\catalina\connector\CoyoteAdapter.java
Mo Jun 7 17:30:23 2010
@@ -215,7 +215,9 @@
//CometEvent.close was called during an event.
request.getEvent().setEventType(CometEvent.EventType.END);
request.getEvent().setEventSubType(null);
-error = true;
+// don't set the error flag - otherwise the socket
will be closed
+// whenever CometEvent.close is called during the event
+// error = true;
connector.getContainer().getPipeline().getFirst().event(request, response,
request.getEvent());
}
res.action(ActionCode.ACTION_COMET_END, null);
Best regards,
Konstantin Kolinko
Regards,
Matthias
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Connection is closed when CometEvent.close is called during an event
Hello,
I am using a CometProcessor servlet in a long-poll scenario, and recently had
a closer look at the life span of connections that are used for poll requests.
I noticed that connections are closed by Tomcat whenever a poll request
was answered (and closed) directly during processing of the BEGIN event.
In our application this happens for one out of three poll requests approximately
and thus should not be neglected.
I had a look into the source code and found the reason in the
CoyoteAdapter.event method - it sets the 'error' flag to true in this situation.
I modified the code (in 6.0.20 and 6.0.26) so that the error flag is not set.
With that change Tomcat kept the connection open:
...
// Calling the container
connector.getContainer().getPipeline().getFirst().event(request, response,
request.getEvent());
if (!error !response.isClosed()
(request.getAttribute(Globals.EXCEPTION_ATTR) != null)) {
// An unexpected exception occurred while processing the event, so
// error should be called
request.getEvent().setEventType(CometEvent.EventType.ERROR);
request.getEvent().setEventSubType(null);
error = true;
connector.getContainer().getPipeline().getFirst().event(request,
response, request.getEvent());
}
if (response.isClosed() || !request.isComet()) {
if (status==SocketStatus.OPEN) {
//CometEvent.close was called during an event.
request.getEvent().setEventType(CometEvent.EventType.END);
request.getEvent().setEventSubType(null);
// don't set the error flag here - otherwise the connection will be closed
// whenever a long poll is answered already during event handling:
// error = true;
connector.getContainer().getPipeline().getFirst().event(request,
response, request.getEvent());
}
res.action(ActionCode.ACTION_COMET_END, null);
} else if (!error read request.getAvailable()) {
// If this was a read and not all bytes have been read, or if no data
// was read from the connector, then it is an error
request.getEvent().setEventType(CometEvent.EventType.ERROR);
request.getEvent().setEventSubType(CometEvent.EventSubType.IOEXCEPTION);
error = true;
connector.getContainer().getPipeline().getFirst().event(request,
response, request.getEvent());
}
return (!error);
...
In my first tests I did not observe any undesired side effects of the change.
However, I did not yet do extensive tests - especially not with a steaming
client.
Do you agree that this should be considered a bug and fixed in the next Tomcat
release?
Regards,
Matthias
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Can we slow down the speed of servlet response ?
Hi, if your simulation really requires waiting on server side, you could also have a look at Comet (http://tomcat.apache.org/tomcat-6.0-doc/aio.html). A Comet solution would not block a thread per request while waiting for the timeout condition. By the way, when using the Http11NioProtocol on a Linux box, you should consider this: http://www.mail-archive.com/users@tomcat.apache.org/msg36968.html -- Matthias -Original Message- From: Wang Han [mailto:[EMAIL PROTECTED] Sent: Thursday, April 24, 2008 11:25 AM To: Tomcat Users List Subject: Re: Can we slow down the speed of servlet response ? Hi Chris, Just received the latest version NM software and it works well with Thread.sleep works now. It seems old NM SW bug caused Thread.sleep() failed. the latest NM will send 60 concurrent requests maximum and I configured the Connector element as: Connector protocol=org.apache.coyote.http11.Http11NioProtocol port=8443 enableLookups=true disableUploadTimeout=true acceptCount=250 maxThreads=250 connectionTimeout=2... Not sure whether it can meet the NM requirement , any suggestion? I just get a Linux box with 1G memory to host my Servlet.Will update you after I finish the test. B.R Han On Fri, Apr 18, 2008 at 7:47 PM, Christopher Schultz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Han, Wang Han wrote: | I have tried Thread.sleep() in my servlet and it fails. | My NM app throws exception and can't handle such response.. What exception is thrown? I can't see a reason why Thread.sleep wouldn't work. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgIijwACgkQ9CaO5/Lv0PBFHACfaRiSezHeWHpnaPI/2NRyqGR2 nZsAn32xEYEJ3VzREBoDaFC3iLZyC7Q3 =Jnab -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Share session cookie across subdomains
Hi,
I haven't thought about the idea in detail, but would it be possible to
wrap the response?
The wrapper would have to ensure that cookie replacement is applied
before any data is written to the output stream or writer.
A remaining issue would be that encoded (redirect-) URLs in the response
must also be modified.
-- Matthias
-Original Message-
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 23, 2008 9:51 PM
To: Tomcat Users List
Subject: Re: Share session cookie across subdomains
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zach,
Zach Cox wrote:
| Hi Chris - I'm not sure what this will accomplish:
|
| public Request(Request wrapped)
| {
| ~this.wrapped = wrapped;
| }
|
| public whatever doWhatever(args)
| {
| ~super.doWhatever(args);
| }
|
| 1) this.wrapped is never used so what's the point of saving it?
Sorry, I meant wrapper.doWhatever(args);
I've taken a closer look at this class and my suggestion is impossible
as there is a final method in the class. :(
Looks like valves are not nearly as useful as they should be. double :(
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgPkzoACgkQ9CaO5/Lv0PB1fgCgutaBFqLgjPK2H16yWJ04YxAn
D3oAn0eLFzc8sHiWft3yKvtxFIbRLryI
=hwi6
-END PGP SIGNATURE-
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Share session cookie across subdomains
With your implementation, the valve will have the effect that a session
is created upon first access to a server,
not only when required by the application.
(see also discussion on
http://www.nabble.com/Cookie-less-session-tracking---whats-are-the-downs
ides-tp16738472p16738472.html )
Thus, the valve is only suitable if this behavior is acceptable.
(e.g. if you can be sure that your site is not accessed by search engine
robots, if you have a rather short session timeout and can live with the
overhead of creating many unnecessary session objects, ...)
-- Matthias
-Original Message-
From: Zach Cox [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 19, 2008 10:26 PM
To: users@tomcat.apache.org
Subject: Share session cookie across subdomains
I'm working on a site that has a single web app in Tomcat that handles
lots of subdomains via wildcard DNS:
- site.com
- www.site.com
- sub1.site.com
- sub2.site.com
- etc.
Basically, the site content gets customized based on the subdomain in
the request, if any. However I ran into a problem where Tomcat would
use separate JSESSIONID session cookies on each different domain which
causes problems as the user would have multiple sessions if they
switched subdomains.
I found an examle Valve at http://www.esus.be/blog/?p=3 but it
ultimately did not result in a cross-subdomain session cookie (at
least in the Tomcat 6.0.14 I'm using). I'm posting the Valve that did
actually seem to solve the problem for me below in hopes that it will
help someone else with the same problem in the future.
Basically you end up with a single session cookie with its domain set
to .site.com so the client will send it back in the request for any
subdomain.
Usage:
- compile CrossSubdomainSessionValve put it in a .jar file
- put that .jar file in $CATALINA_HOME/lib directory
- include a Valve
className=org.three3s.valves.CrossSubdomainSessionValve/ in
$CATALINA_HOME/conf/server.xml
If you see/experience any problems please let me know!
Thanks,
Zach
package org.three3s.valves;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import org.apache.catalina.*;
import org.apache.catalina.connector.*;
import org.apache.catalina.valves.*;
import org.apache.tomcat.util.buf.*;
import org.apache.tomcat.util.http.*;
/** pReplaces the domain of the session cookie generated by Tomcat
with a domain that allows that
* session cookie to be shared across subdomains. This valve digs
down into the response headers
* and replaces the Set-Cookie header for the session cookie, instead
of futilely trying to
* modify an existing Cookie object like the example at
http://www.esus.be/blog/?p=3. That
* approach does not work (at least as of Tomcat 6.0.14) because the
* codeorg.apache.catalina.connector.Response.addCookieInternal/code
method renders the
* cookie into the Set-Cookie response header immediately, making any
subsequent modifying calls
* on the Cookie object ultimately pointless./p
*
* pThis results in a single, cross-subdomain session cookie on the
client that allows the
* session to be shared across all subdomains. However, see the
[EMAIL PROTECTED] getCookieDomain(Request)}
* method for limits on the subdomains./p
*
* pNote though, that this approach will fail if the response has
already been committed. Thus,
* this valve forces Tomcat to generate the session cookie and then
replaces it before invoking
* the next valve in the chain. Hopefully this is early enough in the
valve-processing chain
* that the response will not have already been committed. You are
advised to define this
* valve as early as possible in server.xml to ensure that the
response has not already been
* committed when this valve is invoked./p
*
* pWe recommend that you define this valve in server.xml
immediately after the Catalina Engine
* as follows:
* pre
* lt;Engine name=Catalina...gt;
* lt;Valve
className=org.three3s.valves.CrossSubdomainSessionValve/gt;
* /pre
* /p
*/
public class CrossSubdomainSessionValve extends ValveBase
{
public CrossSubdomainSessionValve()
{
super();
info = org.three3s.valves.CrossSubdomainSessionValve/1.0;
}
@Override
public void invoke(Request request, Response response) throws
IOException, ServletException
{
//this will cause Request.doGetSession to create the session
cookie if necessary
request.getSession(true);
//replace any Tomcat-generated session cookies with our own
Cookie[] cookies = response.getCookies();
if (cookies != null)
{
for (int i = 0; i cookies.length; i++)
{
Cookie cookie = cookies[i];
containerLog.debug(CrossSubdomainSessionValve: Cookie
name is + cookie.getName());
if
(Globals.SESSION_COOKIE_NAME.equals(cookie.getName()))
replaceCookie(request, response, cookie);
}
}
//process the next valve
RE: different context on different ports, but one tomcat
If the webapps shall be completely isolated and shall not share connectors it could be an option to define three separate services in server.xml. Then the transport guarantee for webapp2 is given by the server configuration. You should be aware that you must assign separate thread pools to each connector and thus need more resources than if your webapps can share a connector. -- Matthias Server port=8005 shutdown=SHUTDOWN !-- listener and resource definitions skipped -- Service name=Catalina1 Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 / Engine name=Catalina1 defaultHost=localhost !-- Valve, realm etc. skipped -- Host name=localhost appBase=webapps1 unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false /Host /Engine /Service Service name=Catalina2 Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS / Engine name=Catalina2 defaultHost=localhost !-- Valve, realm etc. skipped -- Host name=localhost appBase=webapps2 unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false /Host /Engine /Service Service name=Catalina3 Connector port=7080 address=127.0.0.1 protocol=HTTP/1.1 / Engine name=Catalina3 defaultHost=localhost !-- Valve, realm etc. skipped -- Host name=localhost appBase=webapps3 unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false /Host /Engine /Service /Server -Original Message- From: Szabolcs Márton [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 20, 2008 5:54 PM To: users@tomcat.apache.org Subject: different context on different ports, but one tomcat Hi! anybody has idea what should i do, when i would like the following to happen: I have ONE instance of Tomcat with 3 different webapps (context) instance#1: accept connection only on port 80 from anywhere instance#2: accept connections only on https port from anywhere instance#3 accept connections on port 7080 but only from localhost this is possible in tomcat? firstly only with tomcat, no firewall or apache! if it is not possible, that any tricks appropiated :) thx Saby - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Logging in separate Thread
I think it is better to start one background worker thread and pass the log requests to that thread with the help of a queue. You can also consider to let the worker cache the DNS lookup results. (Usually you will see requests from the same clients lots of times.) - Matthias -Original Message- From: Jan Mönnich [mailto:[EMAIL PROTECTED] Sent: Thursday, February 14, 2008 4:56 PM To: Tomcat Users List Subject: Logging in separate Thread Hi folks, we want to log just the domain name a user comes from. As the required DNS reverse lookup can take some time, we would like to do the lookup and the logging in a separate thread. Is it a good idea to just start a new thread for that from a servlets doPost() method? Thanks in advance! Jan -- Dipl.-Inf. (FH) Jan Mönnich, PKI Team Phone: +49 40 808077-632, Fax: +49 40 808077-556, [EMAIL PROTECTED] DFN-CERT Services GmbH, https://www.dfn-cert.de, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Sachsenstraße 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski 15 Jahre DFN-CERT + 15. DFN-Workshop Sicherheit in vernetzten Systemen am 13./14. Februar 2008 im CCH Hamburg - https://www.dfn-cert.de/ws2008/ - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: NIO connector
Hi,
I am doing it this way:
Connector c = new Connector(protocol);
c.setPort(port);
if (secure)
{
c.setScheme(https);
c.setSecure(true);
}
// now set further attributes as required
- Matthias
-Original Message-
From: brien colwell [mailto:[EMAIL PROTECTED]
Sent: Friday, February 01, 2008 6:45 AM
To: Tomcat Users List
Subject: Re: NIO connector
hi Filip,
Still no success there ... I think I'm missing something fundamental.
Just in case anyone is interested, I'm running Tomcat 6.0.13, JDK
1.6.0_04, with libnative for the APR connector. I'm going to stick to
APR for now ... I wanted to run a benchmark, but it's not critical.
Best regards,
Brien
On Jan 31, 2008 5:50 PM, Filip Hanik - Dev Lists [EMAIL PROTECTED]
wrote:
Connector c =
e.createConnector((String)null,8080,org.apache.coyote.http11.Http11NioP
rotocol);
Filip
brien colwell wrote:
hi Filip,
Thanks for the tip. Any thoughts on why createConnector would give
null?
embedded.createConnector( (InetAddress) null, port,
org.apache.coyote.http11.Http11NioProtocol );
Brien
On Jan 31, 2008 7:15 AM, Filip Hanik - Dev Lists
[EMAIL PROTECTED] wrote:
use
public Connector createConnector(String address, int port,String
protocol)
set org.apache.coyote.http11.Http11NioProtocol as the protocol
value
should work
Filip
brien colwell wrote:
hi all --
I'm trying to hook the NIO connector to an engine, but I'm lost in
how
to do this. I'm using Tomcat embedded, so I have an Engine
instance,
from which I have a Session object. Can anyone take me from there?
Thanks!
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Subclass of Servlet: Inherited method is not visible
You should ask the implementors of ParameterMethodResolvingServlet
(according to Google this seems to a project within dfki), or look at
it's implementation.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 23, 2008 12:24 PM
To: users@tomcat.apache.org
Subject: Subclass of Servlet: Inherited method is not visible
Hi,
The following schematically describes my setup. Basically, there are two
servlets, one being a subclass of the other:
public class ServletA extends ParameterMethodResolvingServlet {
public void init() { ... }
public void methodA() { ... }
}
public class ServletB extends ServletA {
public void init() {
super.init();
...
}
}
The web.xml contains a mapping to ServletB. When I issue an ajax request
to that servlet calling methodA(), the following error occurs:
HTTP ERROR: 501 No such method: methodA
But everything runs fine when I change ServletB to:
public class ServletB extends ServletA {
public void init() {
super.init();
...
}
public void methodA() {
super.methodA();
}
}
Since it is inherited, I expect Tomcat to actually see methodA()
without
the workaround as shown above.
I am using Tomcat 5.5.25 and Java 1.6.0_03
Any help will be appreciated.
Paul Pichota
-
This email was sent using SquirrelMail.
Webmail for nuts!
http://squirrelmail.org/
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Comet Development
I think you need to explain a little more on what you want to achieve by using comet with JSPs. The JSP processing model is bound to the traditional Servlet processing model, and a compiled JSP is a traditional Servlet - not a Comet Servlet. I am not sure if including response snippets generated by a JSP into the response stream via a call to RequestDispatcher.include would work. Regards, Matthias -Original Message- From: Siobhan [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 8:24 PM To: 'Tomcat Users List' Subject: RE: Comet Development Ok. But how is it all suppose to be put together? I want to use comet using jsp, but I don't see any jsp code. -Original Message- From: Peter Warren [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 12:42 PM To: Tomcat Users List Subject: Re: Comet Development This post (http://www.nabble.com/comet-questions-td14673697.html#a14673697) contains test code for both a client comet servlet. See if it helps. On Jan 16, 2008 10:35 AM, Siobhan [EMAIL PROTECTED] wrote: To anyone who has successfully used Comet: I've been trying to use Comet with Tomcat 6.0 for a few weeks now and have been unsuccessful. I'm so frustrated with the lack of documentation and the unusable example that was given with Tomcat. Are there any step-by-step instructions on how to successfully implement a test program? -SB - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 6 embedded use - problems with jsp - No Java compiler available
Hi Oliver, I would guess that a library is missing in your classpath. I am also using Tomcat in embedded mode, and I had seen the same kind of error because I missed to add el-api.jar to the classpath. These are the tomcat libraries I have included and which are sufficient (without any further jasper setup) to compile and run JSPs: annotations-api.jar catalina.jar el-api.jar jasper.jar jasper-el.jar jasper-jdt.jar jsp-api.jar servlet-api.jar tomcat-coyote.jar tomcat-juli.jar tomcat-juli-adapters.jar Regards, Matthias -Original Message- From: olk [mailto:[EMAIL PROTECTED] Sent: Thursday, January 17, 2008 10:33 AM To: users@tomcat.apache.org Subject: Re: Tomcat 6 embedded use - problems with jsp - No Java compiler available Hi, I found a first hint on my own - it is probably related to setting-up jasper correctly - but I hope someone can tell me how to set the parameter for jasper in embedded mode. What I did was: // Create a handler for jsps Wrapper jspServlet = context.createWrapper(); jspServlet.setName(jsp); jspServlet.setServletClass(org.apache.jasper.servlet.JspServlet); jspServlet.addInitParameter(fork, false); jspServlet.addInitParameter(xpoweredBy, false); jspServlet.setLoadOnStartup(2); context.addChild(jspServlet); context.addServletMapping(*.jsp, jsp); context.addServletMapping(*.jspx, jsp); But it seams not enough for embedded mode. I think I have to set also classpath , compiler ,compilerSourceVM , compilerTargetVM. But I do not know where to point them in embedded mode ??? Is there somebody who can help me on this ? Thx. -- View this message in context: http://www.nabble.com/Tomcat-6-embedded-use---problems-with-jsp---No-Jav a-compiler-available-tp14881179p14915285.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
I think the problem arises because
a.public static final boolean IS_SECURITY_ENABLED =
(System.getSecurityManager() != null);
is more a macro definition than a constant definition.
But as Java does not support macros, the compiler cannot replace
occurrences of 'IS_SECURITY_ENABLED' with
'System.getSecurityManager() != null)'
b. As there are multiple classes named 'Constants' in different
packages,
there is no import declaration for org.apache.coyote.Constants in the
Http11Processor class because it would clash with
org.apache.coyote.http11.Constants.
I would guess that with an import declaration the 'Constants' class
would have been resolved earlier by the class loader.
If this is the case, there would be different ways to solve the problem:
1. use
import static org.apache.coyote.Constants.IS_SECURITY_ENABLED;
This is possible since Java 5 and allows to refer to IS_SECURITY_ENABLED
in the code without a package/class qualifier.
I am not sure if this would solve the issue, but it is an easy trial
(afaik Tomcat 6 requires Java 5 anyway).
2. org.apache.coyote.http11.Constants extends
org.apache.coyote.Constants
I have not checked if there would be name conflicts between declartions
in these packages, but if there are any,
I would try to resolve them anyway.
However, this would not allow to declare the Constants classes final.
I am not sure if this has any impact.
3. refactor the class names to avoid name clashes (CoyoteConstants,
CoyoteHttp11Constants, ...)
4. introduce a new class
package org.apache.coyote;
public final class CoyoteMacros
{
public static final boolean IS_SECURITY_ENABLED =
(System.getSecurityManager() != null);
}
- Matthias
-Original Message-
From: Delian Krustev [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 06, 2007 10:18 AM
To: Tomcat Users List
Subject: Re: AccessControlException in Coyote Http11Processor (Tomcat
6.0.14). Bug in Coyote ?
On Wed, 05 Dec 2007 22:13:00 + Mark Thomas wrote:
Did it happen straight away or did it work for a while and then fail?
Dec 3, 2007 10:14:24 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 152362 ms
..
Dec 3, 2007 10:17:22 PM org.apache.catalina.core.ApplicationDispatcher
invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.security.AccessControlException: org/apache/coyote/Constants
I've tried it about 3 minutes after the restart.
I am beginning to think that
http://svn.apache.org/viewvc?view=revrev=505593 introduced a subtle
timing
issue. If Tomcat internal code causes Constants to be loaded,
everything is
fine. If the webapp code causes Constants to be loaded, it fails.
It goes live straight away, so I suppose some request from user web
application might have already been served.
I've been observing this problem for quite a while, and it has been
there all
the time.
The HTTP connector stays unused because of this problem.
You might be right - may be the last time it did not appear because my
test
was done prior to a request to an application that triggers it.
The fix would be to revert to the (System.getSecurityManager() !=
null)
test.
I'd be glad to test the patch.
Cheers
--
Delian
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: log4j error
Hi, another approach is the use of a RepositorySelector. - you rely on the container to provide the log4j classes and to install a suitable RepositorySelector (should happen as early as possible, e.g. in a ServerLifeCycleListener) - each webapp can still provide it's own logging configuration - the RepositorySelector may provide some fallback mechanism, i.e. use a default Logger Repository in case the webapp does not provide it's own configuration. I was once pointed to such a solution by the following article which explains the mechanism in more detail: http://www.qos.ch/logging/sc.jsp - Matthias -Original Message- From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Sent: Saturday, November 17, 2007 1:16 AM To: Tomcat Users List Subject: RE: log4j error From: Steven Crosley [mailto:[EMAIL PROTECTED] Subject: log4j error log4j:ERROR The class org.apache.log4j.Appender was loaded by log4j:ERROR [EMAIL PROTECTED] whereas object of type log4j:ERROR org.apache.log4j.ConsoleAppender was loaded by [WebappClassLoader This situation was reported earlier today in a different thread. The problem there was due to the following set of factors: 1) log4j*.jar in both Tomcat's lib directory and the webapp's WEB-INF/lib 2) classes from Tomcat's lib directory making references to log4j 3) classes from the webapp making references to log4j 4) classes from the webapp calling methods in classes from Tomcat's lib directory Even though the log4j jars may be identical, instances of log4j classes are not assignable across the different classloaders used for Tomcat's lib directory and the webapp. The quick fix is to get rid of the log4j*.jar in your WEB-INF/lib, but that precludes application-specifc logging. You could also move whatever classes from Tomcat's lib directory that the webapp needs into WEB-INF/lib, rather than having them in the common location. (This would be more in keeping with the servlet spec philosophy, which tries to keep webapps as independent as possible.) Or, you could rework your code a bit so the webapp passes a logging object to the methods that need it that come from Tomcat's lib directory, and insure that the shared classes don't hang onto that logger. There may be other solutions. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CLIENT-CERT authentication with APR connector only for protected resources?
Hi, is there a way to configure the APR connector in a way that it requests a client certificate only if the client accesses a resource that is protected by a security constraint? This works with a Java connector if I specify the option clientAuth=false. The client certificate is not requested from the browser unless I try to access a protected resource. However, with the APR connector, if I set SSLVerifyClient=none for the APR connector, a client certificate is never requested from the browser, and an attempt to access a protected resource returns an error. If I set SSLVerifyClient=optional, I am forced to send my certificate already when the connection is established, even if I only access resources that are not protected by a security constraint. Regards, Matthias - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Comet example at Tomcat 6
Perhaps you should add this to the example:
protected void service(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException
{
resp.sendError( HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
you must be using the APR or NIO connector to get the event
method called );
}
-Original Message-
From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 26, 2007 5:18 PM
To: Tomcat Users List
Subject: Re: Comet example at Tomcat 6
you must be using the APR or NIO connector
Connector
protocol=org.apache.coyote.http11.Http11NioProtocol //or
protocol=org.apache.coyote.http11.Http11AprProtocol
Filip
john x wrote:
Hi!
I just run the chat example ,but ,it seems did not work ;
the code seems can't reach the line
begin(event, request, response)
please help me fix that,thanks;
john
--
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.19/917 - Release
Date: 7/25/2007 1:16 AM
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Shared form authentication when using SingleSignOn
Hi, I had to solve a similar problem a while ago. The solution I found was a small Servlet that I deployed in the other webapps. This Servlet used a RequestDispatcher to dispatch the login/... requests to the login servlet of the main webapp. However, as far as I remember, the redirect back to the page the client had originally requested, does not work without modifications in the FormAuthenticator, as the FormAuthenticator does only save the context relative part of the URL. Regards, Matthias -Original Message- From: Jiri Walek [mailto:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 12:14 AM To: 'Tomcat Users List' Subject: RE: Shared form authentication when using SingleSignOn I have forgot to attach some details: * embeded apache-tomcat-5.5.16-embed.tar.gz running in eclipse 3.1 runtime platform * java 1.5 * both winxp server, linux Best, Jiri -Original Message- From: Jiri Walek [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 18, 2007 11:58 PM To: users@tomcat.apache.org Subject: Shared form authentication when using SingleSignOn Hello, please, consider the situation: We have a product that consists of several web applications deployed to embedded tomcat container. All the web applications share the same realm (configured on engine level) and use the SingleSignOn valve. engine.setRealm(polarionRealm); engine.getPipeline().addValve(new SingleSignOn()); The main web application is configured to use the FormAuthenticator. The login/logout pages work well for that application. So when user access the main web application and when he/she is properly authenticated than when accessing the other web applications the principal is properly passed to the other web application and user is not asked to log in again. Now the problem is: how should we configure the other web application to use the login/logout support of the main web application. In the web.xml one can specify login/logout actions but they are context relative. !-- Login configuration uses form-based authentication -- login-config auth-methodFORM/auth-method realm-namePolarionRealm/realm-name form-login-config form-login-page/login/login/form-login-page form-error-page/login/error/form-error-page /form-login-config /login-config Is there any standard pattern how to reach the goal that the login/logout support is implemented on one place (idealy in one very small webapp) and so many applications can share the auth context using SingleSignOn valve and the login webapp? Best, Jiri Walek Polarion Software - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 6.0.13 - NPE in AprEndpoint run method
Hi, When sending requests to Tomcat during the startup phase, I got a NPE in the AprEndpoint run method, line 1495: getPoller().add(socket); This can happen because in the start method, the pollers are initialized after the acceptor threads already have been started so that the getPoller() call can either run into a NPE itself (if the pollers array is not yet initialized) or return null (if pollers[pollerRoundRobin] is not yet initialized. Thus, I think the error can easily be prevented by starting the acceptors after initializing the pollers. Regards, Matthias - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: axis - tomcat loader constraint violation
Hi, it looks as if class javax/xml/rpc/Service was as well found in common/lib as in the WEB-INF/lib folder of your webapp. If the webapp classloader looks for this class, it will first look in webapps private resources. However, the class had been loaded and resolved before via the common classloader when some other class had referred to it. If javax/xml/rpc/Service would not be accessible via the webapp's private resources, the webapp classloader would delegate the task of loading the class to it's parent classloader, an then no conflict would arise. You should take care to have classes located *either* in the common classpath *or* in the webapp classpath, but not in both of them. Regards, Matthias -Original Message- From: E Koutsoudaki [mailto:[EMAIL PROTECTED] Sent: Friday, July 13, 2007 2:12 PM To: users@tomcat.apache.org Subject: axis - tomcat loader constraint violation Dear all, as part of a project I am working on I have to add to an existent Java based web application the functionality of retrieving information from the NCBI web service. I have generated the Java source files by following the instructions in the NCBI website at: http://www.ncbi.nlm.nih.gov/entrez/q...java_help.html The source files are created and they compile. For testing reasons I have implement a Java application (not web based) from which I was able to retrieve information from the NCBI resources. When integrate the source files into the web based application, again the project builds fine, but when running the following error occurs: java.lang.LinkageError: loader constraint violation: when resolving field service the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the referring class, org/apache/axis/client/Stub, and the class loader (instance of org/apache/catalina/loader/StandardClassLoader) for the field's resolved type, javax/xml/rpc/Service, have different Class objects for that type gov.nih.nlm.ncbi.www.soap.eutils.EUtilsServiceSoap Stub.init(EUtilsServiceSoapStub.java:201) gov.nih.nlm.ncbi.www.soap.eutils.EUtilsServiceSoap Stub.init(EUtilsServiceSoapStub.java:193) gov.nih.nlm.ncbi.http://www.soap.eutils.EUtilsService...ocator .java:55) gov.nih.nlm.ncbi.http://www.soap.eutils.EUtilsService...ocator .java:50) uk.ac.ed.gti.utilities.BioLayoutFile.getNCBIInfo(B ioLayoutFile.java:196) The web based application runs on a Tomcat server and the axis library files have been added in the common/lib folder of the web server so as the web server to be able to locate the libraries. The axis version I've used is the 1.4, Tomcat 5.5 and jdk 1.6.0_01. I have also tried by using the axis-1_2_1, and jdk1.5.0_12. and generally other combinations of those. I always keep Tomcat to 5.5 since this is the version of the existing web application. I would be grateful for any enlightenment about the occurring error. Thank you in advance. Elisavet Koutsoudaki - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: read data/infinite loop problem with comet
Hi,
my feeling is that the CoyoteAdapter does a check that should not be
done in this place (just because the implicit assumption is wrong that
nothing will happen concurrently during the few nano seconds between the
Servlet's available() check and the check of the adapter.)
It looks as if the CoyoteAdapter code does not want to rely on the
Servlet programmer to do the available() checks correctly and therefore
tries to avoid loops of read events which could result from incorrect
Servlet code.
You could try to simply remove the lines
} else if (!error read request.getAvailable()) {
// If this was a read and not all bytes have been
read, or if no data
// was read from the connector, then it
is an error
error = true;
log.error(sm.getString(coyoteAdapter.read));
}
from the CoyoteAdapter code and run your Comet Servlet with the modified
CoyoteAdapter.
If it works, suggest this modification as a bug fix.
Regards,
Matthias
-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 26, 2007 6:53 PM
To: Tomcat Users List
Subject: Re: read data/infinite loop problem with comet
Hi all,
I looked in the Tomcat source code (6.0.13), and I really do not
understand how I'm supposed to avoid the following error:
SEVERE: The servlet did not read all available bytes during the
processing of the read event
What seems to be happening is this:
In my event method():
while (request.getInputStream().available() 0) {
// read some data
}
// * NO MORE DATA AVAILABLE
return;
A bit later in CoyoteAdapter (187):
// *** SOME DATA ARRIVES SOMEWHERE HERE
} else if (!error read request.getAvailable()) {
// If this was a read and not all bytes have been
read, or if no data
// was read from the connector, then it
is an error
error = true;
log.error(sm.getString(coyoteAdapter.read));
}
return (!error);
I checked the source code, and CoyoteInputStream.available() and
Request.getAvailable() both return exactly the same value, namely
InputBuffer.available(). So it seems that between my return and this
check new data arrived has arrived, causing failure. What's worse, my
CometProcessor does not get notified (I don't know why) of the error,
and the Poller goes in an infinite loop.
Does anybody know how I can solve this problem?
Regards,
Sebastiaan
Sebastiaan van Erk wrote:
Hi,
I'm having a problem reading data in my Comet servlet.
In the BEGIN event I have the following loop:
while (request.getInputStream().available() 0) {
// log that in read loop, log available()
// read some data
}
// log that read loop is done, log available()
return;
However, even though I keep reading until available()
returns 0, I get
a SEVERE error complaining I did not read all the available data,
which can be seen from the following logs:
2007-06-26 14:37:08,427 DEBUG [http-8080-exec-4]
com.sebster.myservlet.TomcatCometServlet - BEGIN event for request
[EMAIL PROTECTED]
2007-06-26 14:37:08,427 DEBUG [http-8080-exec-4]
com.sebster.myservlet.TomcatCometServlet - 127.0.0.1:60578 POST
/mycometservlet
2007-06-26 14:37:08,432 DEBUG [http-8080-exec-4]
com.sebster.myservlet.TomcatCometServlet -
[24224039-a37e-40d0-a076-89d1df363390] read loop in BEGIN
event, input
stream data available: 1
2007-06-26 14:37:08,438 DEBUG [http-8080-exec-4]
com.sebster.myservlet.TomcatCometServlet -
[24224039-a37e-40d0-a076-89d1df363390] read loop done, input stream
data available: 0
2007-06-26 2:37:08.MD
org.apache.catalina.connector.CoyoteAdapter event
SEVERE: The servlet did not read all available bytes during the
processing of the read event
After this, the poller goes into an infinite event handling
busy loop.
I looked at what the poller was doing, and it seems to be
setting the
comet event into the END event type and trying to call the event
method, however, it never arrives at my Comet processor's
event method
(it seems to call an event method on an error valve or though). I
don't know what exactly happens, but I can debug more if necessary.
Does anybody know what the proper way to read ALL the data
is, and not
cause this exception to happen?
Regards,
Sebastiaan
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe,
RE: Comet example Tomcat 6 not working.
There have been a lot of things fixed and enhanced in the Comet area
since version 6.0.10.
You should better try with version 6.0.13.
Regards,
Matthias
-Original Message-
From: Ritesh Kumar [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 11:43 AM
To: users@tomcat.apache.org
Subject: Comet example Tomcat 6 not working.
Hi,
I am trying to run the comet sample given along with tomcat.
The sample is
not working correctly most of the time. I am using NIO
connectors and Tomcat
version is 6.0.10.
I have some doubts also:
1) In the ChatServer example, a thread (using a Runnable
MessageSender) is
sending responses the clients. Is it possible to write
multiple times to the
same response. Because when we do writer.flush() then that
response is sent
to the client.
2) The READ event is never invoked in my example. whenever I
send a request
only BEGIN event is getting called. I thought, for the first
time only BEGIN
event should get called, and for further requests by the same
client, READ
event should get called.
3) I am getting exception at the line where the thread which
is trying to
write to response stream is calling the flush method.
The code (from tomcat example) is:
for (int i = 0; i connections.size(); i++) {
try {
PrintWriter writer =
connections.get(i).getWriter();
String toBeFlushed = ;
for (int j = 0; j
pendingMessages.length; j++)
{
// FIXME: Add HTML filtering
writer.println(pendingMessages[j] +
br/);
}
writer.println(Random message 1
+ br/);
writer.println(Random message 2
+ br/);
System.out.println(writer will flush now.
writer is null?= + writer == null);
writer.flush();
} catch (IOException e) {
log(IOExeption sending message, e);
}
}
And the error message I am getting is:
Exception in thread MessageSender[/CometTestApp]
java.lang.NullPointerException
at
org.apache.coyote.http11.InternalNioOutputBuffer.addToBB(Inter
nalNioOutputBuffer.java:607)
at
org.apache.coyote.http11.InternalNioOutputBuffer.commit(Intern
alNioOutputBuffer.java:600)
at
org.apache.coyote.http11.Http11NioProcessor.action(Http11NioPr
ocessor.java:1010)
at org.apache.coyote.Response.action(Response.java:183)
at org.apache.coyote.Response.sendHeaders(Response.java:379)
at
org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffe
r.java:305)
at
org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.
java:288)
at
org.apache.catalina.connector.CoyoteWriter.flush(CoyoteWriter.java:95)
at
com.headstrong.test.ChatServlet$MessageSender.run(ChatServlet.
java:276)
at java.lang.Thread.run(Thread.java:595)
--
View this message in context:
http://www.nabble.com/Comet-example-Tomcat-6-not-working.-tf39
57585.html#a11229741
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Comet: Unsufficiently synchronized recycling decisions
Filip, thank you for the response. The issue is fairly simple: At some point in time (t1) the CoyoteAdapter.service (or the CoyoteAdapter.event) method calls request.isComet(). If the CometEvent has not been closed at (t1), this method returns true and request and response are not recycled. At a later point in time (t2), after returning from the call to the CoyoteAdapter, the Http11AprProcessor.process (or Http11AprProcessor.event) method checks the comet flag. If the flag is false at (t2), the processor will be recycled. In almost all cases the comet flag is still true at (t2) if request.isComet() had returned true at (t1). However, especially in heavy load situations, another thread may be scheduled between (t1) and (t2) and call event.close() . In such a situation, the comet falg will be false at (t2) and the processor is recycled while request and response are not recycled. The processor will then process the next request with non-recycled request/response objects. My quick and dirty fix calls the recycle methods of request and response whenever the recycle method of the processor is called, regardless if request and response had been recycled before or not. It is not that easy to provide a simple example app that produces such a behaviour reliably. I can see that it happens in my application which runs an embedded Tomcat and a whole bunch of additional threads when the system is under load, but it does not happen in a simple test situation. Regards, Matthias -Original Message- From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 13, 2007 8:09 PM To: Tomcat Users List Subject: Re: Comet: Unsufficiently synchronized recycling decisions Reich, Matthias wrote: Hello, I did not get any response on my post from 2 weeks ago. Even if non-recycling of request/response objects happens only sporadically and only in webapps where asynchronous responses may happen before the event processing has finished, it is definitively a bug. Should I report it as a bug to receive any reaction? a bug would help only if it has an example app, or enough info to help us truly understand the issue. personally, I haven't had enough time to look through it to truly understand it, cause I believe the fix would probably be easier than the one described below Filip Regards, Matthias -Original Message- From: Reich, Matthias Sent: Wednesday, May 30, 2007 2:04 PM To: 'Tomcat Users List' Subject: Comet: Unsufficiently synchronized recycling decisions Hi, as mentioned in my contribution to topic 'Web application receives request parameters sent to another application on Tomcat 6', I sometimes get non-recycled Request objects in a BEGIN event. A non-recycled request object appeared in a BEGIN event if the previous request processed by the same request processor was answered asynchronously directly after the BEGIN event. In such a situation my Servlet sometimes did not get an END event, i.e. the CoyoteAdapter was not triggered again and therefore could not recycle the Request object. Nevertheless, the request processor was recycled, i.e. readded to the processor pool. As the processor was recycled, the cometEvent.close() must have happened *after* CoyoteAdapter had made the decision not to recycle Request/Response, but *before* Http11AprProtocol had made the decision to recycle the processor. To verify this, I modified the methods Http11AprProcessor.event and Http11AprProcessor.process. I replaced every occurrence of: recycle(); within these methods with the following lines: org.apache.catalina.connector.Request req = (org.apache.catalina.connector.Request) request.getNote(1); org.apache.catalina.connector.Response res = (org.apache.catalina.connector.Response) response.getNote(1); req.recycle( ); res.recycle( ); recycle(); I know that this is a hack and must be solved in a better way (and also for the NIOConnector), but with these modifications I enforced a single decision point for recycling of Request/Response *and* the processor. When running Tomcat with these modifications, my Servlet no longer received non-recycled Request objects. Regards, Matthias - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL
RE: Comet: Unsufficiently synchronized recycling decisions
Hello, I did not get any response on my post from 2 weeks ago. Even if non-recycling of request/response objects happens only sporadically and only in webapps where asynchronous responses may happen before the event processing has finished, it is definitively a bug. Should I report it as a bug to receive any reaction? Regards, Matthias -Original Message- From: Reich, Matthias Sent: Wednesday, May 30, 2007 2:04 PM To: 'Tomcat Users List' Subject: Comet: Unsufficiently synchronized recycling decisions Hi, as mentioned in my contribution to topic 'Web application receives request parameters sent to another application on Tomcat 6', I sometimes get non-recycled Request objects in a BEGIN event. A non-recycled request object appeared in a BEGIN event if the previous request processed by the same request processor was answered asynchronously directly after the BEGIN event. In such a situation my Servlet sometimes did not get an END event, i.e. the CoyoteAdapter was not triggered again and therefore could not recycle the Request object. Nevertheless, the request processor was recycled, i.e. readded to the processor pool. As the processor was recycled, the cometEvent.close() must have happened *after* CoyoteAdapter had made the decision not to recycle Request/Response, but *before* Http11AprProtocol had made the decision to recycle the processor. To verify this, I modified the methods Http11AprProcessor.event and Http11AprProcessor.process. I replaced every occurrence of: recycle(); within these methods with the following lines: org.apache.catalina.connector.Request req = (org.apache.catalina.connector.Request) request.getNote(1); org.apache.catalina.connector.Response res = (org.apache.catalina.connector.Response) response.getNote(1); req.recycle( ); res.recycle( ); recycle(); I know that this is a hack and must be solved in a better way (and also for the NIOConnector), but with these modifications I enforced a single decision point for recycling of Request/Response *and* the processor. When running Tomcat with these modifications, my Servlet no longer received non-recycled Request objects. Regards, Matthias - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web application receives request parameters sent to another application on Tomcat 6
With some additional logging I found out that my problem is most
probably not related to the mixed request parameters.
It is a problem of synchronizing the decisions of whether to recycle
Request/Response objects and whether to recycle the processor.
I'll send more details in another mail with topic 'Comet: Unsufficiently
synchronized recycling decisions'.
Regards,
Matthias
-Original Message-
From: Reich, Matthias
Sent: Tuesday, May 29, 2007 10:54 AM
To: 'Tomcat Users List'
Subject: RE: Web application receives request parameters sent
to another application on Tomcat 6
Hi,
I am experiencing a behavior that may be related to the
mentioned problem.
My Servlet uses the Comet interfaces of Tomcat 6.
For debugging purposes, when my Servlet receives a BEGIN
event, it stores a request counter in an atttribute of the
HttpServletRequest object.
(This is done to see in the logs to which request a
subsequent READ, END or ERROR event is related.)
Before setting the attribute, the servlet checks whether the
attribute is already set:
if (event.getEventType() == CometEvent.EventType.BEGIN)
{
HttpServletRequest request = event.getHttpServletRequest( );
Long index = (Long) request.getAttribute(INDEX_ATTRIBUTE);
if (index == null)
{
index = nextRequestIndex();
request.setAttribute(INDEX_ATTRIBUTE, index);
requestCount++;
}
else
{
myLogger.warn(Found old request attribute (
+ index + ) in BEGIN event!);
}
...
When running tests where several requests are processed at
the same time, I occasionally see the log message appear.
It looks as if sometimes recycling of a request object is not
yet completed when the object is already reused for a new request.
I cannot tell if a similar behavior occurs in my tests also
for request parameters because my tests don't pay much
attention on the parameters.
The 'old attributes' problem occurs as well with the APR
connector as with the NIO connector, and I guess that also
the 'wrong request parameters' problem only occurs with these
two connectors, as they are prepared to handle Comet requests
and therefore have a modified request processing (compared to
the Http11Processor) also for 'regular' servlet requests.
What connector are you using with Tomcat 6?
If it is the APR connector (i.e. if you have the tcnative-1
library in your library path), you could try if the problem
disappears when you switch to the Http11Protocol.
Matthias
-Original Message-
From: Dejan Krsmanovic [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 8:13 AM
To: Tomcat Users List
Subject: Re: Web application receives request parameters sent
to another application on Tomcat 6
I am aware of that. We are printing request parameters inside
Servlet's
doPost method.
Dejan
Len Popp wrote:
It is possible that Tomcat resuses request objects. I'm
not sure it
does, but it might. For that reason, you're only allowed
to use the
request object in your servlet's doGet or doPost method, you can't
stash it somewhere (e.g. in the HttpSession) and access it later.
(This is mentioned in the servlet spec.) Of course I don't know if
that's your problem, it's just something that came to mind.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Comet: Unsufficiently synchronized recycling decisions
Hi, as mentioned in my contribution to topic 'Web application receives request parameters sent to another application on Tomcat 6', I sometimes get non-recycled Request objects in a BEGIN event. A non-recycled request object appeared in a BEGIN event if the previous request processed by the same request processor was answered asynchronously directly after the BEGIN event. In such a situation my Servlet sometimes did not get an END event, i.e. the CoyoteAdapter was not triggered again and therefore could not recycle the Request object. Nevertheless, the request processor was recycled, i.e. readded to the processor pool. As the processor was recycled, the cometEvent.close() must have happened *after* CoyoteAdapter had made the decision not to recycle Request/Response, but *before* Http11AprProtocol had made the decision to recycle the processor. To verify this, I modified the methods Http11AprProcessor.event and Http11AprProcessor.process. I replaced every occurrence of: recycle(); within these methods with the following lines: org.apache.catalina.connector.Request req = (org.apache.catalina.connector.Request) request.getNote(1); org.apache.catalina.connector.Response res = (org.apache.catalina.connector.Response) response.getNote(1); req.recycle( ); res.recycle( ); recycle(); I know that this is a hack and must be solved in a better way (and also for the NIOConnector), but with these modifications I enforced a single decision point for recycling of Request/Response *and* the processor. When running Tomcat with these modifications, my Servlet no longer received non-recycled Request objects. Regards, Matthias - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web application receives request parameters sent to another application on Tomcat 6
Hi,
I am experiencing a behavior that may be related to the mentioned
problem.
My Servlet uses the Comet interfaces of Tomcat 6.
For debugging purposes, when my Servlet receives a BEGIN event, it
stores a request counter in an atttribute of the HttpServletRequest
object.
(This is done to see in the logs to which request a subsequent READ, END
or ERROR event is related.)
Before setting the attribute, the servlet checks whether the attribute
is already set:
if (event.getEventType() == CometEvent.EventType.BEGIN)
{
HttpServletRequest request = event.getHttpServletRequest( );
Long index = (Long) request.getAttribute(INDEX_ATTRIBUTE);
if (index == null)
{
index = nextRequestIndex();
request.setAttribute(INDEX_ATTRIBUTE, index);
requestCount++;
}
else
{
myLogger.warn(Found old request attribute (
+ index + ) in BEGIN event!);
}
...
When running tests where several requests are processed at the same
time, I occasionally see the log message appear.
It looks as if sometimes recycling of a request object is not yet
completed when the object is already reused for a new request.
I cannot tell if a similar behavior occurs in my tests also for request
parameters because my tests don't pay much attention on the parameters.
The 'old attributes' problem occurs as well with the APR connector as
with the NIO connector, and I guess that also the 'wrong request
parameters' problem only occurs with these two connectors, as they are
prepared to handle Comet requests and therefore have a modified request
processing (compared to the Http11Processor) also for 'regular' servlet
requests.
What connector are you using with Tomcat 6?
If it is the APR connector (i.e. if you have the tcnative-1 library in
your library path), you could try if the problem disappears when you
switch to the Http11Protocol.
Matthias
-Original Message-
From: Dejan Krsmanovic [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 8:13 AM
To: Tomcat Users List
Subject: Re: Web application receives request parameters sent
to another application on Tomcat 6
I am aware of that. We are printing request parameters inside
Servlet's
doPost method.
Dejan
Len Popp wrote:
It is possible that Tomcat resuses request objects. I'm not sure it
does, but it might. For that reason, you're only allowed to use the
request object in your servlet's doGet or doPost method, you can't
stash it somewhere (e.g. in the HttpSession) and access it later.
(This is mentioned in the servlet spec.) Of course I don't know if
that's your problem, it's just something that came to mind.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: comet read event
Hi,
I think you have to add
cometEvent.getHttpServletResponse().getWriter().flush();
also in the READ event case.
Matthias
-Original Message-
From: Peter Warren [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 22, 2007 10:11 PM
To: users@tomcat.apache.org
Subject: comet read event
My BEGIN block in my comet servlet now looks like the code
below (added
a while loop to read until the buffer is empty). Is that what you had
in mind? The buffer in the BEGIN event only contains the
client's first
message. Am I not emptying the buffer correctly? Although,
I wouldn't
expect the buffer to contain the client's second message since the
client blocks for an ack from the server before sending its second
message. Any other thoughts on what happens to the client's second
message and why no READ event is generated?
Thanks for your help,
Peter
if (cometEvent.getEventType() == CometEvent.EventType.BEGIN) {
log(Begin for session: +
request.getSession(true).getId());
BufferedReader reader =
cometEvent.getHttpServletRequest().getReader();
String line = null;
while ((line = reader.readLine()) != null) {
log(servlet received: + line);
cometEvent.getHttpServletResponse().getWriter().println(servlet
received: + line);
cometEvent.getHttpServletResponse().getWriter().flush();
}
}
Filip Hanik wrote:
it could be because the data from the request already came
in with the
request.
when the BEGIN happens, perform the actions as if there was
a READ as
well, ie, empty out the buffer.
Filip
Peter Warren wrote:
The following client code generates a comet BEGIN event on
the server
but not a subsequent READ event, as I was expecting. How
come? Is my
code wrong? Are my expectations wrong? See sequence of events
commented in code below.
// client test method that sends messages to server and
listens for
responses
public void test() throws IOException {
out.println(test 1);
out.flush();
// server receives client's message, generates a
BEGIN event,
and sends response to client
in = new BufferedReader(new
InputStreamReader(urlConn.getInputStream()));
System.out.println(in.readLine());
// client receives server's response and prints it
out.println(test 2);
out.flush();
System.out.println(in.readLine());
// client code blocks here waiting for server response.
// server never generates a READ event. How come?
// Does the HttpURLConnection (see full code below)
need to be
set up differently?
// Am I using the PrintWriter incorrectly when
sending to the
comet servlet?
out.close();
urlConn.disconnect();
}
Thanks for any help,
Peter
-- system --
using:
tomcat 6.0.13 on windows xp sp 2
java 1.6.0_01
-- test client comet servlet source below --
## begin test client ##
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.HttpURLConnection;
import java.net.URL;
public class CometTestClient {
private HttpURLConnection urlConn;
private PrintWriter out;
private BufferedReader in;
public static void main(String[] args) throws Exception {
CometTestClient test = new CometTestClient();
test.test();
}
public CometTestClient() throws IOException {
initConnection();
}
private void initConnection() throws IOException {
URL url = new URL(http://127.0.0.1/CometTest;);
urlConn = (HttpURLConnection) url.openConnection();
urlConn.setDoInput(true);
urlConn.setDoOutput(true);
urlConn.connect();
out = new PrintWriter(urlConn.getOutputStream());
}
public void test() throws IOException {
out.println(test 1);
out.flush();
in = new BufferedReader(new
InputStreamReader(urlConn.getInputStream()));
System.out.println(in.readLine());
out.println(test 2);
out.flush();
System.out.println(in.readLine());
out.close();
urlConn.disconnect();
}
}
## end test client ##
## begin comet servlet ##
import java.io.BufferedReader;
import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import org.apache.catalina.CometEvent;
import org.apache.catalina.CometProcessor;
public class CometTestServlet extends HttpServlet implements
CometProcessor {
private static final long serialVersionUID =
5472498184127924791L;
public void event(CometEvent
RE: WebApps not isolated
ResourceBundle.getBundle uses the ClassLoader that was used to load the class that's calling this method when it looks up the resource. Have you checked that the class which contains the call to ResourceBundle.getBundle is loaded by the expected WebappClassLoaders? Matthias -Original Message- From: Robert Soeding [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 23, 2007 2:37 PM To: users@tomcat.apache.org Subject: WebApps not isolated Hi, since this is my first posting in this mailing list, I would like to thank you very much for providing and maintaining Tomcat. I'm using Tomcat 5.5.20 and .23, Sun Java 1.5.x, on Ubuntu 7.04. I've deployed two identical WebApps, webapp1 and webapp2, by letting Tomcat unpack two WAR files. Next I changed $CATALINA_HOME/webapps/webappX/WEB-INF/classes/myProps.properties in both webapps to point to different databases. Next, I restarted Tomcat. The code to access properties is simply, ResourceBundle.getBundle(myProps).getString(key); The problem is, both webapp1 and webapp2 access the same myProps.properties (webapp2 access webapp1's myProps.properties). When I undeploy webapp1, webapp2 will use its own properties file again. As an additional test, I downloaded a fresh copy of Tomcat, deployed both webapps, edited myProps.properties, and ran this fresh instance. In this instance, webapp1 would use the properties file of webapp2 (while in the other instance of Tomcat, webapp2 would access webapp1's properties file). Anyways, both webapps are not isolated properly. On another server I was not able to reproduce this behavior, using the same WAR files. I've also looked for JARs that might contain the properties file in the $CLASSPATH, $CATALINA_HOME/common/* and $CATALINA_HOME/webapps/webapp1/WEB-INF/lib, but such a JAR does not exist. Moreover, different properties files are used, probably, depending on which webapp is loaded first. Any ideas? Thanks Robert - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Missing ETag in 304 Header
Hi, the spec says that a 304 response MUST include header - ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request Does Tomcat send an ETag header in a 200 response when it serves static content? If not (and I assume that it doesn't), I read the spec in a sense that it is o.k. for the 304 response not to include an ETag. For static content, last modified information usually is sufficient to decide whether a cache entry is still valid, so what additional should an ETag header deliver in that case? Regards, Matthias -Original Message- From: Rashmi Rubdi [mailto:[EMAIL PROTECTED] Sent: Friday, May 18, 2007 3:10 AM To: Tomcat Users List Subject: Re: Missing ETag in 304 Header On 5/16/07, Joe Mun [EMAIL PROTECTED] wrote: Hi guys... so according to the HTTP 1.1 spec ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html), 304 Not Modified responses must include the ETag in the header. However, Tomcat doesn't seem to be adding it... I am serving a static text file, and the header only returns: HTTP/1.x 304 Not Modified Server: Apache-Coyote/1.1 Date: Wed, etc... I examined the header returned by Tomcat 6.0.10 with Firefox's TamperData extension and also by uncommenting Tomcat's RequestDumperValve. You are right that the ETag header doesn't appear. However, I saw another cache related header if-none-match , which also shows a checksum in the same format as ETag , perhaps you may find that header useful. May 17, 2007 9:01:46 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: header=if-none-match=W/6958-1163795820656 I don't really know what causes the ETag to appear, I would expect it to appear by default without any configuration similar to many other HTTP Caching Headers. I did notice the ETag for static files on one website that is hosted on Apache httpd + Tomcat. Is there a reason that the Etag is not being included? Is there a way to configure Tomcat to include this? My company is working with a caching solution provider, and they are complaining about the missing ETag. thanks. Regards Rashmi - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: url-pattern troubles...
The annoying thing about it is, that you cannot use a pattern that says ignore /protected/include. Thus, you must specify patterns for all subdirectories that shall be protected separately. Matthias -Original Message- From: Hassan Schroeder [mailto:[EMAIL PROTECTED] Sent: Friday, May 11, 2007 2:45 AM To: Tomcat Users List Subject: Re: url-pattern troubles... On 5/10/07, webzo [EMAIL PROTECTED] wrote: Ok, this should have been simple. But Tomcat doesn't seem to be doing what I thought it would- I have a bunch of jsp files under a directory called protected. I want a filter to be invoked when these files are accessed. I also have a directory called includes under protected. I DON'T want the filter to be invoked when files under includes are accessed. I cannot change this directory structure. I used the pattern /protected/*.jsp for the filter in question BZZZT. See the Servlet Spec -- SRV.11.2 Your pattern is invalid (and so is /*.jsp -- if that actually worked, it's a bug.) The url-pattern isn't a wide-open regexp, so I think you'll have to change your Filter to ignore the includes subdirectory, unless you can differentiate based on the request type (client request, forward, include -- see SRV.6.2.5). HTH, -- Hassan Schroeder [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: NioEndpoint closes connection upon timeout
-Original Message- From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 08, 2007 11:00 AM However, the Javadoc of enum EventSubType says: TIMEOUT - the connection timed out (sub type of ERROR); note that this ERROR type is not fatal, and the connection will not be closed unless the servlet uses the close method of the event. hmm, not sure I agree with the docs. let me check on that. in the meantime, why don't you set a much higher timeout value for the NIO connector you can do this on a per-connection basis. just do event.setTimeout during the BEGIN event. Filip My servlet does not close the event in case of a TIMEOUT, you're servlet SHOULD ALWAYS call event.close upon any type of error. Well, there is still no common understanding about what a TIMEOUT really means within the code base and the documentation. E.g. the Javadoc for CometEvent says: ERROR - Error will be called by the container in the case where an IO exception or a similar unrecoverable error occurs on the connection. Fields that have been initialized in the begin method should be reset. After this event has been processed, the request and response objects, as well as all their dependent objects will be recycled and used to process other requests. However, the CoyoteAdapter does *not* treat a timeout as an error and does *not* recycle any objects, and this behavior works fine with Apr connector - i.e. the Servlet can decide if this is an error situation and close the event if appropriate. No matter what the final meaning of a timeout will be - the behavior should be the same for both connectors, i.e. either both connectors should close the connection upon a timeout, or both should keep it open. Matthias - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Comet: problem with request.getParameter() in Comet POST requests
-Original Message- From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] Wouldn't every application which isn't as dumb as the chat example (which does not care about the content it reads but simply passes it back to it's clients) need to implement it's own mechanism to check whether there is enough input available to start parsing a chunk of data? huh? This exact same problem exist with regular servlets, and has existed for the last 8 years. Filip I have written some servlet code during the last years, but I never had to deal with the question if the servlet can start parsing - it simply does, and the underlying read operations on the stream block if necessary to wait until more data is available to proceed. (Or the servlet simply accesses request parameters of a POST request and expects that they are available.) The question whether I have to wait for another READ event before I have the complete request available (or a complete message from a series of messages transferred within the scope of one http request) only arises if I am told that I should not do a blocking read. So far I did not read a clear statement which says: With Comet is is not desirable to do blocking read, but the API allows to do it, as well in the BEGIN event handling as in the READ event handling. If this statement is true, I don't have any problem. The Servlet can read all it expects to be delivered by the client when the client starts a request (and don't care if it fits into one TCP packet or not, because the read will block until the remaining TCP packets have arrived.) Afterwards, there won't be anything more to be read until the client sends the next message. Thus, if the servlet gets a READ event, it can assume that the client has sent a new message and read it. (Again, the read will block if some TCP packets are missing which contain remaining parts of the message.) However, if the statement is not true, the Servlet has to care about what is going on on the transport (TCP) level, and it has to count bytes to know when a message is completely available. So can you tell me: Is the above statement true? Matthias - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Comet: problem with request.getParameter() in Comet POST requests
-Original Message- From: Rémy Maucherat [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 02, 2007 11:13 PM On 5/2/07, Sebastiaan van Erk [EMAIL PROTECTED] wrote: It's a race condition and the problem occurs quite infrequently (especially with small request bodies). The larger the request body of the POST request, the more likely it is that the problem occurs. I was testing at a few thousand request per second, and even then it rarely showed up. The fact that other people out there are using getParameter() on Comet POST requests and expect it to work seems to me to warrant 1) acknowledgement that it is a bug, 2) a warning in the documentation, or 3) a request facade for the Comet API which throws an exception when the getParameter() method is called on a POST request. Whatever ;) Rémy I am working on a scenario with browsers as clients. The client does requests with JavaScript code like this: req = new XMLHttpRequest(); req.onreadystatechange = handler; req.open(post, /somecontext/somecometservlet/somerequest?param1=val1param2=val2 ); req.send(null); We intentionally use POST requests to avoid problems that occurred with some caches at customer sites and with web crawlers that monitor the GET requests of a browser and send the identical requests themselves to analyze the responses. Thus, only with POST we can achieve an exactly once submission of the request. However, by passing the request parameters in the URL (i.e. in the header and not in the body) I don't have any problems with reading the request parameters. You can imagine, that I would not be happy if the API would only offer me a request facade that throws an exception when the servlet tries to access the parameters of a POST request. Matthias - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Comet: problem with request.getParameter() in Comet POST requests
-Original Message- From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] Sent: Friday, April 27, 2007 7:24 PM To: Tomcat Users List Subject: Re: Comet: problem with request.getParameter() in Comet POST requests GET parameters, ie parameters in the URL will work. However, using Comet you shouldn't rely on parameters in the body, the body if for you usage, and your usage alone. Seems to me that this is a pretty common use case though with AJAX server side push: request, wait, response. Comet is used to free the http thread while waiting, otherwise the server would be out of http threads in no time. The data posted is often in POST form (a scripted form post). You can still invoke getReader or getInputStream without actually reading from it, if that causes the parse to happen. Yes, that is my current workaround, I use READ events and the Content-Length header to parse the parameters myself. Wouldn't every application which isn't as dumb as the chat example (which does not care about the content it reads but simply passes it back to it's clients) need to implement it's own mechanism to check whether there is enough input available to start parsing a chunk of data? According to my current understanding of Comet a READ event will be triggered after some tcp packet was received from the client. Thus, even if a client has sent a complete chunk of data (e.g. a SOAP request), the server side cannot be sure that it is completely available for parsing when a READ event is triggered. Thus, each application must implement it's own http like protocol to wrap each chunk of data transferred to the server: - The client must send the number of bytes of the following chunk before the actual chunk is sent. To be able to do this, it must care about content encoding (e.g. write character based data to a ByteArrayOutputStream first, determine it's length, send the number of bytes, and then the content of the byte array) - The servlet must read the length, allocate a byte buffer and start reading into the buffer. - Only if it has received a READ event that delivers the last expected byte of the chunk, the content of the byte buffer can be converted into a String (or another character based sequence) according to the character encoding specified by the client, and finally parsed. Is it really the intention of Comet that each application must care about these things? Is there no way to enable a Servlet to do a blocking read if it recognizes that a client has sent a chunk of data? It would not block for a long time in that situation (only until the missing tcp packets of the actual chunk have arrived). This would allow a much more convenient handling of input for most applications. Matthias - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Comet: problem with request.getParameter() in Comet POST requests
Wouldn't every application which isn't as dumb as the chat example (which does not care about the content it reads but simply passes it back to it's clients) need to implement it's own mechanism to check whether there is enough input available to start parsing a chunk of data? Either that, or you can parse the information on demand, as it comes in. The problem is: I only know that SOME input is available, but I don't know if the parser will succeed without a blocking read. With other words: I cannot know whether the last closing bracket of my SOAP request is already available in the input unless I know the number of bytes of the complete chunk in advance. If I want to parse it 'on availability' (I think 'on demand' is not the right term here) I would need a parser that suspends on reaching the end of available data (returning something like a 'not finished' indication) and can be resumed with the next read event. Otherwise I would have to try a new parse attempt (starting with byte 0 again) with each read event, until I finally succeed. Furthermore, I usually parse a sequence of characters, not bytes, and I think it does not make sense to start decoding the bytes in the input if there are still bytes of the message missing. Thus, my conclusion is that 'parsing on availability' is not a solution except for some rare situations. What you seem to want is more in line with the asynchronous servlet Well, for the scenario I am working on, you are right. But the problem of knowing whether a complete chunk of input is available for processing without a blocking read is also present if a Servlet reads one SOAP request after the other within the scope of the same http request. As for blocking reads in your servlet, I don't think there is anything which prevents you from doing multiple blocking reads from the request input stream in a READ event. The description of the READ event is as follows: EventType.READ: This indicates that input data is available, and that one read can be made without blocking. It does not say you are not allowed to do additional reads (with the risk of blocking). Note that I have not tried this yet, and it might not work. It would be useful to have a thorough description of the API which documents these things (as well as other issues such as synchronization, lifetime/scope of the event object, etc), with a clear seperation between API (things one can depend on), and implementation details (things which happen to work some way due to the current implementation but are subject to change without notice). I totally agree! Matthias - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: WAR File loaded into embedded Tomcat not reachable
Hi, you did not tell us about how you load the war file. If the extension is correct (mynewwar.ZIP) I think it won't be loaded automatically. If it is named mynewwar.war and e.g. available in directory C:\mywebapps this should work: Context ctxt = embedded.createContext(/mynewwar , C:\mywebapps\mynewwar.war); ... host.addChild(ctxt); If this doesn't not work for you, you may have to do something like Loader loader = embedded.createLoader( classLoaderKnowingMynewwar ); ctxt.setLoader( loader ); before adding the context. Matthias -Original Message- From: Max Länzlinger [mailto:[EMAIL PROTECTED] Sent: Friday, April 27, 2007 8:16 PM To: users@tomcat.apache.org Subject: WAR File loaded into embedded Tomcat not reachable Hello, I want load a war-file programmaticly into the embedded tomcat-server. I made a Project (MyProject.ZIP) which starts the Server. Also a small web-application as war-file (mynewwar.zip). The server starts fine, and does so far not complain when loading the web-applikation war File into the standard context. The Problem ist afterwards, i cannot call the web-applikation. I Use embedded Tomcat 5.0.30. Sure the problem is little, any wrang/mising call to a method, and i would be very happy for help; if it runs i have a chance to embed Tomcat in our Sybase Database which supports Java, and we coud migrate all our xslt Applikations vom inside Sybase to the nice Tomcat resp. write nice JSF instead. THANKS A LOT FOR HELP Greetings MAx -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leak with Comet
Hello again,
I would like to give you another chance to see the situation where the
processing objects are not recycled.
After all my observations, I had the feeling that the reason for the
non-recycled processing objects must be problems with concurrent access
to queues or maps that hold these objects, and that it should not be TOO
hard to find it - and I found it.
I modified the lines that are marked in the following code fragments
from class Http11AprProtocol to verify it:
public SocketState event(long socket, SocketStatus status) {
Http11AprProcessor result = connections.get(socket);
SocketState state = SocketState.CLOSED;
if (result != null) {
// Call the appropriate event
try {
state = result.event(status);
} finally {
if (state != SocketState.LONG) {
Http11AprProcessor removed =
connections.remove(socket);
if (removed != result) {
Http11AprProtocol.log.error (removed wrong
processor from connections) ;
}
recycledProcessors.offer(result);
}
}
}
return state;
}
public SocketState process(long socket) {
Http11AprProcessor processor = recycledProcessors.poll();
try {
if (processor == null) {
processor = createProcessor();
}
if (processor instanceof ActionHook) {
((ActionHook)
processor).action(ActionCode.ACTION_START, null);
}
SocketState state = processor.process(socket);
if (state == SocketState.LONG) {
// Associate the connection with the processor. The
next request
// processed by this thread will use either a new or
a recycled
// processor.
Http11AprProcessor replaced =
connections.put(socket, processor);
if (replaced != null) {
Http11AprProtocol.log.error (there was still
another processor assigned to the socket - it is not recycled!);
}
proto.endpoint.getCometPoller().add(socket);
} else {
recycledProcessors.offer(processor);
}
...
Now I ran my test application again, keeping the connection alive
between subsequent requests of the browser.
This is what I found in the log file:
WARNUNG: BEGIN(4) POST /comettest/comet/request?action=pollcount=4
28.04.2007 00:20:35 comettest.CometServlet$EventProvider run
WARNUNG: queue size: 1
28.04.2007 00:20:35 comettest.CometServlet$EventProvider sendResponse
WARNUNG: RESPONSE(4)
28.04.2007 00:20:35 comettest.CometServlet$EventProvider run
WARNUNG: queue size: 0
28.04.2007 00:20:35 comettest.CometServlet$EventProvider run
WARNUNG: sleeping 900 millis
28.04.2007 00:20:35 comettest.CometServlet event
WARNUNG: READ(4) POST /comettest/comet/request?action=pollcount=4,
stream closed
28.04.2007 00:20:35 comettest.CometServlet closeEvent
WARNUNG: CLOSE(4) by event processor
28.04.2007 00:20:35 comettest.CometServlet event
WARNUNG: BEGIN(5) POST /comettest/comet/request?action=pollcount=5
28.04.2007 00:20:35
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler
process
SCHWERWIEGEND: there was still another processor assigned to the socket
- it is not recycled!
28.04.2007 00:20:35
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler event
SCHWERWIEGEND: removed wrong processor from connections
This situation does not occur with each request - it seems to depends on
the actual thread scheduling.
The problem is that the socket is added to the poller already within the
Http11AprProcessor.event method.
Due to this the process method can be invoked before the event method
has done it's cleanup.
This time I am a little caucious with advice how to fix the problem, but
I hope I can convince you now that the problem exists ;-)
Matthias
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leak with Comet
Excuse me that I left you alone during the discussion yesterday! Let me clarify: The scenario is that the client polls for events. Thus, it sends a subsequent poll request once it got an answer from the server. (And how should I bring Tomcat to create hundreds of request objects with four browsers, if each of them issues only a single request?) In the log file I can see a very regular pattern (where request parameter count=80 is the client side request count and (80) s the server side request count) 25.04.2007 19:41:53 comettest.CometServlet event WARNUNG: BEGIN(80) POST /comettest/comet/request?action=pollcount=80 25.04.2007 19:41:53 comettest.CometServlet$EventProvider run WARNUNG: queue size: 1 25.04.2007 19:41:53 comettest.CometServlet$EventProvider sendResponse WARNUNG: RESPONSE(80) 25.04.2007 19:41:53 comettest.CometServlet closeEvent WARNUNG: CLOSE(80) by response provider 25.04.2007 19:41:53 comettest.CometServlet$EventProvider run WARNUNG: queue size: 0 25.04.2007 19:41:53 comettest.CometServlet$EventProvider run WARNUNG: sleeping 750 millis 25.04.2007 19:41:54 comettest.CometServlet event WARNUNG: END(80) POST /comettest/comet/request?action=pollcount=80 25.04.2007 19:41:54 comettest.CometServlet closeEvent WARNUNG: CLOSE(80) by event processor 25.04.2007 19:41:54 comettest.CometServlet event WARNUNG: BEGIN(81) POST /comettest/comet/request?action=pollcount=81 Now I look at this statement from a former post again: Processors are only recycled when the IO layer gets an event (read, disconnect, timeout), and if: - the event is a non timeout error - the event is closed by the servlet - the event has been closed asynchronously I must admit that there is no read, disconnect, or timeout event - but there is an END event, and as the CoyoteAdapter sets the type to END instead READ because the event was closed before, I think the mentioned precondition for recycling is fulfilled. The servlet was able to process 467 requests before the OutOfMemoryError occurred, but in the memory dump I can see only 103 processor instances, thus the majority of the Processors was in fact recycled. The mismatch might result from the fact the browser sometimes closed the connection in between, and sometimes did not - see below. If I replace the event.close() in the response provider thread with an outputStream.close(), I also get an END event, regardless if I set Connection: close or not, and also with the NIOConnector. But there is a difference: If the response provider thread sets the Connection: close header before closing the stream, memory consumption is fairly stable for a long time (I let it run for over an hour and saw no significant increase in the Windows task manager), so let us assume that recycling works fine in that situation. MY CONCLUSION: I have to closely couple the connection lifecycle with the request lifecycle to make things work. However, this is bad news for me - I would like to keep connections open as long as possible, because especially with an SSL connector opening a new connection after each poll request is expensive. (And what about malicious clients that ignore the Connection: close ?) If I try to keep the connection open (i.e. the content length in the response header and flush the OutputStream, but don't close it), the client sends the subsequent request on the same connection. The RequestProcessor for the old Request (yes, Request and not Connection - that's why it is called RequestProcessor and not ConnectionProcessor) issues a READ event in this case. The Servlet tries to read and gets -1. This means that it does not actually read from the connection - otherwise it would read the unparsed subsequent request. (We could say that, upon a READ event, the servlet reads further portions of the request, it does not simple read from the connection). As it got -1, the Servlet calls event.close() which means: I am done with this request (it does not mean: I am done with the connection). Then a new (or a recycled) RequestProcessor is associated with the same connection and processes the BEGIN event for the new request, but it seems as if the old RequestProcessor is not always recycled. I think that recycling could be organized much clearer with a small change in the execution model which would also have the benefit of descibing the lifecycle of asynchronous requests more clearly: - First of all, I would like to rename CometEvent into CometRequest, and let it be part of the contract between container and Servlet that one instance of this class represents a request during the whole request lifecycle. (I.e. the Servlet is allowed to hold references to CometRequest objects for further processing) - Recycling of a CometRequest (and all associated objects including the RequestProcessor) should be shifted completely to the CometRequest.close() method. - The only restriction in that case would be that CometRequest.close then cannot be invoked from within
RE: comet events and connections
Well, anyway the lifecycle should be well-defined, and I doubt that it currently is well-defined. If I try to find a better name for class CometEvent which reflects the lifecycle of it's instances according to the current implementation, the name CometRequest fits much better than the name CometConnection, but it does not fit perfectly yet. Have a look at my posting in thread 'Memory Leak with Comet' for more details. Matthias -Original Message- From: Rémy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, April 26, 2007 1:18 AM To: Tomcat Users List Subject: Re: comet events and connections I think that the comet api represents a socket connection. The event life cycle is bound to the connection life cycle. You get an END (or ERROR etc) when the connection gets closed. But when you are writing something that still looks like a servlet you would expect that the event life cycle is bound to the request / response model. As soon as the response is closed you would expect an END event. It's fine to have expectations, but that's not going to happen. It is fine to compare with a Servlet, but the only thing that cannot be compared (and somehow is the thing you apparently want to compare) is evidently the lifecycle, which is completely different. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leak with Comet
Thanks for the clear statement! As I do see processing objects that are not recycled, I now know that I have to postpone my efforts of using the CometProcessor interface. Maybe I'll retry with Tomcat 6.1 when it is released ;-) If some day you like to take a look at a situation where processing objects are not recycled - feel free to ask me for an updated version of my test webapp which reflects my findings of this week. Regards, Matthias -Original Message- From: Rémy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, April 26, 2007 1:04 PM To: Tomcat Users List Subject: Re: Memory Leak with Comet On 4/26/07, Reich, Matthias [EMAIL PROTECTED] wrote: The clear semantics of this approach would be: Processing is the same as for synchronous requests , except that the RequestProcessor thread is released from processing early, and another thread (or several threads that synchronize when accessing the request) continues processing at any time it wants, and the application fully controls the lifetime of CometRequest instances. Thanks for the theories and the suggestions. However, it is not going to be possible to make the API changes you suggested (since I don't like them), and I also don't see a situation where the processing objects are not recycled. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat - CometProcessor question
Hi, I am working on a similar scenario and currently elaborate on the Comet interfaces. 1. With the BEGIN event you get a fully parsed request object, i.e. you don't need to wait for READ events to start processing the request. 2. You can keep a reference to the request and response object so that you will be able to send the Response asynchronously. Thus, I think Comet is the right offering for such a scenario. However, I already learned the lesson, that you need to carefully sychronize access especially to the response object between the thread that runs the servlet's event method and the thread that provides the result. In my tests, I am still struggeling with problems like e.g. memory leaks, so I am not yet in the situation of having a stable running solution. Regards, Matthias Reich -Original Message- From: Praveen Balaji [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 11:51 AM To: users@tomcat.apache.org Subject: Tomcat - CometProcessor question Hi all, Not sure if the subject is appropriate. Here's a description of what I need to achieve: I have a servlet that can block on a request for a long duration. This essentially means the Tomcat processor thread that is serving the HTTP request is blocked and unable to process more incoming requests. From a broader sense, what I need to achieve is to get hold of the client socket I/O streams and let the Tomcat processor thread free. I want to process the request OUTSIDE the lifecycle of the service method. This is so I can achieve better response time with less processor threads. I understand that the Servlet Specification no longer mandates that the request be serviced in the service method. I also understand that Tomcat6 leverages java's NIO support to provide these non-blocking semantics to servlets that implement CometProcessor. However, my observation is that this is particularly useful for AJAX (and similar) client applications that use a keep alive connection to provide responsive UI. My primary requirement is that: 1. I have control of reading the request. I do not want to wait on comet events to read the request payload. 2. I should be able to respond at a later point of time. So I need a handle to the socket output stream. Is the NIO Connector and CometProcessor the right solution for my problem? If yes, how do I achieve the above requirements? If not, does Tomcat provide me any alternatives? Any help will be greatly appreciated and willingly devoured. Thanks, Praveen - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leak with Comet
I tried with Tomcat6 compiled from trunk revision 532271 and two browsers sending the requests. Unfortunately it is not that easy for me to put the dump on a public web server. Instead, I had a look at the dump myself. First I ran Tomcat with a single connector with attribute maxThreads=20, and started it with -Xmx10m. In the dump I saw 103 instances of class org.apache.coyote.http11.Http11AprProcessor and the same number of all the attached objects like Request, Response ... I tried again with -Xmx20m (same configuration otherwise) and saw 249 instances of class org.apache.coyote.http11.Http11AprProcessor. Thus, let us guess that the number of instances increases if I spend more memory. As far as I could see the ConcurrentLinkedQueueHttp11AprProcessor recycledProcessors contains a single entry. But the RequestGroupInfo holds 249 instances of org.apache.coyote.RequestInfo: Instance of java.util.ArrayList (12 bytes) Class: class java.util.ArrayList Instance data members: elementData (L) : Instance of [Ljava.lang.Object;@0x27e379b0 (1204 bytes) modCount (I) : 249 size (I) : 249 Object allocated from: References to this object: [EMAIL PROTECTED] (44 bytes) : field processors -Original Message- From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 24, 2007 11:47 PM To: Tomcat Users List Subject: Re: Memory Leak with Comet Why don't you enable -XX:+HeapDumpOnOutOfMemoryError and send us a link where we can download the HPROF files that get generated. Also send us your config as well when you get the error Filip - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Memory Leak with Comet
So far, I have the feeling that I am the only one who has seen these memory leaks with asynchronous Comet responses. I tried with a number of variations, e.g. - let the browser wait for 500 millis before sending the next poll after receiving a result - keep the events queued in the serverfor at least 500 millis before sending the response - modify synchronization and the places where I invoke event.close() - tried with connector attribute maxKeepAliveRequests=-1 and maxKeepAliveRequests=2 but the effect is always the same. Thus, I doubt that it is really 'wrong' usage of the interfaces, and others should have seen similar effects. Has anyone out there run an application with browsers as clients and with asynchronous responses for a longer time without loosing memory? Or am I the only one so far working on such a scenario? Matthias -Original Message- From: Rémy Maucherat [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 3:11 PM To: Tomcat Users List Subject: Re: Memory Leak with Comet On 4/25/07, Reich, Matthias [EMAIL PROTECTED] wrote: First I ran Tomcat with a single connector with attribute maxThreads=20, and started it with -Xmx10m. In the dump I saw 103 instances of class org.apache.coyote.http11.Http11AprProcessor and the same number of all the attached objects like Request, Response ... This basically means what I said: the connections and their associated processors are never properly closed and recycled for some reason. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Memory Leak with Comet
Hello, I am sorry that I did not address the memory leak issue to the users list first, before sending this bug report: http://issues.apache.org/bugzilla/show_bug.cgi?id=42217 I am aware of the fact that memory allocation occurs in Java progams, and that Tomcat will exploit some resource pools before resources are recycled. I am afraid that I did not consider that I should have been more explicit in my description. If memory allocation of Tomcat continues until I see messages like org.apache.coyote.http11.Http11NioProcessor: Error processing request java.lang.OutOfMemoryError: Java heap space when I run my simple test webapp with JAVA_OPTS=-Xmx512m, this looks for me as if there is a memory leak. Surely, the memory leak could be in my Servlet, and the queue which holds events until they are answered asynchronously is the first candidate to look at in more detail. For this reason, the Servlet logs the size of the queue whenever an element is removed from the queue. I saw that the queue size did not increase over the time, but memory consumption of Tomcat did. Therefore, I am pretty sure that there is either a memory leak in Tomcat or I still don't understand how the Comet interfaces shall be used. If I modify the index page of my webapp in a way that it sends only requests to the 'traditional' servlet, memory does not increase. Also, if it sends requests to the Comet servlet which are answered synchronously, memory consumption is stable. Only if comet requests are answered asynchronously, memory does increase. I did not always wait until I saw the OutOfMemoryError, but the effect is reproducible on my machine. Any opinions about this? Regards, Matthias Reich
RE: Memory Leak with Comet
I did a fresh build this morning from the SVN trunk, and I see the memory leak with both NIO and APR connector. For each browser I run, I have at most 3 active connections at a time. I think, acually there are at most 2 active connections per browser, because by default both IE and FireFox don't open more than 2 connections to a single server. Thus, if I use 4 browser instances for my test, I have at most 12 (or 8) active connections. Matthias -Original Message- From: Rémy Maucherat [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 24, 2007 4:58 PM To: Tomcat Users List Subject: Re: Memory Leak with Comet On 4/24/07, Reich, Matthias [EMAIL PROTECTED] wrote: If memory allocation of Tomcat continues until I see messages like org.apache.coyote.http11.Http11NioProcessor: Error processing request java.lang.OutOfMemoryError: Java heap space There are leaks that have been fixed in the NIO connector, which exist in 6.0.10. Regardless of the amount of waiting events in your queue, each active Comet connection will use resources. There is also at least one relatively recent thread talking about Comet issues. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
