Re: AsyncListener.onError and disconnected client
- Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 24, 2013 2:14:53 PM Subject: Re: AsyncListener.onError and disconnected client On 24/04/2013 18:38, Rossen Stoyanchev wrote: - Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 24, 2013 12:47:54 PM Subject: Re: AsyncListener.onError and disconnected client On 24/04/2013 16:33, Rossen Stoyanchev wrote: Hi, I've seen various discussions here and on the web but I haven't found a conclusive answer. Why does an AsyncListener not receive onError notifications when a client disconnects? Because the Servlet EG says that is the required behaviour. The EG is currently revisiting that decision. See https://java.net/jira/browse/SERVLET_SPEC-44 Thanks for that reference. Is there something in the spec that explicitly makes requires this? Not that I am aware of which why I said EG rather than specification. The JIRA ticket is about adding a disconnect callback but I can imagine in the very least, onComplete can be called. After the connection is over. onComplete should be called once the connection times out. My understanding is that onComplete is always called regardless of how the async request completed, i.e. following onTimeout, or onError. I would expect it to be called after a client disconnect as well for consistency. Also I wonder if a disconnect method is even needed? The onError method could be called indicating that the asynchronous operation has failed to complete (from the Javadoc). That's actually what I expected when I first tried. To my knowledge there is nothing inherent in NIO and TCP that prevents the server from detecting that the client has disconnected. The WebSocket implementation detects disconnected clients immediately and other HTTP servers (e.g. node) seem to be able to do this. What is it about the Servlet async support that prevents it from knowing when a client has disconnected? It would mean having to ditch the BIO connector / or not being able to pass the TCK (assuming the TCK tested this) when using the BIO connector. I guess this goes back to the previous question about whether there is an explicit requirement and therefore test. Why would a TCK test explicitly check that disconnects are not communicated to AsyncListeners? Or is it a more indirect consequence of some other requirement? My point was that if a disconnect event was added to the spec then the BIO connector could never be spec compliant. If I understand correctly, you're saying the BIO connector can not detect a client disconnect. On reflection, it might not be that bad. The event could be fired just not when the client disconnects. It would have to wait until an attempt was made to read from / write to the socket. That's actually not very different from the current situation where I catch any exceptions while trying to write to the response and then call asyncContext.complete(). I suppose it would make it more clear that a client has disconnected (as opposed to some other error), but once writing to the response has raised an error, it doesn't make a big difference what the error is. Rossen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AsyncListener.onError and disconnected client
On 25/04/2013 13:20, Rossen Stoyanchev wrote: - Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 24, 2013 2:14:53 PM Subject: Re: AsyncListener.onError and disconnected client On 24/04/2013 18:38, Rossen Stoyanchev wrote: - Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 24, 2013 12:47:54 PM Subject: Re: AsyncListener.onError and disconnected client On 24/04/2013 16:33, Rossen Stoyanchev wrote: Hi, I've seen various discussions here and on the web but I haven't found a conclusive answer. Why does an AsyncListener not receive onError notifications when a client disconnects? Because the Servlet EG says that is the required behaviour. The EG is currently revisiting that decision. See https://java.net/jira/browse/SERVLET_SPEC-44 Thanks for that reference. Is there something in the spec that explicitly makes requires this? Not that I am aware of which why I said EG rather than specification. The JIRA ticket is about adding a disconnect callback but I can imagine in the very least, onComplete can be called. After the connection is over. onComplete should be called once the connection times out. My understanding is that onComplete is always called regardless of how the async request completed, i.e. following onTimeout, or onError. I would expect it to be called after a client disconnect as well for consistency. Also I wonder if a disconnect method is even needed? The onError method could be called indicating that the asynchronous operation has failed to complete (from the Javadoc). That's actually what I expected when I first tried. It is. The issue is when is happens. The issue is that there is no event (I am aware of) that the container can monitor. BIO - Only know once a read/write fails. NIO - A current read/write will fail. The socket can be explicitly tested (but isn't currently) If the socket is in the poller I'd expect an error event If the socket was added to the poller I'd expect an error event APR - A current read/write will fail. If the socket is in the poller I'd expect an error event If the socket was added to the poller I'd expect an error event It might be possible to test the socket but I haven't checked There are times when a socket is not being used for read/write and is not in a poller (e.g. when the app is doing some processing that doesn't require output to the user agent). You won't get a notification of disconnect in this case until the app has finished. I wonder (for NIO and APR) if you could always have the socket in the poller in order to detect a disconnect? You'd need to carefully keep track of the registered interests for the socket and there are likely to be threading issues as (currently) the Servlet spec is written on the basis that there is only every one thread processing a socket at a time (Tomcat's WebSocket impl violates that assumption - that is the subject of another discussion). To my knowledge there is nothing inherent in NIO and TCP that prevents the server from detecting that the client has disconnected. The WebSocket implementation detects disconnected clients immediately and other HTTP servers (e.g. node) seem to be able to do this. What is it about the Servlet async support that prevents it from knowing when a client has disconnected? It would mean having to ditch the BIO connector / or not being able to pass the TCK (assuming the TCK tested this) when using the BIO connector. I guess this goes back to the previous question about whether there is an explicit requirement and therefore test. Why would a TCK test explicitly check that disconnects are not communicated to AsyncListeners? Or is it a more indirect consequence of some other requirement? My point was that if a disconnect event was added to the spec then the BIO connector could never be spec compliant. If I understand correctly, you're saying the BIO connector can not detect a client disconnect. It can't until you try and read or write from the socket. On reflection, it might not be that bad. The event could be fired just not when the client disconnects. It would have to wait until an attempt was made to read from / write to the socket. That's actually not very different from the current situation where I catch any exceptions while trying to write to the response and then call asyncContext.complete(). I suppose it would make it more clear that a client has disconnected (as opposed to some other error), but once writing to the response has raised an error, it doesn't make a big difference what the error is. This really comes down to how the spec has been written. onError is for errors that happen in the container during dispatch (i.e. at the end of the async phase) that the app does not have visibility
Re: AsyncListener.onError and disconnected client
Mark Thomas wrote: On 25/04/2013 13:20, Rossen Stoyanchev wrote: - Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 24, 2013 2:14:53 PM Subject: Re: AsyncListener.onError and disconnected client On 24/04/2013 18:38, Rossen Stoyanchev wrote: - Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, April 24, 2013 12:47:54 PM Subject: Re: AsyncListener.onError and disconnected client On 24/04/2013 16:33, Rossen Stoyanchev wrote: Hi, I've seen various discussions here and on the web but I haven't found a conclusive answer. Why does an AsyncListener not receive onError notifications when a client disconnects? Because the Servlet EG says that is the required behaviour. The EG is currently revisiting that decision. See https://java.net/jira/browse/SERVLET_SPEC-44 Thanks for that reference. Is there something in the spec that explicitly makes requires this? Not that I am aware of which why I said EG rather than specification. The JIRA ticket is about adding a disconnect callback but I can imagine in the very least, onComplete can be called. After the connection is over. onComplete should be called once the connection times out. My understanding is that onComplete is always called regardless of how the async request completed, i.e. following onTimeout, or onError. I would expect it to be called after a client disconnect as well for consistency. Also I wonder if a disconnect method is even needed? The onError method could be called indicating that the asynchronous operation has failed to complete (from the Javadoc). That's actually what I expected when I first tried. It is. The issue is when is happens. The issue is that there is no event (I am aware of) that the container can monitor. BIO - Only know once a read/write fails. NIO - A current read/write will fail. The socket can be explicitly tested (but isn't currently) If the socket is in the poller I'd expect an error event If the socket was added to the poller I'd expect an error event APR - A current read/write will fail. If the socket is in the poller I'd expect an error event If the socket was added to the poller I'd expect an error event It might be possible to test the socket but I haven't checked There are times when a socket is not being used for read/write and is not in a poller (e.g. when the app is doing some processing that doesn't require output to the user agent). You won't get a notification of disconnect in this case until the app has finished. I wonder (for NIO and APR) if you could always have the socket in the poller in order to detect a disconnect? You'd need to carefully keep track of the registered interests for the socket and there are likely to be threading issues as (currently) the Servlet spec is written on the basis that there is only every one thread processing a socket at a time (Tomcat's WebSocket impl violates that assumption - that is the subject of another discussion). To my knowledge there is nothing inherent in NIO and TCP that prevents the server from detecting that the client has disconnected. The WebSocket implementation detects disconnected clients immediately and other HTTP servers (e.g. node) seem to be able to do this. What is it about the Servlet async support that prevents it from knowing when a client has disconnected? It would mean having to ditch the BIO connector / or not being able to pass the TCK (assuming the TCK tested this) when using the BIO connector. I guess this goes back to the previous question about whether there is an explicit requirement and therefore test. Why would a TCK test explicitly check that disconnects are not communicated to AsyncListeners? Or is it a more indirect consequence of some other requirement? My point was that if a disconnect event was added to the spec then the BIO connector could never be spec compliant. If I understand correctly, you're saying the BIO connector can not detect a client disconnect. It can't until you try and read or write from the socket. On reflection, it might not be that bad. The event could be fired just not when the client disconnects. It would have to wait until an attempt was made to read from / write to the socket. That's actually not very different from the current situation where I catch any exceptions while trying to write to the response and then call asyncContext.complete(). I suppose it would make it more clear that a client has disconnected (as opposed to some other error), but once writing to the response has raised an error, it doesn't make a big difference what the error is. This really comes down to how the spec has been written. onError is for errors that happen in the container during dispatch (i.e. at the end of the async phase) that the app does not have visibility of. It allows the container to tell the app
Re: AsyncListener.onError and disconnected client
On 25/04/2013 14:11, André Warnier wrote: Sorry to butt in, but the issue interests me in another context. My question : is there any kind of I/O operation that a servlet could do to the response stream (even in-between two real data I/O) which would be guaranteed to return an error if the client has closed the connection in the meantime, no matter which Connector implementation underlies it ? It would have to be something which does not really send any real data byte, so as not to corrupt a response that may be partially under way. Some kind of ping, to say it otherwise. With the current Servlet API, no. With direct access to the socket: BIO - no NIO - yes APR - don't know Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AsyncListener.onError and disconnected client
Mark Thomas wrote: On 25/04/2013 14:11, André Warnier wrote: Sorry to butt in, but the issue interests me in another context. My question : is there any kind of I/O operation that a servlet could do to the response stream (even in-between two real data I/O) which would be guaranteed to return an error if the client has closed the connection in the meantime, no matter which Connector implementation underlies it ? It would have to be something which does not really send any real data byte, so as not to corrupt a response that may be partially under way. Some kind of ping, to say it otherwise. With the current Servlet API, no. With direct access to the socket: BIO - no NIO - yes APR - don't know Thanks. Mmm. That's definitely not nice, is it ? It means that there is no real clean way for a Java webapp to do this and be portable. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Configuring IIS to use the JK ISAPI redirector plugin when URL paths are different
On 24.04.2013 09:02, Rainer Jung wrote: On 24.04.2013 06:53, Beavers, Melinda K (Kay) wrote: We have installed the IIS-Tomcat redirector (isapi_redirect.dll) on an IIS 6 server so that http://iis.company.com/website/myfile.jsp will correctly redirect according to our 'isapi_redirect.properties', 'workers.properties', and 'uriworkermap.properties ' and serve the JSP page from http://tomcat.company.com/website/myfile.jsp . That appears to be working just fine. But we actually need to have a different IIS URL. What we are trying to figure out is if we can configure it so that http://iis.company.com/apps/cepv/website/myfile.jsp will redirect and serve the JSP content at http://tomcat.company.com/website/myfile.jsp. The path on the IIS server is has two extra levels (/apps/cepv) in the URL path and does not match the path on the tomcat server where the JSP content is. We have to have those two extra levels in the IIS URL path for other technical reasons and we cannot match or include those two extra levels on the tomcat side. We have tried the following but cannot get it to work. website.worker=website_ajp13 /apps/cepv/website/*.jsp=$(website.worker) Is there anything we can do to map this correctly? Have a look at https://tomcat.apache.org/connectors-doc/generic_howto/proxy.html#URL%20Rewriting starting from If you are using Microsoft IIS as a web server The OP reported via PM that it now works after upgrading from an outdated version to a recent one. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Policy files
Hi Christian, On Wed, Apr 24, 2013 at 11:25 PM, Christian Beikov christian.bei...@gmail.com wrote: I just don't want to have these applications running on my computer not knowing what they actually do. To be honest I couldn't think of any permission I would give a student application. The libraries that can be used are predefined, so I give these jar files the permissions for reflection or whatever they need to work properly. Am I simplifying the whole thing and is what I want much harder to achive than I think? Have you considered running Tomcat in a chroot jail? http://oreilly.com/catalog/tomcat/chapter/ch06.pdf - Security Manager + Chroot combination A more dated link - http://radioae6rt.wordpress.com/2006/04/22/chrooting-tomcat/ Thanks. -Shanti
SSL configuration on Tomcat7.
Hello Everyone, I am Shahid Tamboli and working at Mobimedia Technologies, Pune, India. We are stuck up with configuring our server with SSL. We have taken an Ubuntu instance on Amazon. We have installed Tomcat on the server. The Tomcat version is Tomcat 7 We are facing issues of configuring SSL certificates on my Tomcat server We have followed the following steps of deploying the certificate. http://www.networksolutions.com/support/installation-for-java-based-webservers-e-g-tomcat-using-keytool/http://prolinks.rediffmailpro.com/cgi-bin/prored.cgi?red=http%3A%2F%2Fwww%2Enetworksolutions%2Ecom%2Fsupport%2Finstallation%2Dfor%2Djava%2Dbased%2Dwebservers%2De%2Dg%2Dtomcat%2Dusing%2Dkeytool%2FisImage=0BlockImage=0rediffng=0 On following the above steps we are getting error of certificate not trusted and on contacting the Certificate Provider they told us to check our installation again. Thus if anyone can help us on this issue Thank You -- Cheers Shahid!!!
static cluster
Very frequently i am oberving below static cluster messages are getting logged
in the catalina.out.
+++
INFO: Received member
disappeared:org.apache.catalina.tribes.membership.MemberImpl\
[tcp://10.0.0.222:2333,10.0.0.222,2333, alive=0,id={0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 },\
payload={}, command={}, domain={}, ]
INFO: Replication member added:org.apache.catalina.tribes.membership.MemberImpl\
[tcp://10.0.0.222:2333,10.0.0.222,2333, alive=0,id={0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 },\
payload={}, command={}, domain={}, ]
+++
The question is why other tomcat instances are getting disconnected in between
b y thenselves, what i need to so in oder to resolve this.Please suggest
do i need to increase threads? currently the requests are getting forwarded
from apache to tomcat over ajp port which is configured with 200 threads.
I am using tomcat 6.0.35 Below is my static cluster configuration
+++
Cluster className=org.apache.catalina.ha.tcp.SimpleTcpCluster
channelSendOptions=6 channelStartOptions=3
Manager className=org.apache.catalina.ha.session.DeltaManager
expireSessionsOnShutdown=false
notifyListenersOnReplication=true /
Channel className=org.apache.catalina.tribes.group.GroupChannel
Receiver
className=org.apache.catalina.tribes.transport.nio.NioReceiver
autoBind=0 selectorTimeout=5000 maxThreads=6
address=10.0.0.111 port=2333
/
Sender
className=org.apache.catalina.tribes.transport.ReplicationTransmitter
Transport
className=org.apache.catalina.tribes.transport.nio.PooledParallelSender /
/Sender
Interceptor
className=org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor /
Interceptor
className=org.apache.catalina.tribes.group.interceptors.TcpFailureDetector /
Interceptor
className=org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor
/
Interceptor
className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor
Member
className=org.apache.catalina.tribes.membership.StaticMember securePort=-1
host=10.0.0.222 port=2333
/
+++
RE: SSL configuration on Tomcat7.
You didn't provide very much information. But one thing to check is that the domain name of your site matches what you specified for the certificate. -Original Message- From: Shahid Tamboli [mailto:shahid1...@gmail.com] Sent: Thursday, April 25, 2013 8:10 AM To: users@tomcat.apache.org Subject: SSL configuration on Tomcat7. Hello Everyone, I am Shahid Tamboli and working at Mobimedia Technologies, Pune, India. We are stuck up with configuring our server with SSL. We have taken an Ubuntu instance on Amazon. We have installed Tomcat on the server. The Tomcat version is Tomcat 7 We are facing issues of configuring SSL certificates on my Tomcat server We have followed the following steps of deploying the certificate. http://www.networksolutions.com/support/installation-for-java-based-webservers-e-g-tomcat-using-keytool/http://prolinks.rediffmailpro.com/cgi-bin/prored.cgi?red=http%3A%2F%2Fwww%2Enetworksolutions%2Ecom%2Fsupport%2Finstallation%2Dfor%2Djava%2Dbased%2Dwebservers%2De%2Dg%2Dtomcat%2Dusing%2Dkeytool%2FisImage=0BlockImage=0rediffng=0 On following the above steps we are getting error of certificate not trusted and on contacting the Certificate Provider they told us to check our installation again. Thus if anyone can help us on this issue Thank You -- Cheers Shahid!!! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
TcpFailureDetector memberDisappeared
Hi everybody..
Hope you can help with this..
Were running Tomcat 6.0 in cluster, its been running now maybe 2yrs
without problems.. then this..
We've checked and renewed all network components (cables, hubs
switches) checked all machines
Including monitoring with Wireshark tcpdump...
Best regards
Tim
25.04.2013 17:17:14
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Verification complete. Member still
alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-6
4, -88, 6, 19}:4000,{-64, -88, 6, 19},4000, alive=2260923,id={-10 1 -21
124 -22 1 79 68 -85 47 27 -30 -97
54 55 92 }, payload={}, command={}, domain={}, ]]
2013-04-25 17:17:18,525 DEBUG (HotelFewoDetails.java:223) - mapAvailable
2013-04-25 17:17:18,526 DEBUG (HotelFewoDetails.java:141) - image
25.04.2013 17:17:31
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp:/
/{-64, -88, 6, 19}:
4000,{-64, -88, 6, 19},4000, alive=2277935,id={-10 1 -21 124 -22 1 79 68
-85 47 27 -30 -97 54 55 92 }, pay
load={}, command={}, domain={}, ]] message. Will verify.
25.04.2013 17:17:31
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Verification complete. Member still
alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-6
4, -88, 6, 19}:4000,{-64, -88, 6, 19},4000, alive=2277935,id={-10 1 -21
124 -22 1 79 68 -85 47 27 -30 -97
54 55 92 }, payload={}, command={}, domain={}, ]]
25.04.2013 17:17:48
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp:/
/{-64, -88, 6, 19}:
4000,{-64, -88, 6, 19},4000, alive=2294751,id={-10 1 -21 124 -22 1 79 68
-85 47 27 -30 -97 54 55 92 }, pay
load={}, command={}, domain={}, ]] message. Will verify.
25.04.2013 17:17:48
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Verification complete. Member still
alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-6
4, -88, 6, 19}:4000,{-64, -88, 6, 19},4000, alive=2294751,id={-10 1 -21
124 -22 1 79 68 -85 47 27 -30 -97
54 55 92 }, payload={}, command={}, domain={}, ]]
25.04.2013 17:17:54
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp:/
/{-64, -88, 6, 19}:
4000,{-64, -88, 6, 19},4000, alive=2301120,id={-10 1 -21 124 -22 1 79 68
-85 47 27 -30 -97 54 55 92 }, pay
load={}, command={}, domain={}, ]] message. Will verify.
25.04.2013 17:17:54
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Verification complete. Member still
alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-6
4, -88, 6, 19}:4000,{-64, -88, 6, 19},4000, alive=2301120,id={-10 1 -21
124 -22 1 79 68 -85 47 27 -30 -97
54 55 92 }, payload={}, command={}, domain={}, ]]
25.04.2013 17:19:34
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp:/
/{-64, -88, 6, 19}:
4000,{-64, -88, 6, 19},4000, alive=2400766,id={-10 1 -21 124 -22 1 79 68
-85 47 27 -30 -97 54 55 92 }, pay
load={}, command={}, domain={}, ]] message. Will verify.
25.04.2013 17:19:34
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Verification complete. Member still
alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-6
4, -88, 6, 19}:4000,{-64, -88, 6, 19},4000, alive=2400766,id={-10 1 -21
124 -22 1 79 68 -85 47 27 -30 -97
54 55 92 }, payload={}, command={}, domain={}, ]]
25.04.2013 17:20:58
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp:/
/{-64, -88, 6, 19}:
4000,{-64, -88, 6, 19},4000, alive=2479368,id={-10 1 -21 124 -22 1 79 68
-85 47 27 -30 -97 54 55 92 }, pay
load={}, command={}, domain={}, ]] message. Will verify.
25.04.2013 17:20:58
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Verification complete. Member still
alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-6
4, -88, 6, 19}:4000,{-64, -88, 6, 19},4000, alive=2479368,id={-10 1 -21
124 -22 1 79 68 -85 47 27 -30 -97
54 55 92 }, payload={}, command={}, domain={}, ]]
25.04.2013 17:21:46
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
memberDisappeared
INFO: Received
memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp:/
/{-64, -88, 6, 19}:
4000,{-64, -88, 6, 19},4000, alive=2533416,id={-10 1 -21 124 -22 1 79 68
-85 47 27 -30 -97 54 55 92 }, pay
load={}, command={}, domain={}, ]] message. Will verify.
25.04.2013 17:21:46
Re: Question on servlet determination
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 4/24/13 4:46 PM, Konstantin Kolinko wrote: No. With the following pattern requesting the ../foo/bar URI above results in 404 for me. (In current 7.0.x, should not be different from 7.0.39). url-pattern/servlets/servlet/RequestInfoExample/url-pattern Adding an extra / works correctly. My adding here is adding to request URI in web browser, . http://localhost:8080/examples/servlets/servlet/RequestInfoExample http://localhost:8080/examples/servlets/servlet/RequestInfoExample/ With clean 7.0.39: http://localhost:8080/examples/servlets/servlet/RequestInfoExample I get the example page with pathInfo=null http://localhost:8217/examples/servlets/servlet/RequestInfoExample/ I also get the example page with pathInfo=/ My question is why the top url (with no trailing /) is getting the request at all, given the url-pattern in web.xml: servlet-mapping servlet-nameRequestInfoExample/servlet-name url-pattern/servlets/servlet/RequestInfoExample/*/url-pattern /servlet-mapping The way I read that, the trailing /* is being interpreted as *. Am I missing something? Why does /servlets/servlet/RequestInfoExample not require a trailing / to be dispatched to that servlet? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJReVzNAAoJEBzwKT+lPKRYJM4P/1ZW3zOJMm5qLXWgFCIMZLKt 4h3176dZSPtBnvup0b8IRImLTJhMpHLyFGEbAh9ZCE4AaTbb0o7EiwwpE++oIu9M SKzaF0EdZhA9h7/3MpVw6jF5K9Jf7weBbEHC7VhDXYoBMmfH0WRQ6n+wFsT+H3+W k0oXlvC42BRkT+bOGCm5g9gd7XIflqtZ9kCG6bpL7dlvL614b4HTWARNVpFRJrZ9 VvC/sCo2WiJd+cbG2XURRQCHhdfVeaL6ndaL6qYVvVheNFslXWw997EcKxwFpd88 UtjPvDiBNjB1l9TqFVU/Qntrv0j+NMVlQzIh13lsqLgpm+MWZ2tBbP72ZzY5tSWg QIV4+qYhL5YTrN8+Y7aLrr0qovjvXQMZCtxTxYJWJ1fuNswHeArO66vJUIvxce1O fePVIGI3PpWjzakmBPUJKyp5yiRRlGT9Cw7cqBV9wtMufyYLMBtebVoq+nntAN9q UfTQh13++XYjDFYqkDNdaXbbS7ebaL2a/Q2017GYLvxmrNOswUFbLDZvPuV4AJY6 5GvbNWAC8LnK0tDskp/3N4R7fqSpoi05xd72SCr45ud6Sbz893/r2W1cEPSl7Fpw LEUw1euiWh2yzTHILOuCfDvuPa0XU4qmACh1wnJlfqAzvrlV6Od+Vixa8bO+quQx mS4RmVAYKOfyWgYKUDBX =qAan -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Policy files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Christian, On 4/24/13 11:25 PM, Christian Beikov wrote: Well I understand that there is only one SecurityManager per JVM, but as you mentioned I can restrict actions for specific CodeBases. This is what I am actually trying to do. I want the student web applications to have only a hand full of permissions defined in a policy file. I'm curious as to what permissions you want them to have while restricting others. Can you give some examples? I think I explained my self wrong earlier. The policy file I am speaking of, the one I want to apply to student projects, is more like a set of permissions that I want to give the web applications. I mainly want my testsuite and everything packaged with it to have all permissions. Generally the student projects should have no permissions. I want to give these applications only a minimal set of permissions, only the ones they actually would need to fullfil their tasks. I understand what you are saying, but examples would certainly help. The WebappClassLoader supports the method addPermission(Permission) which is nice somehow, but I don't want to hard code the permissions but rather have them in a policy file or so. I actually had no idea that WebappClassLoader had a set of addPermission methods. I'll have to read more about those they seem to give access to the parent classes (URLClassLoader, SecureClassLoader)'s permissions lists. Cool if it works. I honestly had no idea that some ClassLoaders maintain their own permissions lists. The reason for having the permissions in a policy file is mainly because I thought I can configure something in context.xml so that the policy file gets picked up by tomcat. If you want this, then you'll have to do a couple of things: 1. Make sure the context.xml always has the stuff you want (and isn't under control of the student, for instance -- otherwise they can just give themselves whatever permissions they want) 2. Create a ServletContextListener that runs on startup 3. Your listener needs to parse your policy and apply it to the WebappClassLoader. I wouldn't be surprised if the webapp itself is not permitted to add permissions to the WebappClassLoader. You might have to put your ServletContextListener higher-up in the ClassLoader hierarchy in order to be allowed to call that method. 4. Figure out how to parse a policy file. Note that #4 just means /your/ policy file. It doesn't have to be a classic Java Policy File. You could have a simple policy file like this: java.io.File.read=/path/to/some/data java.io.File.write=/dev/null Then you can parse it any way you like. Use XML if it's more convenient. I just don't want to have these applications running on my computer not knowing what they actually do. To be honest I couldn't think of any permission I would give a student application. The libraries that can be used are predefined, so I give these jar files the permissions for reflection or whatever they need to work properly. If you don't know what permissions they would need, maybe you should wait until you actually need to give those permissions before you spend a lot of time building infrastructure to support granting them. Am I simplifying the whole thing and is what I want much harder to achive than I think? If it were me, I'd look at a particular project and imagine any privileges you'd need to give to a webapp in order for it to function. For instance, if you have a webapp that is just a Hello World then you don't need any permissions. If you need to access a database, then you'll need to give them access to that, too. If everyone needs access to the same database, maybe just make it a top-level permission that all code can access localhost:1234 or whatever in order to contact the database. I think you'll find that lots of what you want can be configured at the global level without worrying too much about assigning permissions to individual webapps. Instead, all webapps will likely need the same permissions (e.g. reflection) and you can simply give *all* code in the JVM permissions to do that. Then you have much less code to write. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJReWOHAAoJEBzwKT+lPKRYDjIP+wY5GP++U4B9sTRbQLCjpOKZ wCkg4QnaKP6/eWikJa2HpuQ0re2428utIxv+nXSRdACWXgIx/lQbD2oTF8OfNC86 1ltP8kDXA5kUDT5y4nbpGeWzl0wUuEM4Ce/wmq8mkyKTqvLj2vMDiXrUNSjfgrBS UVUm/P3kn0E0oJubyRZ19IJITC8Iv7rnnppOSEPOz+hj1/zVbblkHK91UEqmLy4+ 6kcdZ8Xxvq33vHWfCjsmosJuvIljh5SYl8CLTtEDv+gr/x/YweJoVA9m1tNXp97u QgZrzrCBz5L+RBnplz1vZFae/eqhm2FPjVZL9p3Kw8utqZa03rj/ugwBZO1/WP7L zv46CQaN0cRuM6RMik9rkwKjIIz8VPgr62zvfApkDamYpej07/HIG0lIVpSc6fa4 O9U4KjRTfCOCG2zZyE1eQq+Qzxg/MMlrik4uNQV/KNMM7WASFjOv1+c/Q7M9oeJm c5dgInU3mTU6o+LW/b1By3sRxkadR5/Vhx3X+7aFGya+VBonkQrpFB9qV494bzvi
Re: SSL configuration on Tomcat7.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Shahid, On 4/25/13 11:10 AM, Shahid Tamboli wrote: Hello Everyone, I am Shahid Tamboli and working at Mobimedia Technologies, Pune, India. We are stuck up with configuring our server with SSL. We have taken an Ubuntu instance on Amazon. We have installed Tomcat on the server. The Tomcat version is Tomcat 7 We are facing issues of configuring SSL certificates on my Tomcat server We have followed the following steps of deploying the certificate. http://www.networksolutions.com/support/installation-for-java-based-webservers-e-g-tomcat-using-keytool/http://prolinks.rediffmailpro.com/cgi-bin/prored.cgi?red=http%3A%2F%2Fwww%2Enetworksolutions%2Ecom%2Fsupport%2Finstallation%2Dfor%2Djava%2Dbased%2Dwebservers%2De%2Dg%2Dtomcat%2Dusing%2Dkeytool%2FisImage=0BlockImage=0rediffng=0 On following the above steps we are getting error of certificate not trusted and on contacting the Certificate Provider they told us to check our installation again. Thus if anyone can help us on this issue Please tell us exactly what steps you took. I know you were following an online howto, but please start over again (e.g. delete your keystore), and tell us how you went from a clean installation of Tomcat to where you are today. You are likely missing a step (or 2). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJReWRcAAoJEBzwKT+lPKRYRwsQAKICvLmY0lOyDEc9MVgIDY4f suloGbVGQCC9g5GfVs9qmMnac6Ruz6WCqrjyDGRdcGwZxhwfkouoRK0cbiHJgLIn 5w5h8y+otFMaq1tzrBRPBp13wilPravSOkSFEREKuTj6he+vc5lN1ANnOi8NGk1h Mk/ETbie6QH4XUfzg8HpR9GfTq9eItluPnFWwQKzpdtg0DIlEwZzMGe0zYr0Rhjo bU2wA9IoTVXPKprlWsXI4imMiCs9YEyE7qmbWQl6nwL1j0zomzJXuyeyqPKM8G+J ZPBh3udF7p3PUx2LhZMWpakI+9tqOBXynxr+RMhdcb0ogXA99xv0c8lKixbTR5D0 vtEPxVP9YcJzaS4MimCQeZfAeAh9EF19RqI57n8TN0POAPXnRgJaGdUqBcs9Jx34 4k5kjrQMMNCBVk/DGKKR0TwaoeOap7vL8TFVTcrYqcfQ1DMyeC5t0kRDH0z2m0pp 1AMiLcdgEsr5xyuyIAG4EQXAtFzsJn4MNkvo051JCrQkfmEEKutZp0sZdpRGHtOk WPXlctMEI2UEd3Or4CYC0BtZ8BzU/hlJPmo/8g47jXcqtqUiu1P0KRRIvciNbFLI i2GHz99pGJpxVg0fo6gF+5NFIyujziClqcYCmkpkEicGXJi1zyTBvToZvNIZwnRT JlC3o06nDSVeVgsCSnpG =xcyh -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Question on servlet determination
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Question on servlet determination http://localhost:8080/examples/servlets/servlet/RequestInfoExample I get the example page with pathInfo=null http://localhost:8217/examples/servlets/servlet/RequestInfoExample/ I also get the example page with pathInfo=/ My question is why the top url (with no trailing /) is getting the request at all, given the url-pattern in web.xml: servlet-mapping servlet-nameRequestInfoExample/servlet-name url-pattern/servlets/servlet/RequestInfoExample/*/url-pattern /servlet-mapping Likely because of these clauses in the spec: The container will recursively try to match the longest path-prefix. This is done by stepping down the path tree a directory at a time, using the '/' character as a path separator. The longest match determines the servlet selected. A string beginning with a '/' character and ending with a '/*' suffix is used for path mapping. (The above is from 3.0, section 12.1, rule 2, and section 12.2, first bullet.) But I haven't looked at the code to see how it's actually implemented. - 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL configuration on Tomcat7.
Shahid, Chris, On 25.4.2013 19:14, Christopher Schultz wrote: On 4/25/13 11:10 AM, Shahid Tamboli wrote: Hello Everyone, I am Shahid Tamboli and working at Mobimedia Technologies, Pune, India. We are stuck up with configuring our server with SSL. We have taken an Ubuntu instance on Amazon. We have installed Tomcat on the server. The Tomcat version is Tomcat 7 We are facing issues of configuring SSL certificates on my Tomcat server We have followed the following steps of deploying the certificate. http://www.networksolutions.com/support/installation-for-java-based-webservers-e-g-tomcat-using-keytool/http://prolinks.rediffmailpro.com/cgi-bin/prored.cgi?red=http%3A%2F%2Fwww%2Enetworksolutions%2Ecom%2Fsupport%2Finstallation%2Dfor%2Djava%2Dbased%2Dwebservers%2De%2Dg%2Dtomcat%2Dusing%2Dkeytool%2FisImage=0BlockImage=0rediffng=0 On following the above steps we are getting error of certificate not trusted and on contacting the Certificate Provider they told us to check our installation again. Thus if anyone can help us on this issue Please tell us exactly what steps you took. I know you were following an online howto, but please start over again (e.g. delete your keystore), and tell us how you went from a clean installation of Tomcat to where you are today. You are likely missing a step (or 2). No, no, no... do not delete keystore. That may be the only place where your private key is. If you delete your private key, you will have to generate new private key, and purchase new certificate. I guess Chris missed to notice that you gave us URL from commercial CA. So, I propose that you just locate your keystore and run keytool -list -keystore /path/to/my_keystore.jks And send us the results here. Also send us your server.xml with comments and passwords removed. -Ognjen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL configuration on Tomcat7.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ognjen, On 4/25/13 4:47 PM, Ognjen Blagojevic wrote: Shahid, Chris, On 25.4.2013 19:14, Christopher Schultz wrote: On 4/25/13 11:10 AM, Shahid Tamboli wrote: Hello Everyone, I am Shahid Tamboli and working at Mobimedia Technologies, Pune, India. We are stuck up with configuring our server with SSL. We have taken an Ubuntu instance on Amazon. We have installed Tomcat on the server. The Tomcat version is Tomcat 7 We are facing issues of configuring SSL certificates on my Tomcat server We have followed the following steps of deploying the certificate. http://www.networksolutions.com/support/installation-for-java-based-webservers-e-g-tomcat-using-keytool/http://prolinks.rediffmailpro.com/cgi-bin/prored.cgi?red=http%3A%2F%2Fwww%2Enetworksolutions%2Ecom%2Fsupport%2Finstallation%2Dfor%2Djava%2Dbased%2Dwebservers%2De%2Dg%2Dtomcat%2Dusing%2Dkeytool%2FisImage=0BlockImage=0rediffng=0 On following the above steps we are getting error of certificate not trusted and on contacting the Certificate Provider they told us to check our installation again. Thus if anyone can help us on this issue Please tell us exactly what steps you took. I know you were following an online howto, but please start over again (e.g. delete your keystore), and tell us how you went from a clean installation of Tomcat to where you are today. You are likely missing a step (or 2). No, no, no... do not delete keystore. That may be the only place where your private key is. Erp... sorry! You are absolutely right. I keep forgetting how astoundingly stupi... er, efficient! ... Java keystores are. If you delete your private key, you will have to generate new private key, and purchase new certificate. This is true. I hope the OP reads this before blowing that file away. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRed7tAAoJEBzwKT+lPKRYJwIP/RFIaEw65anffhuE9KRcQ75K AY89quXsNKfu5L3lFRyjHM9VfZx4S6qD86ntmF94r0gM22Ka0LS0Lih8E6/lVe0j fDEbU3pm0dgb/3gYrxJ7dDVoFOR2oqS1l5aNScKCwtPlad6bs3quJvLSjqVRermk SyQ9iypv63/08QfMflkwUgzzkvWFrZ39Qd6fSi0vAkl/M1S8CbgLBGZnTMH6NZxh +Xj3/2B8sTvzLrS/Nc0ez4vBbFQ8wmeQyGM6t5x7GIh128UEAK0AuIOHLNjd960i yQOdFDDpIv29eoJlMvjvEsVVZk4h2fUK9LB0XnG2w+Eqr77AyEatMbE5F7BHpzFr i3JThXgV7/ufhH0jIGWvGK4dwBD/zjz/e22E8/464j2dHLt38L6BuEXNMGMUcnK7 RCcmkWLtBgG6aTyjEDED7EpkYGpJJh1GmFM1BmefkSLDTJ0HWSPy1n14d7z4tv3L KgxPcEQjG8lXw9US+GHJRO2yqUfSomh5fBxQyl/+kUJ8bJF+Fk+MGxYURevgR3PE 5LhCraNNT2HZzd7c3Y62F1tgpyXr18VzELYmFouYOQrYtpSEJzQnxXr3I5TkjcMo +u4vcVjq3HZFFYJP7cKSXwXStm2GZWE2l2cTz5rd3tAmPiORNARM4sor0/4E3MKu SCgPv5ofcL+7sGbzoSrr =qx5U -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
