Re: Connection resets without timeout
I'm curious as well -- I ran into this too and the only work around I had was to send a heartbeat which, if the client was gone, would complete the lifecycle (server sent events in my particular case). This was ugly and felt wrong so I'd love to know the right thing to do. On Aug 25, 2015, at 12:12, Steffen Heil (Mailinglisten) li...@steffen-heil.de wrote: Hi When using async servlets with timeout set to 0, tomcat seems not to detect, if the client closes the connection. At least the servlet listener is not notified. I expected AsyncListener.onComplete or AsyncListener.onError or AsyncListener.onTimeout, but none of these are called. The only thing called is ReadListener.onAllDataRead but that’s expected as the request is a POST request with few inbound data but long running outbound data. Now we have no way to detect when the connection to the client is broken. On TCP level the connection was closed (FIN/FIN+ACK), so tomcat should know that the connection is gone. Is there any way to get notified about that or at least to check manually? Regards, Steffen BTW: I am posting new questions that are not direct follow-ups as top messages. If there is another policy for this list, please let me know. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Connection resets without timeout
Hi When using async servlets with timeout set to 0, tomcat seems not to detect, if the client closes the connection. At least the servlet listener is not notified. I expected AsyncListener.onComplete or AsyncListener.onError or AsyncListener.onTimeout, but none of these are called. The only thing called is ReadListener.onAllDataRead but that’s expected as the request is a POST request with few inbound data but long running outbound data. Now we have no way to detect when the connection to the client is broken. On TCP level the connection was closed (FIN/FIN+ACK), so tomcat should know that the connection is gone. Is there any way to get notified about that or at least to check manually? Regards, Steffen BTW: I am posting new questions that are not direct follow-ups as top messages. If there is another policy for this list, please let me know. smime.p7s Description: S/MIME cryptographic signature
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Am 24.08.2015 um 21:23 schrieb Mark Thomas: On 24/08/2015 16:40, Alten, Jessica-Aileen wrote: We'd love to provide Windows binaries for mod_jk, but they are a real pain in the neck to actually build: they require very specific build environment, and the library must be built in such a way that it's compatible with the web server in which it's running (e.g. httpd 1.3/2.2/2.4 or IIS 5/6/7/8/9, proper architecture (32/63) and chipset (x86/x86-64/itanium/alpha). It's gotten to the point where it's tough to provide all of those combinations with any regularity. I understand that it is difficult - perhaps too difficult for the developers of this module, but the average Windows admin or Java programmer should do this? ;) There were binaries of this module at least for the last 10 years! I'm very disappointed on this attitude. You are closing out the whole Windows/IIS world. Yes, we (the Tomcat community) has a problem here. We needed a jk release to address a security issue that had been made public before we were ready. The developers that normally work on jk have been quiet lately so one of the other Tomcat developers stepped up to do the release. The source code side of things is relatively simple but the binaries are not and the document build process is not sufficient to generate a binary release. This is the documented build process for ISAPI: http://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis/README?view=annotate We don't have the equivalent 'How to build a release' documentation. It is not at all clear how release builds (which options have been used, what have they been compiled with / against?) have been built in the past so it is next to impossible to reproduce a similar build. Unfortunately, I don't believe they provide builds for the ISAPI redirector for IIS. If that's what you need... umm... Umm - yes - this is what I need. There are a couple of options: Hope the jk committers provide enough information to document the release process so anyone can run it. Figure out how to build something that works for you and share that with the Tomcat community so anyone can build it. Then one of the active Tomcat committers will be able to include the binary in the next release (and provide an official binary for this release). I just tried the isapi_redirector build using VC 2010 and the Makefile.amd64. No additional flags, just setting up the compiler with setenv /Release /x64 (as usual for MSVC) before running it. Then changing into the iis src directory and running nmake -f Makefile.amd64 which results in Release_amd64/isapi_redirect.dll (the IIS plugin) and Release_amd64/isapi_redirect.pdb (the symbol file needed for debugging). The build was done on Windows 7 64 Bits Professional, but I think that is less important then the MSVC version used. Since I'm using the 2010 compiler, the produced binary has a dependency on the MSVCR100.dll runtime library, which must be installed independently on the system if not yet available, but at least there are redistributables for it provided by Microsoft, see https://www.microsoft.com/en-US/download/details.aspx?id=. I have checked the dependency using the depends.exe dependency walker (similar to Unix/Linux ldd), see http://www.dependencywalker.com/. I'd hope that the usual runtime library compatibility issues are not the problematic for the ISAPI redirector as for mod_jk on Windows. Maybe IIS can cope better with plugins using different versions of the runtime libs. I definitely don't have a version 6 compiler to prevent using the newer runtime libs. @Jessica: which CPU architecture are you using: x86 (32 Bit), x64 (64 Bits) or even Itanium 64? Which OS version do you have? If you are willing to test, I can provide an example binary from which we might learn, how well it works and whether that type of build is suitable for others as well. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Exception using Async Servlet
Hi I am using servlets with startAsync to be able to read and write asynchronously. However from time to time the following is logged: Aug 25, 2015 5:52:32 PM org.apache.catalina.connector.CoyoteAdapter asyncDispatch SCHWERWIEGEND: Exception while processing an asynchronous request java.lang.IllegalStateException: Calling [asyncError()] is not valid for a request with Async state [MUST_COMPLETE] at org.apache.coyote.AsyncStateMachine.asyncError(AsyncStateMachine.java:348) at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:820) at org.apache.coyote.Request.action(Request.java:378) at org.apache.catalina.core.AsyncContextImpl.setErrorState(AsyncContextImpl.java:406) at org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:332) at org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(AbstractHttp11Processor.java:1709) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:649) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1527) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1484) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) There is no code of our own involved so I am wondering if my configuration is invalid or I am using the servlet in an incorrect way. I would post some of the code we use here, but it is not really small, so where would I need to start searching or posting? Regards, Steffen smime.p7s Description: S/MIME cryptographic signature
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
All, I still don't quite understand how I ended up in this position, but when Stephen from the Apache Lounge builds a new tomcat native build of something, he asks me to inform the tomcat mailing list. I consider it the very least I can do for the community, but struggle to see how I am adding value. Anyway his notification below. His original subject was mod_jk-1.2.41 VC11 but it seemed prudent to send on this thread. Chris Hi Chris, Just build it for VC11, see https://www.apachelounge.com/viewtopic.php?p=31471 Maybe you can inform the list. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Asynchronous writes (Servlet and WebSocket)
On 25/08/2015 13:15, Steffen Heil (Mailinglisten) wrote: Hi I am investigating, how I can archive asynchronous writes with tomcat. archive? I'm guessing you mean achieve. For servlets I came up with code like this: final AsyncContext context = request.startAsync(); final ServletInputStream input = request.getInputStream(); final ServletOutputStream output = response.getOutputStream(); ChannelProcessor processor = new ChannelProcessor( channel, input, output ); context.addListener( processor ); input.setReadListener( processor ); output.setWriteListener( processor ); While ChannelProcessor is my class that implements (beside others) WriteListener, so I get notified, when the ServletOutputStream is ready to send more data. However, looking at the code, I suspect that output.write( byte[] buffer ) will still block, if the amount of data in buffer is larger than the maximum size of the OutputBuffer used by that connection: No, it will buffer it all in the SocketWrapper. You won't get another notification until the buffered data has been written. For WebSockets there is session.getAsyncRemote().sendBinary( buffer, handkler ); But that calls ServletOutputStream.write (maybe from another thread) Same as above. So, are these really asynchronous? Yes. Is a call to ServletOutputStream.write always guaranteed to return without blocking?` Yes, assuming you are not using the BIO connector (where it always blocks regardless). Where is that implemented? The detail varies between versions due to the refactoring that has gone on over time in the connectors but in trunk that is all handled by SocketWrapperBase.writeNonBlocking() Generally, the trunk code should be easier to follow because of the refactoring. HTH, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 8.0.26 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.0.26. Apache Tomcat 8 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language and Java WebSocket technologies. Apache Tomcat 8.0.26 includes numerous fixes for issues identified in 8.0.24 as well as a number of other enhancements and changes. The notable changes since 8.0.24 include: - Fix EOF handling in the AJP APR/native connector to avoid the tight loop that caused high CPU load - Avoid an NPE when adding POJO WEebSocket endpoints programmatically - Improved handling of async timeouts Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-8.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-80.cgi Migration guides from Apache Tomcat 5.5.x, 6.0.x and 7.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems with tomcat-connectors-1.2.41 on 32bit linux
Am 25.08.2015 um 14:58 schrieb Falco Schwarz:
Hi there,
I tried to update the connectors to the most recent update but I am stuck
with error messages. Just a few background information on the
infrastructure used:
httpd: 2.2.31
OpenSSL: 1.0.2.d
mod_jk: 1.2.41
Kernel: 3.0.101-0.47.52-pae
OS: SLES 11 SP3 (32bit)
gcc: (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]
httpd configure: ./configure --prefix=/opt/apache
--sysconfdir=/opt/apache/build --enable-mods-shared=all ssl ldap cache
proxy authn_alias authnz_ldap dav_lock --with-mpm=prefork
--with-included-apr --with-pcre --with-ldap --with-ssl=/opt/apache/openssl
jk configure: ./configure --with-apxs=/opt/apache/bin/apxs
configure, make and install runs without any errors. If I try to startup
httpd though the following error occurs:
httpd: Syntax error on line 88 of /opt/apache/conf/alles/httpd.conf: Cannot
load /opt/apache/modules/mod_jk.so into server:
/opt/apache/modules/mod_jk.so: undefined symbol: __sync_add_and_fetch_4
When I added the use of atomics, I checked for the minimal GCC version
to support it. At that time I didn't notice, that GCC originally had
only support for some architectures, and for all other architectures
compiles in a call to a function named __sync_add_and_fetch_4(), which
it does not implement itself.
There's a couple of options:
- use a newer GCC, it might support x86 atomics. But I guess you'd like
to stick to your SLES provided GCC, so this probably is not an option
for you.
- As a workaround fall back to what APR provides as atomics. In file
common/jk_global.h you could comment out the following lines with a
leading //:
436 #elif defined(__GNUC__) (__GNUC__ 4 || (__GNUC__ == 4
__GNUC_MINOR__ = 1))
437 #define JK_ATOMIC_INCREMENT(x) __sync_add_and_fetch(x, 1)
438 #define JK_ATOMIC_DECREMENT(x) \
439 do {\
440 if (__sync_sub_and_fetch(x, 1) 0) __sync_add_and_fetch(x, 1);\
441 } while (0)
or simply change the #elif line 436 e.g. to
#elif defined(JK_USE_GCC_ATOMICS) defined(__GNUC__) (__GNUC__ 4
|| (__GNUC__ == 4 __GNUC_MINOR__ = 1))
Since JK_USE_GCC_ATOMICS is not defined, the elif will be skipped and
the next option (APR atomics) will be used, but you can later switch
back to the GCC version by compiling with -DJK_USE_GCC_ATOMICS. We might
add something like this and make the define be chosen according to
configure flags (--disable-gcc-atomics). Or maybe we should even use a
configure check to detect real support for GCC atomics on the target
platform.
Let us know how it works.
Thanks for reporting the problem,
Rainer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Asynchronous writes (Servlet and WebSocket)
Hi Thanks for assuring me, that it really is asynchronous. That was a blocker for us. archive? I'm guessing you mean achieve. Yes, I did. Sorry, not a native English speaker... No, it will buffer it all in the SocketWrapper. You won't get another notification until the buffered data has been written. Ok. Yes, assuming you are not using the BIO connector (where it always blocks regardless). NIO only. Where is that implemented? The detail varies between versions due to the refactoring that has gone on over time in the connectors but in trunk that is all handled by SocketWrapperBase.writeNonBlocking() I am using 8.0.24. There I did not find such a class. Generally, the trunk code should be easier to follow because of the refactoring. Will these refactorings be in the next release? When is it due? Best regards, Steffen smime.p7s Description: S/MIME cryptographic signature
How to set Session Values with Form Based Authentication
Hi, I'm using form based authentication with j_security_check. I want to set some session values upon the user login. I can set them in the index page. But when user directly put some other url then it will redirect to login page and then back to the actual requested page. Therefore my logic on index page will not get execute. Is there a way for me to set the session value when using j-security_check based form authentication in Tomcat? Thanks /Thusitha --
Tomcat 7 - Organizing web applications into sub directories
I am trying to organize my applications (multiple) into a specific hierarchy under the webapps folder. Something like this - webapps dev app1 app2 test app1 app3 When deploying (without WAR), I am getting a 404 error for servlets. Tried changing the web.xml servlet mapping, still no luck. It works perfectly when the folder is moved directly under webapps like below - webapps app1 Does tomcat have a limitation on organizing webapps under multiple levels of folders (under the webapp directory)? -- *-* Srikanth Challa Founder, CEO Enterprise Atlas Inc. srika...@enterpriseatlas.com +1 (510) 402-6212
How to deal with LogJam Vulnerability?
Hi All, I am using Tomcat version 7.00.062 supported on JRE 8u45. How do i disable the LogJam Vulnerability? I have added a line in the java.security file of the JRE. jdk.tls.disabledAlgorithms=DH Is this good enough? Or do we need to add DiffieHelmann also? jdk.tls.disabledAlgorithms=DH, DiffieHellman Which one solves the issue of LogJam? Kindly help. Regards, Nikitha
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Am 25.08.2015 um 20:41 schrieb Christopher Schultz: On 8/25/15 11:49 AM, Rainer Jung wrote: I just tried the isapi_redirector build using VC 2010 and the Makefile.amd64. No additional flags, just setting up the compiler with setenv /Release /x64 (as usual for MSVC) before running it. Then changing into the iis src directory and running nmake -f Makefile.amd64 which results in Release_amd64/isapi_redirect.dll (the IIS plugin) and Release_amd64/isapi_redirect.pdb (the symbol file needed for debugging). The build was done on Windows 7 64 Bits Professional, but I think that is less important then the MSVC version used. Since I'm using the 2010 compiler, the produced binary has a dependency on the MSVCR100.dll runtime library, which must be installed independently on the system if not yet available, but at least there are redistributables for it provided by Microsoft, see https://www.microsoft.com/en-US/download/details.aspx?id=. I have checked the dependency using the depends.exe dependency walker (similar to Unix/Linux ldd), see http://www.dependencywalker.com/. I'd hope that the usual runtime library compatibility issues are not the problematic for the ISAPI redirector as for mod_jk on Windows. Maybe IIS can cope better with plugins using different versions of the runtime libs. I definitely don't have a version 6 compiler to prevent using the newer runtime libs. I believe we go through great pains with tcnative to build against MSVCRT.DLL because, evidently, that is guaranteed to be available on any modern Windows system (I think that means win2k/NT4.0+... possibly back to win95). This reduces the installation complexity for the end user, but requires lots of work on the part of the packager. I'd like to know what the community thinks about building against MSVCRT100.DLL, which is essentially the same thing and I would imagine that everyone has that DLL these days. (The issue, of course, is that we can't bundle it ourselves due to licensing restrictions.) Can we statically-link instead of using the DLL? Would that be very stupid? Seems like it would solve everything. AFAIR the original problem about the msvc runtime libs is, that different versions are not compatible with each other. The one needed by MSVC 6 (msvcrt.dll) is compatible with newer ones (the ones with numbers in their name), but newer ones for different numbers are not compatible with each other. Using different numbered versions in the same process can lead to crashes etc. This is a problem, if your process consists of different pieces compiled with different MSVC versions and thus loading different msvc libs. One example is the Apache web server provided/compiled by someone and a module provided/compiled by someone else. Another might be the jvm (java.exe) and a native library loaded into it. For instance the java.dll contained in Java 1.8.0_51 and in 1.7.0_80 load msvcr100.dll. So when Oracle updates their tool chain, they might switch to a newer msvc runtime lib version. I'd hope that this is less likely to happen for IIS, but I haven't yet checked, whether IIS on newer systems itself still only has a dependency on MSVCRT.dll or also on newer versions. I hope not. Still there could be a problem if people add other extensions introducing such incompatibilities. So I think this is less about end user installation hassle. Adding the msvc redistribution once to systems isn't that uncommon as a task on windows. It is more about being compatible with msvc runtime libs loaded by other components inside the same process. The MS tool chain isn't suited to support modular software that's combined from different suppliers. For reference see e.g. https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx or https://msdn.microsoft.com/en-us/library/abx4dbyh%28v=vs.100%29.aspx for MSVC 2010 (especially the paragraph starting with If you have more than one DLL) and https://msdn.microsoft.com/en-us/library/ms235460.aspx I think from those descriptions the compatibility problem for tcnative might be void, because likely we don't pass native objects across the boundary, just references which are only natively used inside tcnative, not in the JVM anywhere else. For mod_jk the problem is harder, because there's a lot of data passed between httpd and mod_jk.so. As someone wrote: The same holds true in case of simple C structures too. Although it is unlikely that, say for an example, the order of struct tm or struct FILE, would change from one version of Visual Studio to another, one can’t reply on such assumptions. For the isapi redirector I'm undecided how likely a problem is. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 8/25/15 5:53 PM, Rainer Jung wrote: Am 25.08.2015 um 20:41 schrieb Christopher Schultz: On 8/25/15 11:49 AM, Rainer Jung wrote: I just tried the isapi_redirector build using VC 2010 and the Makefile.amd64. No additional flags, just setting up the compiler with setenv /Release /x64 (as usual for MSVC) before running it. Then changing into the iis src directory and running nmake -f Makefile.amd64 which results in Release_amd64/isapi_redirect.dll (the IIS plugin) and Release_amd64/isapi_redirect.pdb (the symbol file needed for debugging). The build was done on Windows 7 64 Bits Professional, but I think that is less important then the MSVC version used. Since I'm using the 2010 compiler, the produced binary has a dependency on the MSVCR100.dll runtime library, which must be installed independently on the system if not yet available, but at least there are redistributables for it provided by Microsoft, see https://www.microsoft.com/en-US/download/details.aspx?id=. I have checked the dependency using the depends.exe dependency walker (similar to Unix/Linux ldd), see http://www.dependencywalker.com/. I'd hope that the usual runtime library compatibility issues are not the problematic for the ISAPI redirector as for mod_jk on Windows. Maybe IIS can cope better with plugins using different versions of the runtime libs. I definitely don't have a version 6 compiler to prevent using the newer runtime libs. I believe we go through great pains with tcnative to build against MSVCRT.DLL because, evidently, that is guaranteed to be available on any modern Windows system (I think that means win2k/NT4.0+... possibly back to win95). This reduces the installation complexity for the end user, but requires lots of work on the part of the packager. I'd like to know what the community thinks about building against MSVCRT100.DLL, which is essentially the same thing and I would imagine that everyone has that DLL these days. (The issue, of course, is that we can't bundle it ourselves due to licensing restrictions.) Can we statically-link instead of using the DLL? Would that be very stupid? Seems like it would solve everything. AFAIR the original problem about the msvc runtime libs is, that different versions are not compatible with each other. The one needed by MSVC 6 (msvcrt.dll) is compatible with newer ones (the ones with numbers in their name), but newer ones for different numbers are not compatible with each other. Using different numbered versions in the same process can lead to crashes etc. I'm pretty sure that fprintf is compatible across versions, no? But the version-less DDL is reliably available on all modern systems, right? That's the real issue: is the library available on the target system. Using the version-less library gives us the widest compatibility without requiring the user to install one of the MSVC++ redistributable packages. This is a problem, if your process consists of different pieces compiled with different MSVC versions and thus loading different msvc libs. Oh, so it might depend upon whatever IIS uses. So.. how can we tell which MSVC was used by a particular IIS version? I'd hope that this is less likely to happen for IIS, but I haven't yet checked, whether IIS on newer systems itself still only has a dependency on MSVCRT.dll or also on newer versions. I hope not. Still there could be a problem if people add other extensions introducing such incompatibilities. So I think this is less about end user installation hassle. Adding the msvc redistribution once to systems isn't that uncommon as a task on windows. It is more about being compatible with msvc runtime libs loaded by other components inside the same process. The MS tool chain isn't suited to support modular software that's combined from different suppliers. Okay, good to know. Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV3OVJAAoJEBzwKT+lPKRYtlAQAK9fjKt8GBjdYPS+X0VwFZJh q+7H81fCRayq8TEFFEA5wArJjzDrhxk4kPI9t6lz53zOQEH5hqS7XgvhvAJc7kFW iWbm2w0XL7j4tx4arZtmWVF49jjayKx/wlJirzR0uy3A26075aovDyha6UcTerah CwViFV5DVpEDZc1gTd/KWAkkZ+D0prZIdF02rC0YlR/U7cdbHUtJMil6LtxgrSNL lZ1G6xmaDe1nZ2GFaDCcTEacyseEFFk14nBwtGgfu2KYkx37wVgnb8Ixs35ah+FK J+Bn6/pQOgIy3oebgCa4JS2ELndz75Lp+JIrsR0/tJbY5ku7LJgYGfg/cSch9697 z6sAfr9iqgXSjab4zdsSkOz7HH3B2LOPFYFFlh0wDloMRClig/hSpYf5DFt2PA7w 3PK7qy/9UoyWSU3qAHEtTnSB35jCtaY4t0PzXyhaSS7fhSNr2Fsid4AOJX9Oi2BV WX8lONlrANxXtyUJMd01nQjvu7H5nmCEVagBCN9Qx/xdUSb8v9oBfqGYkdnNdY7I hYM3GHJyNX5LS3jSFoUc+TcawTZbAwjAw1dDu9YTGpSPZhWlCspyJ5pLe5+11WiD i2avR3blmKn6OLIX2YPO0e/5vPNDBBWelLslod2DAcPqnqqilRsdabFDOJPOxVgY a/riwxnkWspvGcFysdX3 =QJtF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail:
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
Am 25.08.2015 um 23:59 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 8/25/15 5:53 PM, Rainer Jung wrote: Am 25.08.2015 um 20:41 schrieb Christopher Schultz: On 8/25/15 11:49 AM, Rainer Jung wrote: I just tried the isapi_redirector build using VC 2010 and the Makefile.amd64. No additional flags, just setting up the compiler with setenv /Release /x64 (as usual for MSVC) before running it. Then changing into the iis src directory and running nmake -f Makefile.amd64 which results in Release_amd64/isapi_redirect.dll (the IIS plugin) and Release_amd64/isapi_redirect.pdb (the symbol file needed for debugging). The build was done on Windows 7 64 Bits Professional, but I think that is less important then the MSVC version used. Since I'm using the 2010 compiler, the produced binary has a dependency on the MSVCR100.dll runtime library, which must be installed independently on the system if not yet available, but at least there are redistributables for it provided by Microsoft, see https://www.microsoft.com/en-US/download/details.aspx?id=. I have checked the dependency using the depends.exe dependency walker (similar to Unix/Linux ldd), see http://www.dependencywalker.com/. I'd hope that the usual runtime library compatibility issues are not the problematic for the ISAPI redirector as for mod_jk on Windows. Maybe IIS can cope better with plugins using different versions of the runtime libs. I definitely don't have a version 6 compiler to prevent using the newer runtime libs. I believe we go through great pains with tcnative to build against MSVCRT.DLL because, evidently, that is guaranteed to be available on any modern Windows system (I think that means win2k/NT4.0+... possibly back to win95). This reduces the installation complexity for the end user, but requires lots of work on the part of the packager. I'd like to know what the community thinks about building against MSVCRT100.DLL, which is essentially the same thing and I would imagine that everyone has that DLL these days. (The issue, of course, is that we can't bundle it ourselves due to licensing restrictions.) Can we statically-link instead of using the DLL? Would that be very stupid? Seems like it would solve everything. AFAIR the original problem about the msvc runtime libs is, that different versions are not compatible with each other. The one needed by MSVC 6 (msvcrt.dll) is compatible with newer ones (the ones with numbers in their name), but newer ones for different numbers are not compatible with each other. Using different numbered versions in the same process can lead to crashes etc. I'm pretty sure that fprintf is compatible across versions, no? But Ha! Not far from one of the real problem examples: http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell And MS says in http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refactoring.aspx: The best example of this maintainability problem could be found in the old implementation of the printf family of functions. The CRT provides 142 different variations of printf, but most of the behavior is the same for all of the functions, so there are a set of common implementation functions that do the bulk of the work. These common implementation functions were all defined in output.c in the CRT sources(1). This 2,696 line file had 223 conditionally compiled regions of code (#ifdef, #else, etc.), over half of which were in a single 1,400 line function. This file was compiled 12 different ways to generate all of the common implementation functions. Even with the large number of tests that we have for these functions, the code was exceedingly brittle and difficult to modify. But it seems, if this old blog describes what actually happened in the meantime, that starting with version 14 they moved from incompatible versions to using backwards compatible libs. Maybe some light at the horizon. the version-less DDL is reliably available on all modern systems, right? That's the real issue: is the library available on the target system. Using the version-less library gives us the widest compatibility without requiring the user to install one of the MSVC++ redistributable packages. This is a problem, if your process consists of different pieces compiled with different MSVC versions and thus loading different msvc libs. Oh, so it might depend upon whatever IIS uses. So.. how can we tell which MSVC was used by a particular IIS version? I'd hope that this is less likely to happen for IIS, but I haven't yet checked, whether IIS on newer systems itself still only has a dependency on MSVCRT.dll or also on newer versions. I hope not. Still there could be a problem if people add other extensions introducing such incompatibilities. So I think this is less about end user installation hassle. Adding the msvc redistribution once to systems isn't that uncommon as a task on windows. It is more about being compatible
API requests overloading Tomcat?
I use an application called Spacewalk to manage RHEL systems in an
enterprise environment. The application provides an API that I use for
automation purposes. While load starts to increase on the application
server, we reach a breaking point where the application becomes
unresponsive, and throws 500 internal server errors. Listed at the bottom
are some of the errors I see when this happens. I'm looking for advice on
how to better diagnose and\or tune my settings to optimize Tomcat
performance. I feel like the system is beefy enough to handle this load,
but Tomcat appears to be my bottleneck.. How should I go about resolving
this? I have played around with the AJP connector settings quite a bit, but
can't seem to find suitable parameters.
OS: RHEL6.6
RAM: 64GB (Please note, under heavy load, we are not utilizing
even 50% of RAM.. it seems to be all CPU, but I'm not sure how to get
Tomcat to utilize more RAM other than boosting the Xmx settings which I
have already done)
CPU: 16 (vCPU)
Tomcat:
apache-tomcat-apis-0.1-1.el6.noarch
tomcat6-el-2.1-api-6.0.24-83.el6_6.x86_64
tomcat6-lib-6.0.24-83.el6_6.x86_64
tomcat6-servlet-2.5-api-6.0.24-83.el6_6.x86_64
tomcat6-6.0.24-83.el6_6.x86_64
tomcat5-jsp-2.0-api-5.5.27-7.jpp5.noarch
tomcat6-jsp-2.1-api-6.0.24-83.el6_6.x86_64
tomcat5-servlet-2.4-api-5.5.27-7.jpp5.noarch
Java:
java-1.6.0-openjdk-1.6.0.36-1.13.8.1.el6_7.x86_64
Oracle client:
oracle-instantclient11.2-basic-11.2.0.3.0-1.x86_64
JAVA_OPTS=-ea -Xms512m -Xmx4096m -Djava.awt.headless=true
-Dorg.xml.sax.driver=org.apache.xerces.parsers.SAXParser
-Dorg.apache.tomcat.util.http.Parameters.MAX_COUNT=1024 -XX:MaxNewSize=256
-XX:-UseConcMarkSweepGC -Dnet.sf.ehcache.skipUpdateCheck=true
-Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory
-Djava.library.path=\${system_property:java.library.path}:/usr/lib:/usr/lib64/oracle/11.2/client/lib
Connector settings:
Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2
redirectPort=8443 URIEncoding=UTF-8 address=127.0.0.1
maxThreads=1024 maxKeepAliveRequests=1000/
!-- Define an AJP 1.3 Connector on port 8009 --
Connector port=8009 protocol=AJP/1.3 redirectPort=8443
URIEncoding=UTF-8 address=127.0.0.1 maxThreads=1024/
Connector port=8009 protocol=AJP/1.3 redirectPort=8443
URIEncoding=UTF-8 address=::1 maxThreads=1024/
From /var/log/tomcat6/catalina.out
Aug 25, 2015 1:33:23 AM org.apache.jk.core.MsgContext action
WARNING: Unable to send headers
java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at
java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:532)
at
org.apache.jk.common.JkInputStream.appendHead(JkInputStream.java:326)
at org.apache.jk.core.MsgContext.action(MsgContext.java:266)
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(OutputBuffer.java:305)
at
org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:288)
at
org.apache.catalina.connector.CoyoteWriter.flush(CoyoteWriter.java:95)
at
org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:175)
at
org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:956)
at
org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:622)
at
com.opensymphony.module.sitemesh.taglib.page.ApplyDecoratorTag.doEndTag(ApplyDecoratorTag.java:258)
at
org.apache.jsp.WEB_002dINF.pages.common.errors._500_jsp._jspx_meth_page_005fapplyDecorator_005f0(Unknown
Source)
at
org.apache.jsp.WEB_002dINF.pages.common.errors._500_jsp._jspService(Unknown
Source)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:438)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
at
org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:415)
at
org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:342)
at
org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:286)
at
Re: [ANN] Apache Tomcat Connectors 1.2.41 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 8/25/15 11:49 AM, Rainer Jung wrote: Am 24.08.2015 um 21:23 schrieb Mark Thomas: On 24/08/2015 16:40, Alten, Jessica-Aileen wrote: We'd love to provide Windows binaries for mod_jk, but they are a real pain in the neck to actually build: they require very specific build environment, and the library must be built in such a way that it's compatible with the web server in which it's running (e.g. httpd 1.3/2.2/2.4 or IIS 5/6/7/8/9, proper architecture (32/63) and chipset (x86/x86-64/itanium/alpha). It's gotten to the point where it's tough to provide all of those combinations with any regularity. I understand that it is difficult - perhaps too difficult for the developers of this module, but the average Windows admin or Java programmer should do this? ;) There were binaries of this module at least for the last 10 years! I'm very disappointed on this attitude. You are closing out the whole Windows/IIS world. Yes, we (the Tomcat community) has a problem here. We needed a jk release to address a security issue that had been made public before we were ready. The developers that normally work on jk have been quiet lately so one of the other Tomcat developers stepped up to do the release. The source code side of things is relatively simple but the binaries are not and the document build process is not sufficient to generate a binary release. This is the documented build process for ISAPI: http://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis/README?view=a nnotate We don't have the equivalent 'How to build a release' documentation. It is not at all clear how release builds (which options have been used, what have they been compiled with / against?) have been built in the past so it is next to impossible to reproduce a similar build. Unfortunately, I don't believe they provide builds for the ISAPI redirector for IIS. If that's what you need... umm... Umm - yes - this is what I need. There are a couple of options: Hope the jk committers provide enough information to document the release process so anyone can run it. Figure out how to build something that works for you and share that with the Tomcat community so anyone can build it. Then one of the active Tomcat committers will be able to include the binary in the next release (and provide an official binary for this release). I just tried the isapi_redirector build using VC 2010 and the Makefile.amd64. No additional flags, just setting up the compiler with setenv /Release /x64 (as usual for MSVC) before running it. Then changing into the iis src directory and running nmake -f Makefile.amd64 which results in Release_amd64/isapi_redirect.dll (the IIS plugin) and Release_amd64/isapi_redirect.pdb (the symbol file needed for debugging). The build was done on Windows 7 64 Bits Professional, but I think that is less important then the MSVC version used. Since I'm using the 2010 compiler, the produced binary has a dependency on the MSVCR100.dll runtime library, which must be installed independently on the system if not yet available, but at least there are redistributables for it provided by Microsoft, see https://www.microsoft.com/en-US/download/details.aspx?id=. I have checked the dependency using the depends.exe dependency walker (similar to Unix/Linux ldd), see http://www.dependencywalker.com/. I'd hope that the usual runtime library compatibility issues are not the problematic for the ISAPI redirector as for mod_jk on Windows. Maybe IIS can cope better with plugins using different versions of the runtime libs. I definitely don't have a version 6 compiler to prevent using the newer runtime libs. I believe we go through great pains with tcnative to build against MSVCRT.DLL because, evidently, that is guaranteed to be available on any modern Windows system (I think that means win2k/NT4.0+... possibly back to win95). This reduces the installation complexity for the end user, but requires lots of work on the part of the packager. I'd like to know what the community thinks about building against MSVCRT100.DLL, which is essentially the same thing and I would imagine that everyone has that DLL these days. (The issue, of course, is that we can't bundle it ourselves due to licensing restrictions.) Can we statically-link instead of using the DLL? Would that be very stupid? Seems like it would solve everything. Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV3LbzAAoJEBzwKT+lPKRYZJAP/jcbABmW39urbWUDQ6OYIJHB jXLhOyb4ibH9fGesEeNL/ye/i29WbX+uxp3TJWbQ2eKK5Lraom5TRzqm0zjJFgYR MEjuk7djBWX0TgnC2S2YlAnfxkzUCC4D2+1S9olPlX8J/mDmvbwS3ei4k+6QLjMO IvJ/fBYdga1dAhE8cnT4yIxj5MRzZk9GCQkwKrknksoTzU1J+UNbaVUomTAnDcqe akkvq0m/C8ubXRuq7bRLcYWBlgbYy22GxJClczMgmKTfIHoHnkG/nONgpvLxtq+i CDPt3B2ULoYsjz0xTWo94NtNdl8BceNWfsd8JBSF2YFW35Bd1SDVsNQHQV6J3gU3
Re: AW: Asynchronous writes (Servlet and WebSocket)
On 25/08/2015 17:02, Steffen Heil (Mailinglisten) wrote: Where is that implemented? The detail varies between versions due to the refactoring that has gone on over time in the connectors but in trunk that is all handled by SocketWrapperBase.writeNonBlocking() I am using 8.0.24. There I did not find such a class. The equivalent code for NIO is in org.apache.coyote.http11.InternalNioOutputBuffer Similar code exists in the other implementations for the other connectors. Generally, the trunk code should be easier to follow because of the refactoring. Will these refactorings be in the next release? No. It is too invasive to back port to the stable 8.0.x and it also requires removing support for BIO and comet which we don't want to do in 8.0.x. When is it due? 8.0.x releases are on a roughly monthly cycle. The most recent (8.0.26) was announced today. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: API requests overloading Tomcat?
On 25/08/2015 19:42, Matthew Madey wrote: I use an application called Spacewalk to manage RHEL systems in an enterprise environment. The application provides an API that I use for automation purposes. While load starts to increase on the application server, we reach a breaking point where the application becomes unresponsive, and throws 500 internal server errors. Listed at the bottom are some of the errors I see when this happens. I'm looking for advice on how to better diagnose and\or tune my settings to optimize Tomcat performance. I feel like the system is beefy enough to handle this load, but Tomcat appears to be my bottleneck.. How should I go about resolving this? I have played around with the AJP connector settings quite a bit, but can't seem to find suitable parameters. snip/ Aug 25, 2015 1:33:23 AM org.apache.jk.core.MsgContext action WARNING: Unable to send headers java.net.SocketException: Broken pipe Insufficient threads on the Tomcat side? How does max threads on the httpd side compare to the Tomcat side? SEVERE: Exception initializing page context java.lang.IllegalStateException: Cannot create a session after the response has been committed That is an application bug. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Exception using Async Servlet
On 25/08/2015 17:05, Steffen Heil (Mailinglisten) wrote: Hi I am using servlets with startAsync to be able to read and write asynchronously. However from time to time the following is logged: Aug 25, 2015 5:52:32 PM org.apache.catalina.connector.CoyoteAdapter asyncDispatch SCHWERWIEGEND: Exception while processing an asynchronous request java.lang.IllegalStateException: Calling [asyncError()] is not valid for a request with Async state [MUST_COMPLETE] at org.apache.coyote.AsyncStateMachine.asyncError(AsyncStateMachine.java:348) at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:820) at org.apache.coyote.Request.action(Request.java:378) at org.apache.catalina.core.AsyncContextImpl.setErrorState(AsyncContextImpl.java:406) at org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:332) at org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(AbstractHttp11Processor.java:1709) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:649) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1527) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1484) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) There is no code of our own involved so I am wondering if my configuration is invalid or I am using the servlet in an incorrect way. I would post some of the code we use here, but it is not really small, so where would I need to start searching or posting? Make sure you are using the latest 8.0.26 release. There have been some fixes around async dispatch. If you still see the issue then we'll need a test case (as simple as possible) that reproduces the issue for us to investigate. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8.0.23, Apache Commons 2.2: Object pool shared across Tomcat servers/clusters?
Hi, Currently in our project, we have multiple Tomcat servers running on a single physical server each having its own connection pool. We have a requirement where in, we could have a shared connection pool across multiple Tomcat servers. Hence, would like to know if any of the below is possible and how? 1. Shared connection pool across individual Tomcat instances running in same/different physical server? 2. Shared connection pool across Tomcat clusters? Again, the cluster could be on same or different physical servers. Thanks, Prarthana Agwania - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection resets without timeout
On 25/08/2015 17:34, Gregory Gerard wrote: I'm curious as well -- I ran into this too and the only work around I had was to send a heartbeat which, if the client was gone, would complete the lifecycle (server sent events in my particular case). This was ugly and felt wrong so I'd love to know the right thing to do. Test with 8.0.26 and if you still see the issue open a bug report. We have fixed something similar for WebSocket previously. [1] Mark [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=57762 On Aug 25, 2015, at 12:12, Steffen Heil (Mailinglisten) li...@steffen-heil.de wrote: Hi When using async servlets with timeout set to 0, tomcat seems not to detect, if the client closes the connection. At least the servlet listener is not notified. I expected AsyncListener.onComplete or AsyncListener.onError or AsyncListener.onTimeout, but none of these are called. The only thing called is ReadListener.onAllDataRead but that’s expected as the request is a POST request with few inbound data but long running outbound data. Now we have no way to detect when the connection to the client is broken. On TCP level the connection was closed (FIN/FIN+ACK), so tomcat should know that the connection is gone. Is there any way to get notified about that or at least to check manually? Regards, Steffen BTW: I am posting new questions that are not direct follow-ups as top messages. If there is another policy for this list, please let me know. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Problems with tomcat-connectors-1.2.41 on 32bit linux
Hi there, I tried to update the connectors to the most recent update but I am stuck with error messages. Just a few background information on the infrastructure used: httpd: 2.2.31 OpenSSL: 1.0.2.d mod_jk: 1.2.41 Kernel: 3.0.101-0.47.52-pae OS: SLES 11 SP3 (32bit) gcc: (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973] httpd configure: ./configure --prefix=/opt/apache --sysconfdir=/opt/apache/build --enable-mods-shared=all ssl ldap cache proxy authn_alias authnz_ldap dav_lock --with-mpm=prefork --with-included-apr --with-pcre --with-ldap --with-ssl=/opt/apache/openssl jk configure: ./configure --with-apxs=/opt/apache/bin/apxs configure, make and install runs without any errors. If I try to startup httpd though the following error occurs: httpd: Syntax error on line 88 of /opt/apache/conf/alles/httpd.conf: Cannot load /opt/apache/modules/mod_jk.so into server: /opt/apache/modules/mod_jk.so: undefined symbol: __sync_add_and_fetch_4 It seems to be related to the atomic changes with 1.2.41, yet I cannot figure out what I am missing here. Could anyone point me in the right direction? Regards, Falco
Asynchronous writes (Servlet and WebSocket)
Hi I am investigating, how I can archive asynchronous writes with tomcat. For servlets I came up with code like this: final AsyncContext context = request.startAsync(); final ServletInputStream input = request.getInputStream(); final ServletOutputStream output = response.getOutputStream(); ChannelProcessor processor = new ChannelProcessor( channel, input, output ); context.addListener( processor ); input.setReadListener( processor ); output.setWriteListener( processor ); While ChannelProcessor is my class that implements (beside others) WriteListener, so I get notified, when the ServletOutputStream is ready to send more data. However, looking at the code, I suspect that output.write( byte[] buffer ) will still block, if the amount of data in buffer is larger than the maximum size of the OutputBuffer used by that connection: Call stack: CoyoteOutputStream.write (is ServletOutputStream.write) OutputBuffer.write ByteChunk.append ByteChunk.flushBuffer OutputBuffer.realWriteBytes ... from here on I am not sure. For WebSockets there is session.getAsyncRemote().sendBinary( buffer, handkler ); But that calls ServletOutputStream.write (maybe from another thread) So, are these really asynchronous? Is a call to ServletOutputStream.write always guaranteed to return without blocking?` Where is that implemented? Regards, Steffen smime.p7s Description: S/MIME cryptographic signature
RE: Tomcat 8.0.23, Apache Commons 2.2: Object pool shared across Tomcat servers/clusters?
From: Prarthana Agwania [mailto:prarthana.agwa...@gmail.com] Subject: Tomcat 8.0.23, Apache Commons 2.2: Object pool shared across Tomcat servers/clusters? Currently in our project, we have multiple Tomcat servers running on a single physical server each having its own connection pool. We have a requirement where in, we could have a shared connection pool across multiple Tomcat servers. Whoever came up with that requirement is seriously confused. Underlying every database connection is a TCP/IP connection, which by definition, is point-to-point. There is no possible way for a single TCP/IP connection to be usable other than by the two end points (discounting MITM hacks). At best, you could invent a proxy machine which would connect to the DB server, and each Tomcat server could connect to the proxy. The added complication, performance impact, and overall cost make this a completely nonsensical thing to do. - 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
