Re: CVE-2012-0022 details
On Sat, Jan 21, 2012 at 9:02 AM, David Jorm dj...@redhat.com wrote: Hi All I am working on resolving the CVE-2012-0022 DoS in JBoss Web, and I wanted to confirm some details if anyone can help. Based on reading the advisory and Tomcat patch code, it seems to me that the issue is simply slow processing when a very large number of parameters is received with a request. The JBoss Web patch we implemented for CVE-2011-4858 (hash DoS) limits the number of parameters that can be passed with a request to 512 by default. With this limit in place, I am unable to reproduce CVE-2012-0022 by passing in a very large number of parameters. I wanted to check whether handling a very large number of parameters is all that is required to resolve CVE-2012-0022, or whether there is something more to it that I have missed? JBoss Web and Tomcat are separate products, and issues are often dealt with in different ways. Please do not bother the Tomcat community with issues that do not concern them. Rémy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance issue in simpleTags and tagfiles
On Wed, Sep 7, 2011 at 2:23 PM, Adrian Gonzalez adr_gonza...@yahoo.fr wrote: Hello, I've noticed a performance difference between classic Tags and simple Tags in Tomcat 7.0.21 (also tested it on 7.0.6 with the same results). Simple tags or tagfiles execution is at 5 times superior to classic tag execution. Simple tags (and derivatives) are easier to write, but are not poolable. So regular tags are best if you're going to use them a lot. Rémy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Servlet 3.0, @WebFilter and ordering
On Wed, Feb 9, 2011 at 7:46 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2011/2/8 Christopher Schultz ch...@christopherschultz.net: On 2/8/2011 4:31 AM, Stevo Slavić wrote: I don't see support for ordering in @WebFilter annotation. Am I missing something? I don't see anything that would allow an ordering to be specified. Ordering is discussed in chapters 8.2.2 and 8.2.3 of the servlet 3.0 spec. In 8.2.3 it is explicitly written: As described above, when using annotations to define the listeners, servlets and filters, the order in which they are invoked is unspecified Well, but it is still defined a bit by the ordering of the JARs. But within the JAR, the order of processing of @WebFilter is undefined, which seems quite logical to me. (If you need ordering, use a SCI or listener and add the filters programmatically) Rémy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 6.0.20 released
The Apache Tomcat team announces the immediate availability of Apache Tomcat 6.0.20 stable. This release includes many bugfixes over Apache Tomcat 6.0.18. Apache Tomcat 6.0 includes new features over Apache Tomcat 5.5, including support for the new Servlet 2.5 and JSP 2.1 specifications, a refactored clustering implementation, advanced IO features, and improvements in memory usage. Please refer to the change log for the list of changes: http://tomcat.apache.org/tomcat-6.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-60.cgi Migration guide from Apache Tomcat 5.5.x: http://tomcat.apache.org/migration.html Thank you, -- The Apache Tomcat Team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 6.0.18 released
The Apache Tomcat team announces the immediate availability of Apache Tomcat 6.0.18 stable. This release includes many bugfixes over Apache Tomcat 6.0.16. Apache Tomcat 6.0 includes new features over Apache Tomcat 5.5, including support for the new Servlet 2.5 and JSP 2.1 specifications, a refactored clustering implementation, advanced IO features, and improvements in memory usage. Please refer to the change log for the list of changes: http://tomcat.apache.org/tomcat-6.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-60.cgi Migration guide from Apache Tomcat 5.5.x: http://tomcat.apache.org/migration.html Thank you, -- The Apache Tomcat Team - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat 6.0.16 released
The Apache Tomcat team announces the immediate availability of Apache Tomcat 6.0.16 stable. This release includes many bugfixes over Apache Tomcat 6.0.14. Apache Tomcat 6.0 includes new features over Apache Tomcat 5.5, including support for the new Servlet 2.5 and JSP 2.1 specifications, a refactored clustering implementation, advanced IO features, and improvements in memory usage. Please refer to the change log for the list of changes: http://tomcat.apache.org/tomcat-6.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-60.cgi Migration guide from Apache Tomcat 5.5.x: http://tomcat.apache.org/migration.html Thank you, -- The Apache Tomcat Team - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat 6.0.14 released
The Apache Tomcat team announces the immediate availability of Apache Tomcat 6.0.14 stable. This release includes bugfixes over Apache Tomcat 6.0.13. Apache Tomcat 6.0 includes new features over Apache Tomcat 5.5, including support for the new Servlet 2.5 and JSP 2.1 specifications, a refactored clustering implementation, advanced IO features, and improvements in memory usage. Please refer to the change log for the list of changes: http://tomcat.apache.org/tomcat-6.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-60.cgi Migration guide from Apache Tomcat 5.5.x: http://tomcat.apache.org/migration.html Thank you, -- The Apache Tomcat Team - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat 6.0.13 released
The Apache Tomcat team announces the immediate availability of Apache Tomcat 6.0.13 stable. This release is the second stable release of the 6.0.x branch, and includes bugfixes over Apache Tomcat 6.0.10. Apache Tomcat 6.0 includes new features over Apache Tomcat 5.5, including support for the new Servlet 2.5 and JSP 2.1 specifications, a refactored clustering implementation, advanced IO features, and improvements in memory usage. Please refer to the change log for the list of changes: http://tomcat.apache.org/tomcat-6.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-60.cgi Migration guide from Apache Tomcat 5.5.x: http://tomcat.apache.org/migration.html Thank you, -- The Apache Tomcat Team - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat 6.0.10 released
The Apache Tomcat team announces the immediate availability of Apache Tomcat 6.0.10 stable. This release is the first stable release of the 6.0.x branch. Apache Tomcat 6.0 includes new features over Apache Tomcat 5.5, including support for the new Servlet 2.5 and JSP 2.1 specifications, a refactored clustering implementation, advanced IO features, and improvements in memory usage. Please refer to the change log for the list of changes: http://tomcat.apache.org/tomcat-6.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-60.cgi Migration guide from Apache Tomcat 5.5.x: http://tomcat.apache.org/migration.html Thank you, -- The Apache Tomcat Team - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat v6.0.9-beta
The Apache Tomcat team announces the immediate availability of Apache Tomcat 6.0.9 beta. This release is the third beta release of the 6.0.x branch. Apache Tomcat 6.0 includes new features over Apache Tomcat 5.5, including support for the new Servlet 2.5 and JSP 2.1 specifications, a refactored clustering implementation, advanced IO features, and improvements in memory usage. Please refer to the change log for the list of changes: http://tomcat.apache.org/tomcat-6.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-60.cgi Thank you, -- The Apache Tomcat Team - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat v6.0.7-beta
The Apache Tomcat team announces the immediate availability of Apache Tomcat 6.0.7 beta. This release is the second beta release of the 6.0.x branch. Apache Tomcat 6.0 includes new features over Apache Tomcat 5.5, including support for the new Servlet 2.5 and JSP 2.1 specifications, a refactored clustering implementation, advanced IO features, and improvements in memory usage. Please refer to the change log for the list of changes: http://tomcat.apache.org/tomcat-6.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-60.cgi Thank you, -- The Apache Tomcat Team - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat v6.0.2-beta
The Apache Tomcat team announces the immediate availability of Apache Tomcat 6.0.2 beta. This release is the first non alpha release of the 6.0.x branch. Apache Tomcat 6.0 includes new features over Apache Tomcat 5.5, including support for the new Servlet 2.5 and JSP 2.1 specifications, a refactored clustering implementation, advanced IO features, and improvements in memory usage. Please refer to the change log for the list of changes: http://tomcat.apache.org/tomcat-6.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-60.cgi Thank you, -- The Apache Tomcat Team - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Http11AprProtocol took 2 hr to init on http-443
On 6/22/06, Markus Schönhaber [EMAIL PROTECTED] wrote: Jeff Chuang wrote: To make port 80 use APR and port 443 NOT use APR, I have tried it several times, without any luck. After tomcat starts, port 80 is fine, but connections to port 443 are always timeout. It looks from the log the Http11BaseProtocol was not used on port 443. The log looks like: [...] I've just tried to configure a Connector which uses the Http11BaseProtocol by setting the attribute class=org.apache.coyote.http11.Http11BaseProtocol on It should actually be: protocol=org.apache.coyote.http11.Http11Protocol -- x Rémy Maucherat Developer Consultant JBoss Inc x - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: APR extensinos for Tocmat 5.5.17 cause a JVM crash on Windows OS
On 6/2/06, Stefan Baramov [EMAIL PROTECTED] wrote: Hi everyone: Tomcat 5.5.17 for Windows (distribution apache-tomcat-5.5.17.exe) comes with a DLL file called tcnative-1.dll. According to the Tomcat documentation this is a native extension based on the APR and Open SSL projects. However, the extension causes the JVM to crashes qutie often. The application is a image intense web app running on - Windows 2003 Server + SP1 - JDK 1.5.0_06 I've tried both server and client JVM's and both fails. I've tried to disable the AJP connector and still the problem was there. The problem disappears only if I remove the tcnative-1.dll from the system path. The attachment shows one of the crashes. It obviously points to the tcnative-1.dll. So can someone shed some light on this extension and problem it is causing. You're using Java2D, which as usual is doing invalid accesses to the output steam. Without APR, you would get issues like getting requests which are already committed at the beginning of the request, and other random behavior like that. The solution is to not give direct access to the Servlet API to the Java2D components (using an intermediate buffer, etc), or enable the security manager. -- x Rémy Maucherat Developer Consultant JBoss Inc x - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat as a standalone webserver. Why not?
On 6/2/06, Jim Jagielski [EMAIL PROTECTED] wrote: IMO, if you need to move out of pure Java in your Java Web Server to get acceptable performance, then why use it in the first place? Plus, if you are concerned about the security of Apache (cause it's nasty C) and therefore want to use a Java Web Server, then using JNI means you've left that warm and safe place, since you are no longer safe in a pure Java environment. Web Servers are web servers primarily, focused on HTTP, compliance, speed and capability. Use the right tool for the right job :) We know what your company recommends, thank you very much :) Do you also mean to imply that the network code in the JVM is not native, and cannot have any security problem, etc ? Using APR replaces that native code and uses the one from the ASF instead. -- x Rémy Maucherat Developer Consultant JBoss Inc x - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] LambdaProbe for Tomcat 1.5 is released
On 5/12/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I am pleased to announce the immediate availability of LambdaProbe 1.5 LambdaProbe is an Open Source (GPL) Tomcat monitoring and mangement webapp. The new release features OS memory usage, swap usage and CPU utilization monitors, support for Java Service Wrapper, which allows to restart Tomcat from a web page, user interface improvements and important bug fixes0. Very good. Most probably this is for compat with Tomcat 5.0, but the context.xml is: Context path=/probe privileged=true Logger className=org.apache.catalina.logger.FileLogger prefix=probe. suffix=.out timestamp=true/ /Context For 5.5, it can be simplified to (since the Logger element no longer exists): Context privileged=true /Context It also doesn't support my on going 6.0 development, although most likely 6.0 will remain compatible with 5.5. You could attempt to default to the most recent adapter if no obvious match is found. -- x Rémy Maucherat Developer Consultant JBoss Inc x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more trouble with 5.5.16+
On 4/19/06, Corey Kaiser [EMAIL PROTECTED] wrote: 5.5.17 beta exhibits all of the same issues as 5.5.16. 5.5.12 works just as great as 5.5.15. The differences between 5.5.15 and 5.5.16+ are fairly safe looking bugfixes (especially in Jasper, the changes are nearly non existent). IMO, you are having some setup problem causing this. You can see the changelog here: http://tomcat.apache.org/tomcat-5.5-doc/changelog.html -- x Rémy Maucherat Developer Consultant JBoss Inc x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [REPOST] Tomcat 5.5.15 - HTTPS hanging and intermittent Page Cannot be Displayed problems
On 4/3/06, Markus Schönhaber [EMAIL PROTECTED] wrote: Richard Mundell wrote: In 5.5.15 we switched to using the (ever-so-well-documented) APR native library so I suspect it's the OpenSSL code in the APR library which is causing the problem. First thing I'd try is to update to tomcat-native 1.1.2. This fixes an issue where sometimes the response was corrupted. And while you're at it: update to Tomcat 5.5.16 too. Chances are that this will help. We found a logical explanation for certain SSL request hang issues, which look similar to these ones, and the problem should now be fixed. The patch is here: http://svn.apache.org/viewcvs?rev=391288view=rev -- x Rémy Maucherat Developer Consultant JBoss Inc x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maximum number of simultaneous HTTP Requests / Performance
On 4/3/06, Tp [EMAIL PROTECTED] wrote: Hi, we have to develop a high performance chat based only on HTML and HTTP only for a television company. The biggest issue is performance. The chat's output window requires one open HTTP connection per client. This means, that when you have 3000 people following the chat that the server has to be able to handle 3000 simultaneous ie. open HTTP connections. I have read some old benchmark tests. In those Tomcat does not get a very good rating compared to other servers like JRun, BEA and others, since it does not use NIO or some native methods. I guess I could try just to open 3000 threads on my machine which write some output and see how it's doing but I guess that does not really tell me anything reliable. So I was wondering if anybody can really tell me what Tomcat's (5.5) limit is on this? How many simultaneous HTTP connections can Tomcat handle and still respond in such a way, that the application stays useable. I assume that the machine runs on a Pentium 4 3.2 Ghz with 1 GB of RAM under linux and that all the file descriptor limits are set to the maximum. The second question I have is, that lets assume the limit of a single tomcat instance is at 2000 connections, how could I use a cluster and loadbalancer to increase the total amount of simultaneous HTTP connections of the Applicaiton and this really possible? Does anybody in here have pratical experience for a live production system, which is in use and handles many HTTP connections? Neither the HTTP protocol (of course, since you control the network environment, you cannot run into trouble with proxies), nor the Servlet API have been designed to be used to do biderectional asynchronous communication and forever running service methods (what you're actually doing in that case is running your own protocol on top of HTTP), and in that case, there's no solution except using a large amount of threads. I don't know if you're aware of it, but the SIP protocol (and the associated SIP Servlets specification) has been designed for exactly this sort of usage, and using it or a similar custom protocol may be a lot better than trying to hack stuff. OTOH, OSes like recent Linux versions have no problem with lots of threads (like 5000) as long as threre are enough resources, so you could test that solution and see how it works. -- x Rémy Maucherat Developer Consultant JBoss Inc x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rephrased: Maximum number of simultaneous HTTP connections
On 4/3/06, Tp [EMAIL PROTECTED] wrote: The hype friendly continuation name has no business being associated with this particular feature, since the said feature is not continuations (which is a fancy - and IMO forward thinking and actually useful - programming model for implementing the often seen multiple HTML form wizard style process - and of course, which is going to use one HTTP request per form, as usual), and is also quite useless. What do you mean exactly by this? I guess I'm not familiar with the the topic, maybe you can elaborate a little more on this or point me to another thread about this topic. There's no topic here, obviously, as Tomcat did not introduce the term continuation. As I said, this was introduced to qualify a new programming model for wizard style processes that are often seen in web applications (registration, checkout, etc). You definitely need to think about this topic more, as the thread handling is very important for your application. If all you need is to reinvoke the service method once there's more input data available, you can just as easily use multiple small requests (over a kept alive connection), which is equally cheap in terms of processing and allows not breaking the HTTP and Servlet API designs. Well, first I hoped, that it is possible to leave the doGet() and doPost() method without the HTTP connection being closed. If that would be possible, then I could keep the HttpResponse and write to it, whenever there is new data available. The HTTP connection is kept alive during a predefined time (the socket timeout) between requests. You then need to use a Tomcat connector that doesn't use a thread to handle each connection during keepalives (such as the HTTP APR connector). This will mean all your clients will rely on frequent polling to get the new posts of you chat room, which is going to cause a fairly large load on your server. That is actually the real challenge and that's what my question is about partly. However, once the methods finish, the http connections get closed and I there is no way of preventing this. So, I have to keep the thread busy, which handles the doGet() or doPost() method in order for the connecton to stay alive. I don't understand why the connections will be closed (unless, say, the client is asking for the connection to be closed after the request), since it is not the default HTTP/1.1 behavior. You should investigate that. This is not the real problem. You can use Object.wait() and Object.notifyAll() to signal, when new data is available and then sent it over the HTTP conneciton, if you can't multiplex. If there would be a single thread I would just run through a loop and always dispatch new messages, if there are any in the queue. Yes, but you need the 5000 or so threads to do this, and there's no workaround. So it is the real problem since it forces you to use polling. -- x Rémy Maucherat Developer Consultant JBoss Inc x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rephrased: Maximum number of simultaneous HTTP connections
On 4/3/06, Leon Rosenberg [EMAIL PROTECTED] wrote: Why then using tomcat at all? What's wrong with writing own app, which listens on a socket and does whatever it has to do? Before you have to rape tomcat to perform a task it was never designed for... Yes, indeed. In many cases, it would seem all you want to do is layer some sort of custom protocol over HTTP (= use a fake HTTP request to establish the connection, and then do whatever you want; since there's control over the client and the server, parsing the HTTP artifacts will not be a problem). Tomcat (or any other high level container), the Servlet API, and maybe HTTP itself could get in the way of such usage, and a simple low level solution could be better. -- x Rémy Maucherat Developer Consultant JBoss Inc x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rephrased: Maximum number of simultaneous HTTP connections
On 4/3/06, Tp [EMAIL PROTECTED] wrote: Well, I don't know what you understand under polling. I guess you mean the clients will have to sent GET and POST requests repeately, right? The load is going to be even higher with polling. That's I would not introduce any polling. How would I do this anyway, if I only use HTML? My idea was opening a connection and then just let the client wait and sit there. Whenever I get new messages, then I will sent them over. Here a diagram: Client sends GET - Server Server sends HEADERS (Content Encoding: Chunked) - Client Server sends chunks - Client Client displays them whenever they arrive. Of course. It's the problem I was describing. The only way to do it using the Servlet model is to keep the service method running forever, since the Servlet API doesn't allow the server to write data asynchronously in response to certain events. It is actually the SIP Servlets model (which is why I mentioned it earlier). Well actually you caught me here. You are right. I mean I have tested it and after the doGet() and doPost() methods returned the connection was closed. But you are absolutely right, that this can't be a general policy and indeed depends on the keepalive timeout. So I have to check this out, it could actually be the solutions for my problem at least when it comes to saving the threads for each conneciton. I could just remember the HttpRespone Objects and use one thread, which gets, when new messages arrive in the queue. The thread then could println() them to all he HttpRespones. This would save me all the Threads. Hmm, sounds good, or have I missed somthing?! At this point, this has nothing to do with a Servlet. I know it won't work in Tomcat. Yes, but you need the 5000 or so threads to do this, and there's no workaround. So it is the real problem since it forces you to use polling. What do you mean with polling? I mean none of the threads is polling using this method, or? For example 5000 Threads would be waiting. Then a message arrives and all of them get notified and then they sent the message to the clients. So I don't see where polling comes in?! Right. I said you need to use polling, or use 5000 threads (which is not a problem if you have enough memory). -- x Rémy Maucherat Developer Consultant JBoss Inc x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rephrased: Maximum number of simultaneous HTTP connections
On 4/3/06, Tp [EMAIL PROTECTED] wrote: Remy Maucherat schrieb: But you said that the connection will not close, when the doGet() or doPost() method returns, which of course make a lot of sense. Otherwise Persistent connections would not be possible at all. So if that's true, then I should be able to write to the OutputStream of the HttpResponse at a time, when the doGet() and doPost() method has returned. Why would it not work? The connection would not close, but all the objects provided by the Servlet API are only accessible during the execution of the service method of the Servlet. For example, in Tomcat's case, these are recycled. -- x Rémy Maucherat Developer Consultant JBoss Inc x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rephrased: Maximum number of simultaneous HTTP connections
On 4/3/06, Tp [EMAIL PROTECTED] wrote: Also the reference to the OutputStream itself? I mean it should stay open until the connection closes. Are you sure? This OutputStream object is a fake facade, and loses its relationship to the actual socket at the end of the request. -- x Rémy Maucherat Developer Consultant JBoss Inc x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Tomcat provide support for PHP scripts
On 3/31/06, Bruno Georges [EMAIL PROTECTED] wrote: JBossWeb does. Soon to be released. We're distributing a package for Tomcat too, but it's not fully tested yet. http://labs.jboss.com/portal/index.html?ctrl:id=page.default.downloadsproject=jbossweb -- x Rémy Maucherat Developer Consultant JBoss Inc x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.0 vs. 5.5? tomcat 5.5 has been bad!
On 3/30/06, Markus Schönhaber [EMAIL PROTECTED] wrote: The RuntimeException is to make it more noticeable in the logs. I mean 953 hits on googling is quite alot of people having trouble. Would be nice to cut that number down with an easy log statement that tomcat could add!!! Well, if it's really that easy you should definitely provide a patch. I recommend not wasting time, as I would refuse such a nonsensical patch. The actual worakround is to learn how to properly use logging, which seems to be a useful skill. -- x Rémy Maucherat Developer Consultant JBoss Inc x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSL Using APR Connectors under Linux not working
On 3/28/06, Armand Rock [EMAIL PROTECTED] wrote: Thanks for the help...it works now...kind of... Http is no longer functioning 100% of the time (random images seem to not display anymore... getting rid of the APR changes fixes the problem... I'm going to have to take a look and see if there are any known bugs with the APR connectors under linux or if there is something else that needs to be done You should update to Tomcat native 1.1.2. -- x Rémy Maucherat Developer Consultant JBoss Inc x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.0 vs. 5.5? tomcat 5.5 has been bad!
On 3/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Anyone have much experience with running on these. On tomcat 5.5, I have ran into many problems 1. exception fron ServletContextListener.contextInitialized causes the vague error of Error listenerStart with no details. Most people on lists I have seen don't even know it was caused by Exception out of that method(Took me a while to figure out too) Yes, it's an extremely myterious log message, as a ServletContextListener is a listener for the context. 2. logging MyFaces logs was not working Whatever. 3. Facelets example war files don't work in 5.5.16 It uses a bad method for descovering its config, if I remember well, which is now fixed. -- x Rémy Maucherat Developer Consultant JBoss Inc x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Supporting maximum number of keep-alive connections
On 3/22/06, Rajeev Jha [EMAIL PROTECTED] wrote: In our case,the servlet is interfacing to the back-end that sends async events from time to time. As you may have noticed, the HTTP protocol (and the Servlet API) are not designed for this kind of usage. You can try to hack your way through if you like, but most likely you'll run into some issues with servers in between and a variety of timeouts. A protocol like SIP, OTOH, is designed for this and handles it very cleanly. -- x Rémy Maucherat Developer Consultant JBoss Inc x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TomcatProbe 1.1 released
On 3/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It is a difficult question. I wrote it because of these reasons: 1. To see how busy the datasources are and be able to reset them without server restart. I didn't get it to work (the JMX bean for the DBCP datasource was available). How is it supposed to work ? -- x Rémy Maucherat Developer Consultant JBoss Europe x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TomcatProbe 1.1 released
On 3/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: hi Remy, the probe does not use JMX to read DBCP datasources or any datasources for that matter. Did you get any error or is it the case of datasource(s) missing from the list on datasources tab? If it is the latter could you let me know how and where the datasource is declared? The datasource was missing, and was declared as a global datasource. -- x Rémy Maucherat Developer Consultant JBoss Europe x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TomcatProbe 1.1 released
On 3/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: yeah, that makes sense. If you have a context referencing the datasource in question via ResourceLink it will be displayed. Datasources declared in contexts would also be shown. Whilst we are on this subject, can global datasources be looked up by contexts without explicit ResourceLink? No, but there was a ResourceLink in the context (I don't have the war though, sorry). -- x Rémy Maucherat Developer Consultant JBoss Europe x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Testing DataSourceRealms
On 3/4/06, James Reynolds [EMAIL PROTECTED] wrote: I'm working on setting up BASIC authentication using container managed security in Tomcat 5.5.15. However, It's not working so now I'm wondering if my set up is wrong. The JNDI DataSource definitely works, I'm not so sure about the realm. Is there another way to test it? Would you mind looking at my configuration files? *Context.xml* As another said, it's indeed context.xml. ?xml version=1.0 encoding=UTF-8? Context path=/npp No path attribute. Resource name=jdbc/NppDB auth=Container type=javax.sql.DataSource driverClassName=oracle.jdbc.driver.OracleDriver url=jdbc:oracle:thin:@server:1521:SID username=scott password=tiger maxActive=20 maxIdle=10 removeAbandoned=true logAbandoned=true maxWait=-1/ Realm className=org.apache.catalina.realm.DataSourceRealm debug=99 No debug attribute. dataSourceName=jdbc/NppDB userTable=NPPUSER userNameCol=EMAIL userCredCol=PASSWORD userRoleTable=USER_ROLE roleNameCol=ROLE/ http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#DataSourceRealm localDataSource attribute: When the realm is nested inside a Context element, this allows the realm to use a DataSource defined for the Context rather than a global DataSource. If not specified, the default is false: use a global DataSource. -- x Rémy Maucherat Developer Consultant JBoss Europe x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
On 2/28/06, Tomasz Nowak [EMAIL PROTECTED] wrote: Your right, the tone of my postings is inproper. I've been using 'free' software for almost 10 years now and I pretty well get the rules. My only excuse is the level of my frustration, based on recent Tomcat use. For now, the only contribition to Tomcat community I can give is _pointing_out_ some real-world problems, that typical users of Tomcat may face (and face!). The problems are: The claims of regressions over 4.1 are completely bogus. 1. Poor/none default logging facility in 5.5.x. - no real help/tips on error sources - no examples how to do a decent virtual hosts logging - no tips how to switch off a lot of uneccesary trash log inputs If Tomcat is supposed to be production ready why it has no production ready logging features? In case you haven't noticed, it is extremely hard to do, because webapps have their own logging mechanism most of the time. You mention the logger element of 4.x, but it didn't actually do anything (it did put the internal logging for the specified container, as well as the logging done using the ServletContext - aka, the ugliest and most useless logging facility ever). Tomcat 5.5.15 and j.u.l use hierarchical categories for the containers so that you can easily replicate the logging that was done by the logger element. The default logging.properties does that for localhost. I do not consider logging.properties to be poor or bad in any way. You can also update to another, more full featured logger based on j.u.l, such as http://www.x4juli.org/. If you disagree with all this, you can use another technology as you were planning. 2. No real-world, step-by-step docs how to TRACE and eliminate application errors that lead to server failure. That is probably a problem lot of Tomcat users must struggle with. Right, you want an integrated profiler, ready to enable, and with no performance cost. I'd like to have it too. 3. During last years I see no actions taken by Tomcat dev team to eliminate Tomcat server failures caused by webaplications. Is it really impossible? It depends, on some OSes, it's apparently impossible to get a threaded server to run properly indeed. You're using Linux 2.4.something. Try updating to 2.6. If you are using Redhat or another Redhat based distros, always use LD_ASSUME_KERNEL. -- x Rémy Maucherat Developer Consultant JBoss Europe x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
On 2/28/06, Peter Lin [EMAIL PROTECTED] wrote: honestly, besides Weblogic, most servlet and ejb containers do not provide simple and clear instructions for tracing issues. With websphere, you have to buy an expensive license of WASD and even then debugging an issue won't be better in my experience. Debugging an webapp is a difficult task and very time consuming. I sympathize with you, but the only real way to trace is to use a profiler like optimizeIt, jprofiler or yourkit. An alternative would be to run tomcat with Sun's JFluid VM which is experimental. How does BEA do that ? JRockit ? JFluid could be a way (when you're not profiling, the overhead is limited), but on production servers it's still not doable as enabling profiling would kill it. Of course, memory profiling could be low impact, and would be great already. -- x Rémy Maucherat Developer Consultant JBoss Europe x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: per-webapp logging problem with Tomcat 5.5
On 2/27/06, Andreas Schildbach [EMAIL PROTECTED] wrote: Boris Unckel wrote: I have a workaround: You provide a logging.properties in your webapp. All relevant parameters are controlled per system -D properties. A workaround for what? Providing a logging.properties in my webapp is exactly what I'm trying to avoid. What's the relevant parameters, and how can I control them using system properties? I'm sorry for this lot of questions. If your workaround works, I'm happy. Otherwise, I'll take the bitter pill of customizing my webapps after deployment. I'm thinking of creating a batch in one central place that creates the configs. Either way, I plan to file an enhancement request at SUN. Logging on the server side is flawed from the beginning to the end, and I think the next servlet spec should do away with that. I'll keep this list posted. Very funny. -- x Rémy Maucherat Developer Consultant JBoss Europe x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: per-webapp logging problem with Tomcat 5.5
On 2/26/06, Andreas Schildbach [EMAIL PROTECTED] wrote: Could it be that all libraries I use go to the wrong log? All your libraries, like Spring, will use their own logger names. All these loggers are not defined in your configuration, so will all use the handlers for the root logger (.handlers). org.apache.catalina.core.ContainerBase.[Catalina].[app2.de] is only used for logging the container logs for the specified host. The documentation describes how to specify per webapp logging (with an example). You should read it. -- x Rémy Maucherat Developer Consultant JBoss Europe x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: time/date stamp differences
On 2/20/06, Tim Lucia [EMAIL PROTECTED] wrote: If you use the manager application to undeploy and redeploy (for rolling back, or for upgrading) then the old files will be removed undeploy, and the dates and times will not matter. And also: http://issues.apache.org/bugzilla/show_bug.cgi?id=33636 -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.15 Context Reloading issue
On 2/18/06, Jon Saville [EMAIL PROTECTED] wrote: I'm seeing very similar issues on reloading since 5.5.12. I posted details on the 3rd Feb, but nobody seemed that interested... http://marc.theaimsgroup.com/?l=tomcat-userm=113896054222793w=2 Question: what has changed in how log4 assets are used internally since 5.5.12? It looks like something is assuming a log4j asset is present, and doesn't like the log4j configuration being changed during a context reload. I added some code to null out certain instances, and your shared log4j setup doesn't like it (at least it's a likely possibility). Try to use a JNDI based log4j setup (or similar, using one logging namespace for all webapps is not clean), or don't share it. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UserTransaction, JOTM and Tomcat 5.5.x
On 2/11/06, Matt Raible [EMAIL PROTECTED] wrote: Just to follow up on this, the settings below work - but HSQLDB doesn't seem to support nested transactions. beginning the transaction DBTest javax.transaction.NotSupportedException: Nested transactions not suppo rted at org.objectweb.jotm.Current.begin(Current.java:233) at foo.DBTest.init(DBTest.java:30) at org.apache.jsp.test_jsp._jspService(org.apache.jsp.test_jsp:54) The DBTest class is from the JOTM + Tomcat example at http://jotm.objectweb.org/current/jotm/doc/howto-tomcat-jotm.html. Changing to use MySQL solves the problem and everything works great. Yes, I noticed hsql had that lack of transaction support, but I assumed things would work with a regular DB. I added some documentation for the Transaction element. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UserTransaction, JOTM and Tomcat 5.5.x
Since you're doing docs, META-INF/context.xml should be simplified to: Context Resource name=jdbc/myDB auth=Container type=javax.sql.DataSource factory=org.objectweb.jndi.DataSourceFactory driverClassName=org.hsqldb.jdbcDriver username=sa password= url=jdbc:hsqldb:./ Transaction factory=org.objectweb.jotm.UserTransactionFactory jotm.timeout=60/ /Context No servlet class reloading anymore (not useful to many people), and the Transaction element has all the necessary defaults since it's a special resource. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UserTransaction, JOTM and Tomcat 5.5.x
On 2/7/06, Remy Maucherat [EMAIL PROTECTED] wrote: For 1), it's simple: Resources are bound in comp/env, while the UserTransaction should go in comp. ResourceLink has a special case for UserTransaction, so it works. There's a special Transaction element which would avoid having to do that, but it's not implemented. It wouldn't be hard to add support for it in org.apache.catalina.core.NamingContextListener. Actually, I checked again and the Transaction element seems to be properly implemented, and it should be used since it will bind the UT to the right place (unlike the Resource element). It works very well for me right now. META-INF/context.xml: Context reloadable=true crossContext=true Resource name=jdbc/myDB auth=Container type=javax.sql.DataSource factory=org.objectweb.jndi.DataSourceFactory driverClassName=org.hsqldb.jdbcDriver username=sa password= url=jdbc:hsqldb:./ Transaction name=UserTransaction auth=Container type=javax.transaction.UserTransaction factory=org.objectweb.jotm.UserTransactionFactory jotm.timeout=60/ /Context WEB-INF/lib contains all the jotm JARs (and the hsql JAR). WEB-INF/classes contains the carol.properties config (the lmi protocol didn't work for me, so I switched to jrmp). So it can be packaged as a ready to run WAR. I still don't understand how that %ç!ç carol hijacks the java: ENC in its default configuration, however. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UserTransaction, JOTM and Tomcat 5.5.x
On 2/7/06, Matt Raible [EMAIL PROTECTED] wrote: Thanks Remy - this is good stuff, I didn't know about the Transaction element. Is that new in 5.5.x? Is it documented anywhere? No. It's not useful to anyone (well, almost) either. As far as the JARs location - this shouldn't matter should it? I can put it in $CATALINA_HOME/common/lib *or* in WEB-INF/lib - right? No, it does not matter. I've tried changing my context, and moving all JARs/properties local to my WAR, but it still doesn't work. Can you post your WAR for download? dropload.com works for me if you can't post it somewhere. I am not doing anything special besides what I wrote. You have all the configuration files. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session.getId() throws IllegalStateException
On 1/31/06, Blair Cooper [EMAIL PROTECTED] wrote: The following code generates an exception when getId() is called with Tomcat 5.5.15. In 5.5.7 it returned the session id. I realize that the session is being invalidated, thus valueUnbound() being called. I also realize that the servlet spec/errata says that this exception should be thrown when the session is invalid. I would contend that; at the time valueUnbound() is called the session should still be considered valid. valueUnbond is called after the session has been invalidated. In our code we need to know which session is being invalidated in order to do some cleanup. Any chance that Tomcat would be changed/fixed to not mark the session as invalid until it has finished notifying the HttpSessionBindingListeners? No (it was the same timing before, but Session.getId didn't throw an exception), but I agree the change was a very bad decision. Hacking Tomcat to remove the if (valid) is Session.getId is the way to go. Other workaround: get the session id in valueBound and store it in a field of your object. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.5.15 - does JULI required a host tag defined realm?
On 1/27/06, Boris Unckel [EMAIL PROTECTED] wrote: Hello Remy, nice to hear from you. O.K. So this problem is not solvable in JULI/x4juli. Is there a chance to initialize JUL (independently from any other backend) early enough in the bootstrap process? Second: How can we check Tomcat for correct point of log aquiring? It is as soon as the context classloader is set correctly. There are only a set number of components which can cause problems, and I think all are fine now. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is the JK Connector the definite one to use as a web connector?
On 1/17/06, Chris Mooring [EMAIL PROTECTED] wrote: Hi All, I have just read various configuration documents for jk2 and jk. It seems as though support for jk2 is no longer available. Is jk the recommended connector to use now? It seems odd...like I am using a previous version. Also, I'd still love to hear from anyone about my previous question on whether Tomcat's native HTTP server is a better option than using a setup such as IIS or Apache and a connector like JK. See my previous e-mail pasted below; Thanks, Chris Previous question on performance of Tomcat native HTTP server vs Apache/IIS and connectors. Hi All, I am trying to determine which will deliver better performance; 1) Tomcat's Native HTTP server 2) IIS or Apache with JK2 connectors If you have only one server, 1 will be faster and easier to maintain in almost all situations (proxying, even with a fairly optimized protocol like AJP, is quite expensive). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
On 1/6/06, Christian Stalp [EMAIL PROTECTED] wrote: Hello out there, I want to build a servelt which access a database. To avoid race-conditions and to realize synchronous access, I decited to make a Singe Thread Servlet. But Eclipse told me that this is no longer a usable code. So what can I do else? It's deprecated because it is confusing, but it is actually very useful performance wise in some cases, since it does pooling. I will make sure this feature remains available in the future. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing Tomcat Performance on Windows vs. Linux
On 1/6/06, Michael Czeiszperger [EMAIL PROTECTED] wrote: On Jan 5, 2006, at 6:22 PM, Remy Maucherat wrote: Sorry, for the potentially redundant question, but to clarify, is the APR version of Tomcat officially released? The last time I checked it was not. I don't care either way, but we have a policy of only testing official releases. Yes, APR enabled connectors were officially released in 5.5.12 for the first time as stable. Since the build was released, a couple annoying APR related bugs were found (and fixed in 5.5.13), though, so you might want to try 5.5.15 once it is voted stable. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
On 1/6/06, Michael Echerer [EMAIL PROTECTED] wrote: In worst case you won't even achieve what you want using single thread mode because according to the servlet specification servlet containers are free to pool servlets, if it implements SingleThreadModel. Hence you could have multiple pooled instances that be no means guarantee an synchronized access to your database in case of simultaneous requests hitting different instances. So SingleThreadModel is deprecated for good reason, since servlet spec 2.4 and also for 2.5. You are better of synchronizing yourself. Don't rely on SingleThreadModel as an easy way to get around multithreading issues. Nice, but completely wrong. STM in Tomcat uses an instance pool which allows having a minimal impact (something like 5%), and it will perform much better than syncing, unless the said sync is trivial. The reason this is deprecated is because some people thought it would solve all their syncing problems, while it doesn't address many things (like session access). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat sends certain files with missing chunks
On 1/3/06, Hasan, Nadeem [EMAIL PROTECTED] wrote: Hi all, I just upgraded our Tomcat installation on our dev box to 5.5.12 and I am seeing very strange results. Certain files are sent by Tomcat with a large hole in the middle. In the response header, it does report the size (Content-Length) correctly, but when transferring the file itself, it skips a portion somewhere in the middle. I am seeing this behaviour consistently with at least 2 files. I have a packet dump of the whole transaction that I can provide if needed. There's a dumb bug in Tomcat 5.5.12 regarding the ranges that are passed to the sendfile call, so it may fail. Either upgrade to a newer Tomcat or disable sendfile (you didn't read the APR documentation, apparently). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing Tomcat Performance on Windows vs. Linux
On 1/5/06, Michael Czeiszperger [EMAIL PROTECTED] wrote: I thought that Tomcat users would be interested to know that we just published an in-depth comparison of Tomcat performance on Windows and Linux. The articles are available here: http://webperformance.com/library/reports It describes the very different behavior of the two platforms under load, and shows there is a significant different in performance. Under the restricted conditions of the test Linux was able to handle 32% more load than Windows with identical versions of Tomcat on identical hardware. With the usage of APR in Tomcat 5.5.x, I would say the difference will be even bigger, as APR on Linux will use more efficient IO calls than on Windows. So use Linux :) (note: please, don't use any Redhat Linux 2.4s kernels, though) -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing Tomcat Performance on Windows vs. Linux
On 1/5/06, Jess Holle [EMAIL PROTECTED] wrote: Michael Czeiszperger wrote: On Jan 5, 2006, at 2:24 PM, Tim Funk wrote: Interesting. In enterprise environments, I also hear it common to see antivirus software also run on windows servers too. (Yes, you read that correctly) I'd be curious to see how much or a performance decrease there is when one is turned on. Thanks for the suggestion. I'll add that to the list for future tests. Also a Tomcat 5.5.12 (or better 5.5.15) with and without APR test against recent IBM, Sun, and BEA offerings would be really nice :-) There seems to be a silly notion out there that because you pay for commercial offerings they'll automatically make any web application run significantly faster and scale significantly better than just running it in Tomcat with the same resources. I'm not saying that paying for a commercial offering gets you nothing, but: 1. There's no reason to assume that one of the things it buys you is performance and scalability on the same server resources. 2. There's no reason to assume that anything it does buy you in these terms is significant when compared to theh performance/scalability impact of your web application's own code -- time spent optimizing your own code might buy you a lot more than the most expensive servlet engine ever could... Well, I guess you could sponsor a study from the webperformance folks to find out if you're really interested ;) -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing Tomcat Performance on Windows vs. Linux
On 1/5/06, Michael Czeiszperger [EMAIL PROTECTED] wrote: On Jan 5, 2006, at 3:39 PM, Jess Holle wrote: Also a Tomcat 5.5.12 (or better 5.5.15) with and without APR test against recent IBM, Sun, and BEA offerings would be really nice :-) We did a previous test with tomcat against those servers, and are waiting for APR to be officially released on all platforms before proceeding. There are no plans to ever release Linux binaries, if that's what you're asking for. The Windows binaries are semi official for convinience/testing only, and are statically compiled. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing Tomcat Performance on Windows vs. Linux
On 1/5/06, ALEX HYDE [EMAIL PROTECTED] wrote: Stupid question Remy but are you refering to the proces per java thread issue that had effected Linux? I am well behind the times so is this all resolved? I am soon to set-up a Tomcat server, preferably on Linux FC3 with a 2.6 kernal. Would you know whether this is suitable for running Tomcat under a reasonable load? Redhat hacked their 2.4 kernels, so they don't work well. Other 2.4 kernels will work ok, although of course scalability will most likely be not as good. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Singleton memory leak after redeploying.
On 11/30/05, Remy Maucherat [EMAIL PROTECTED] wrote: This issue also affects Hibernate. As it doesn't seem to be a Tomcat bug, but would be good to have a fix for, I've added possible workarounds for that (reflection code which sets as many static fields as possible to null in loaded classes when stopping the classloader) in the latest Tomcat code (which you need to get from SVN). It would need testing. To test this, recompile the class here and replace the original in catalina.jar (or put in in the appropriate folder under server/classes): http://svn.apache.org/viewcvs.cgi/*checkout*/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java?rev=348448content-type=text%2Fplain -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.12- APR Connector - SSL configuration
Lines 639-650 of the org.apache.coyote.Http11AprProtocol.java
// FIXME: SSL implementation
/*
if( proto.secure ) {
SSLSupport sslSupport=null;
if(proto.sslImplementation != null)
sslSupport =
proto.sslImplementation.getSSLSupport(socket);
processor.setSSLSupport(sslSupport);
} else {
processor.setSSLSupport( null );
}
processor.setSocket( socket );
*/
Whoops...
Not knowing the intimate details of how the Tomcat/APR connectors function, I
might be incorrect in my assumption, but it looks like the SSL code is in
fact commented out.
Going to post a bug for this if someone doesn't do it by the time I get
home... =D - cheers!
If you do that, I'll close it as INVALID 5 minutes later.
--
x
Rémy Maucherat
Developer Consultant
JBoss Group (Europe) SàRL
x
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slow and incomplete dynamic content generation after enabling native connector support in 5.5.12
On 11/24/05, Eric Jain [EMAIL PROTECTED] wrote: After adding the APR library to the java.library.path [as described in http://tomcat.apache.org/tomcat-5.5-doc/apr.html], certain JSPs that produce a lot of output (but used to be served in under a second) are now very slow and produce incomplete output. The header appears only after a few kilobytes of output, at which point the output is cut off... Sure. File a bug with a test WAR. Of course, it will likely end up as INVALID, since I expect this to work. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.12 + APR (Apache Portable Runtime) + SSL (OpenSSL) on Windows
On 11/17/05, Dhaval Patel [EMAIL PROTECTED] wrote: Thanks for your response Remy. But I didnt quite get it. I need help configuring SSL with Tomcat on Windows XP. I read the documentation that I found. I could not solve the problem that's why I posted on forum. I wrote what I did. How a newbie knows what is irrelevant and what is not. I think it is quite evident that the connector configuration in server.xml is important. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.12 and SSL - https doesn't work
On 11/2/05, Stanislav Mironov [EMAIL PROTECTED] wrote: Hello All! I have upgraded Tomcat to 5.5.12 from 5.5.9. Now link https://host:8443 hangs forever trying to get response and http://host:8443 returns correct plain html page without SSL. So SSL actually doesn't work at all. My server.xml related to SSL is: !-- Define a SSL HTTP/1.1 Connector on port 8443 -- Connector port=8443 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true acceptCount=100 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=conf/ssl/keystore.jks keystorePass=changeit/ Keystore file presents in right place, keystore password is correct. I create keystore this way: keytool -genkey -alias tomcat -keyalg RSA -validity 365 -keystore conf/ssl/keystore.jks Similar config file works pretty good for tomcat 5.5.9. What's happened to SSL? Nothing, it works fine. Note that if you are using APR/OpenSSL, the configuration is of course different (the APR page of the docs has the details). -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JULI ConsoleHandler custom formatter
On 11/2/05, Johnny Tolliver [EMAIL PROTECTED] wrote: I use JULI for my servlet logging and am having trouble defining a custom formatter for console handler output. An excerpt of my logging.properties file is this: handlers=org.apache.juli.FileHandler,java.util.logging.ConsoleHandler .level=INFO org.apache.juli.FileHandler.formatter = mypackage.MyFormatter java.util.logging.ConsoleHandler.formatter = mypackage.MyFormatter As expected, java.util.logging.Logger output goes to both the console handler and the file handler, but only the file handler output uses MyFormatter. It seems that console hanlder output is always formatted with SimpleFormatter no matter what. Is that expected behavior? Can it be fixed? Thanks. java.util.logging.ConsoleHandler will only load formatter classes from the system classloader. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
