Using Authentication/Authorization
Hiya, I am using Tomcat and Apache to host a simple website. I need to have some security on the site. At least to start with. Eventually I need to have security, period. :) So, following the documentation and several walk-thrus from many sources, I cannot get tomcat to cooperate. I am running Mac OS X 10.4.3 and am using Java 1.5.0, apache 1.3, and tomcat 5.5.12 and am connecting apache and tomcat with the ajp13 connector (using mod_jk version 1.2.14). At this point, I'm think I'm bypassing Apache/JKconnectors and going straight to the webapp via port 8080... When I set up the web.xml file for using, say, basic security, and then attempt to access the constrained resources, tomcat gives me the error that the requested resource is not availabe. When I remove all attempts (in the web.xml file) at security, I can access the resource just fine. I tried using the UserDatabase realm and also the MemoryRealm, but to no avail either way. Next, when I go to the default tomcat page, http://localhost:8080, and try to go to the Administrator section, it asks for my login and password. (I've configured the tomcat-users.xml file to add an admin and manager role to one of the users and restarted the server.) But when I attempt to log in, I get the error: "The requested resource (/ admin/j_security_check) is not available." I know j_security_check is the action you enter for a form authentication, but this is what came with tomcat.. nothing of my creation, so I don't think I'm the problem. This link worked on my tomcat version 5.0. I upgraded today and now it doesn't work... so now seeings how I can't seem to get security running on my webapp and I can't log in to the administration section of the server, I'm wondering if there is some funk going on out of my scope. I downloaded the binaries for mac.. maybe something is wrong? If anyone has any idea, please let me know.. I am at a total loss. Thankyou, Jess Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TID 170878 Re: How to get java process id of a user running tomcat
You have emailed Webjam Customer Support. To send a message to the intended recipient, please use their email address (if known) OR Go to their network, click on their network name (top left-hand side of the top bar) and click on the 'Contact the editor' link to send a message. Alternatively find their username within the network you both use, click on this to view their Mini-profile to 'Send message'. === > i agree with Chuck > and would add these commands for consideration on a windows box > > netstat -ano will show the pid of any java job which is tied to a tcp port > > likewise (on windows only): > > wmic process get /all /value > > is another win vista/win7/xp pro+ command > which will show all the output from all pid's > including the command line options > > or more specifically something like this: > > wmic process where "commandline like '%java%'" get commandline, processid > > hope this helps someone out there > > > > > From: "Caldarale, Charles R" > To: Tomcat Users List > Sent: Wed, December 2, 2009 9:32:18 AM > Subject: RE: How to get java process id of a user running tomcat > > > From: Pierre Goupil [mailto:goupilpie...@gmail.com] > > Subject: Re: How to get java process id of a user running tomcat > > > > " jps -mlv " will give you the PIDs of all running Java processes. Plus > > it's a part of the standard SUN JVM. > > But not for the OP, who is running an unsupported version of Tomcat on an unsupported JVM that predates the jps tool. As Pid suggested, the correct thing to do is to fix the webapp so it properly manages the threads it has started. Attack the problem, not the symptom. > > - 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. > > > -- Kind regards * * * Webjam Customer Services Webjam - your social networks made easy www.webjam.com
mod_jk retry continuing existing stream?
I have mod_jk load balancing over several back-end Java processes which embed Tomcat. When I Ctrl-C one of those processes, a server-sent-event response stream (which has already sent a number of events) does not end from a client perspective. Rather the original request is retried against the next server and its response is simply added to the original stream from the client's perspective. That is just plain weird - and doesn't make sense to me at all in terms of retry handling. Any pointers/info on this would be much appreciated. -- Jess Holle P.S. The stream is generated via async servlet request/response via Spring WebFlux/Reactor.
Re: Mod_jk/firewall configuration problems
Did you check your OS's keep alive interval and modify it if necessary? This interval has to be more frequent than your firewall's idle connection termination timeout -- otherwise setting keepalive in mod_jk does nothing for you. [This is alluded to in the docs. The details on setting this interval vary between OS'es.] -- Jess Holle Serlet Jean-Claude wrote: Sorry : that 's all i thought Hope that you don't forget to stop and restart your Apache server after modifying workers.properties Jean-Claude _ De : Greg Allen [mailto:[EMAIL PROTECTED] Envoyé : mercredi 21 juin 2006 13:37 À : Serlet Jean-Claude; users@tomcat.apache.org Objet : RE: Mod_jk/firewall configuration problems I didn't have socket_keepalive set. But I added it and still have the same problem. >From my httpd.conf: JkLogFile /var/log/httpd/mod_jk.log JkLogLevel debug # Just like workers.properties but exact line is prefixed # with JkWorkerProperty # Minimal jk configuration JkWorkerProperty worker.list=ajp13w JkWorkerProperty worker.ajp13w.type=ajp13 JkWorkerProperty worker.ajp13w.host=localhost JkWorkerProperty worker.ajp13w.port=8009 JkWorkerProperty worker.ajp13w.socket_keepalive=1 # enter the full path to the tomcat webapps directory JkAutoAlias /opt/tomcat/webapps # Mount 'testapp' directory. It's physical location # is assumed to be in the /opt/tomcat/webapps/testapp # ajp13w is a worker defined in the workers.properties JkMount /testapp/* ajp13w # Unmount desired static content from testapp webapp. # This content will be served by the httpd directly. JkUnMount /testapp/images/*.gif ajp13w JkUnMount /testapp/images/*.jpg ajp13w -- Greg _ From: Serlet Jean-Claude [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 2:35 AM To: Greg Allen; users@tomcat.apache.org Subject: RE: Mod_jk/firewall configuration problems Please give the configuration of your workers : the workers.properties.file Have you set worker.yourworker.socket_keepalive=1 in it ? Jean-Claude _ De : Greg Allen [mailto:[EMAIL PROTECTED] Envoyé : mardi 20 juin 2006 16:42 À : users@tomcat.apache.org Objet : Mod_jk/firewall configuration problems I am having a problem with mod_jk.so. I have apache set up as my web server, forwarding my jsp traffic to a tomcat server running on the same machine. This setup works fine when the client is inside of my firewall. However, when I try to access my site from outside the firewall, mod_jk does not forward the traffic to tomcat and the page is not displayed. My firewall is set up to forward port 80 traffic from outside to my web server machine. This is working, as I can get non-tomcat served pages to appear on clients outside of the firewall. I have attached the debugging log from mod_jk. In it you can see two requests - the first is from outside (which fails), while the second is from inside and you can see that it is served correctly. I'm sure this is some sort of configuration issue. But I don't know what. Can anyone point out what is wrong? Thanks, -- Greg - 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: JConsole query
Darren Kukulka wrote: HI There, Just a quick question regarding the JConsole tool we use to monitor Tomcat5 instances - 2 to be precise. We've noticed that within the Memory display window the breakdown of Heap usage shows three areas and their utilisation. The descriptions of each space differs between the servers, even though essentially they are configured identically. They are both running Tomcat 5.5.15 on a Windows 2003 Server and differ slightly with their JVM (one is running the server JVM, the other is running the client JVM). Server 1 - SUN JRE 1.5.0_06-b05 - shows "Eden", "Survivor" and "Tenured" space names Server 2 - SUN JRE 1.5.0_06-b05 - shows "PS Survivor", "PS Eden" and "PS Old Gen" space names. Can anybody explain this behaviour to me? You're getting different different generations because Java 5 is recognizing Server 2 as a server class machine -- due to heap allocation, total memory on the machine and such -- and it's not doing this on Server 1. I must admit I'm a bit confused myself about when each occurs as the documented rules don't seem to actually quite be followed. -- Jess Holle - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSP Precompilation vs. JSR-45 Debugging
I have noticed that when I use an Ant script based on that documented in the Tomcat docs to precompile all my JSPs the resulting JSPs do not support source-level (JSR-45) debugging. I thought I was doing something wrong so I looked through the JspC source code and I can't see how I could feed it anything more information. As an added complication I have an extra directory that I need in the compilation classpath. I have extended the web app classloader to handle this and added a line to the javac classpath in the Ant script. Thus things work fine in that respect but I need that to keep working -- I just want to have an option to do source-level JSP debugging as well. What am I missing? -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache 2.2 and mod_proxy_ajp
I have some vague recollection that performance of mod_proxy_ajp tested just /slightly /better than mod_jk. Tim Funk wrote: Performance (IIRC while reading on the mailing lists) is about the same. mod_proxy_ajp should be easier to configure and install since it comes bundled with apache and it should be much easier to install than jk. e wrote: Hi, I'm happy to see Apache 2.2 has been released. I'm curious if anyone has any insights into the performance of mod_proxy_ajp vs mod_jk? Is it more efficient, or just easier to configure? Are there any sample configurations available to look at? Thanks, E - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache 2.2 and mod_proxy_ajp
Chris Lear wrote: * Jess Holle wrote (02/12/05 13:53): I have some vague recollection that performance of mod_proxy_ajp tested just /slightly /better than mod_jk. But where is the information on this? It should be in Apache 2.2's doc set, but it would not surprise me at all if this were a bit sparse as of yet. I joined this list a few days ago after Googling like crazy for information on the most sensible and supported way to connect apache to tomcat (or whether to drop it and just use the http connector). In the end, I'm using mod_jk, because I couldn't find *anything* helpful on the web about configuring or using mod_proxy_ajp, apart from some theoretical examples that tended to be incompatibile with one another. The only thing people seem to agree on is that mod_jk2 is no use, though that had the option of unix sockets, which I would have thought would be a good thing. mod_proxy_ajp is only in Apache 2.2 (and the 2.1 development stream leading to 2.2) and 2.2 was just released, so obviously it is going to fairly little information about it as of yet. mod_jk2 never became stable. mod_jk is the thing for Apache 2.0, is well documented, and works fine. I might revert to using the http connector. The reasons for not doing this are: 1) I want apache to do SSL, 2) I don't want to run tomcat as root, and using local port forwarding is a hassle, and 3) there's a bit more flexibility in the apache route. The other major reason for using mod_jk or mod_proxy_ajp is load balancing from Apache over several Tomcats. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Performance degradation under load
Caldarale, Charles R wrote: This really sounds like you're not using connection pooling, but instead are opening a new connection for each request. How many do you have configured in the pool? If it's less than the number you see with netstat, that would be another indication that your app is getting its own connections rather than ones from the pool. Is your app closing the connections (and statements and result sets) properly? This usualy requires putting the close statements in finally blocks, just to make sure that exceptions don't cause them to be skipped. Additionally, you speak of multiple connections because you need to hit multiple tables. There are cases where such is all but necessary, but enough sophistication with unions, joins, etc, can reduce the number of round trips you make to the database, which can be quite important given any communication latency. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing Tomcat Performance on Windows vs. Linux
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...
--
Jess Holle
Re: Comparing Tomcat Performance on Windows vs. Linux
Remy Maucherat wrote: On 1/5/06, Jess Holle <[EMAIL PROTECTED]> 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 :-) 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 ;) :-) I guess I'm personally anecdotally convinced that the bulk of performance and scalability opportunities (for both improvement and "disimprovement") are in the web application code -- not the servlet engine code. Thinking about this a bit more, though, I guess this conviction comes from experience with really large and complex web applications. When most of the code being run is not servlet engine code, then it stands to reason that the bulk of the resource consumption would not come from the servlet engine. If someone is going hog-wild with certain tag usage styles, buffered dynamic inclusion of JSPs within tight loops, and so forth, or just has a really simple (e.g. mostly static) web application, then it would seem more likely that servlet engine optimizations could make a substantive difference. I still would not assume that current commercial offerings offer this difference when compared to the current Tomcat version, though. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing Tomcat Performance on Windows vs. Linux
Michael Czeiszperger wrote: At the enterprise level businesses pay for support, and at the highest levels of support the license the source for a product is under makes little difference to the end customer, which is why its a good business model for the likes of IBM. (Note that our own products are not open source. They would be open source if we could find a way to make a living that way.) Understood. Like I said, I'm not saying you don't get something by paying something -- it just should not be *assumed* you get better performance and/or scalability by paying something. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Oracle Jsdk 1.5
Farid Izem wrote: My Second question is : does the ojdbc14.jar will be support for jsdk1.5 and where can i download it ? ojdbc14.jar works fine under Java 5 -- it is for Java 1.4 /and higher/ as I understand it.
Re: AW: JSessionID
Conveying servlet sessions by SSL session is clearly not required by the spec, though... I'm not sure whether Tomcat supports this... Bernhard Slominski wrote: Hi, I just looked it up in the spec and there is a 3rd one as well: SSL Sessions From the Servlet spec: "SRV.7.1 Session Tracking Mechanisms The following sections describe approaches to tracking a user's sessions SRV.7.1.1 Cookies Session tracking through HTTP cookies is the most used session tracking mechanism and is required to be supported by all servlet containers. The container sends a cookie to the client. The client will then return the cookie on each subsequent request to the server, unambiguously associating the request with a session. The name of the session tracking cookie must be JSESSIONID. SRV.7.1.2 SSL Sessions Secure Sockets Layer, the encryption technology used in the HTTPS protocol, has a built-in mechanism allowing multiple requests from a client to be unambiguously identified as being part of a session. A servlet container can easily use this data to define a session. SRV.7.1.3 URL Rewriting URL rewriting is the lowest common denominator of session tracking. When a client will not accept a cookie, URL rewriting may be used by the server as the basis for session tracking. URL rewriting involves adding data, a session ID, to the URL path that is interpreted by the container to associate the request with a session. The session ID must be encoded as a path parameter in the URL string. The name of the parameter must be jsessionid. ..." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestDumperValve screws UTF-8 parameter parsing
I've produced my own servlet filter to get around this -- which does not dump request parameters until *after* the request has completed. With almost no additional effort you can then add request elapsed time, etc, etc, to this. Mark Thomas wrote: Endre Stølsvik wrote: Enabling the RequestDumperValve in both 5.5.12 and 5.0.16 (!) messes up the parsing of other-than-ISO-8859-1 incoming parameters. After using a rather huge bunch of hours, this came down as the result: when this "debug valve" is turned on, it seems to default to ISO-8859-1 when it parses and log-outputs the incoming parameters, thus also implicitly setting the entire Request-object to this enc, so any subsequnt setting to UTF-8 doesn't matter at all. At least this is true for POST paramters. For GET parameters, the situation is a little different. Here an explicit setting of URIEncoding to UTF-8 seems to work as it should, while useBodyEncodingForURI doesn't - it picks up the wrong already implicitly set encoding. (For 5.0.16 I can't seem to get the latter version to work, and have to use the explicit setting.) Sorry if my analysis doesn't hold water, but at least the bug seems to be very consistent. Regards, Endre. Which is why the following text appears in the docs for this valve: WARNING: Using this valve has side-effects. The output from this valve includes any parameters included with the request. The parameters will be decoded using the default platform encoding. Any subsequent calls to request.setCharacterEncoding() within the web application will have no effect. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: JSessionID
Bill Barker wrote: "Jess Holle" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Conveying servlet sessions by SSL session is clearly not required by the spec, though... I'm not sure whether Tomcat supports this... It doesn't (mostly because nobody has been interested enough to write the code for it). Understood. Frankly I'm not interested enough to even ask anyone else to prioritize writing such code over other the usual areas (stability/performance [not that this is bad now, mind you], servlet 2.5/JSP 2.1, etc...) -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestDumperValve screws UTF-8 parameter parsing
Endre Stølsvik wrote: On Tue, 10 Jan 2006, Oded Arbel wrote: | On Tuesday, 10 ÿÿJanuary 2006 00:06, Endre Stølsvik wrote: | > Enabling the RequestDumperValve in both 5.5.12 and 5.0.16 (!) messes | > up the parsing of other-than-ISO-8859-1 incoming parameters. | > | > After using a rather huge bunch of hours, this came down as the | > result: when this "debug valve" is turned on, it seems to default to | > ISO-8859-1 when it parses and log-outputs the incoming parameters, | > thus also implicitly setting the entire Request-object to this enc, | > so any subsequnt setting to UTF-8 doesn't matter at all. At least | > this is true for POST paramters. | | AFAIK, the catalina implementation of HttpServletRequest does not allow | to set the character set more then once, even though it doesn't do any | pre-processing of the input. | | Maybe that should be fixed instead ? I think that when you "touch" the servlet request object's parameters at all (or even anything else it might seem like), it parses them all at once using the then-set (or default) encoding and caches them. This is most probably according to spec. This is most definitely according to the spec. Then again, valves are below the level of the spec and could do things differently. The point is that this would be difficult to do efficiently at request start and so tradeoffs were clearly made. This may not have been documented right at first (I know I got burned once), but the issue has always clearly been there. I'd suggest living with it or writing your own filter. Doing such output at request end works and while I don't think such a filter can provide everything a valve can it does allow an awful lot of information to be gathered. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat integegrated with Apache
Does Tomcat now have caching of LDAP authentication (i.e. for basic authentication)? Does Tomcat allow a single web app (and URL therein) to be authenticated against multiple LDAPs (i.e. where part of the user community is defined by each)? Is there a SiteMinder plug-in for Tomcat? These sorts of things also currently drive folk to use Apache currently. -- Jess Holle Caldarale, Charles R wrote: From: Gary Blomquist [mailto:[EMAIL PROTECTED] Subject: RE: Tomcat integegrated with Apache Can you give any specifics as to why you think running Tomcat in front of Apache is bad? 1) Extra overhead. 2) Additional complexity. 3) Added points of failure. Certainly if you have a need for capabilities not supported by Tomcat (such as load balancing), then front-ending it with httpd is an inexpensive way to go. (A hardware balancer should give you somewhat better performance, but you may or may not need it.) The old httpd vs. Tomcat performance difference for static content simply isn't a factor anymore. Take a look at the study Peter Lin did: http://tomcat.apache.org/articles/benchmark_summary.pdf Note that this wasn't with the latest version of Tomcat, which has improved a bit more. - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authenticating LDAP users without their input - doable?
This is better termed NTLM authentication without a user challenge. I don't know of means of doing this with Tomcat, but I certainly don't know everything... g m wrote: I have a critical 'challenge' It is possible to authenicate on Tomcat using LDAP (Active Directory) (using MS IE browser), but, 'without' the user inputing their username and password - that is, use the cached credentials from user when they logged into the system. I have seen some applications that do this but no idea how. - Is this at all doable ? - Do I need a plugin module (or something)? - Does IE need to be configured to do this? I am using Tomcat 5.5.9 , Java 1.5, IE 6, Windows XP Really appreciate a Guru's (or two) opinion/pointer on this one. Thanks! - Yahoo! Photos – Showcase holiday pictures in hardcover Photo Books. You design it and we’ll bind it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authenticating LDAP users without their input - doable?
Jess Holle wrote: This is better termed NTLM authentication without a user challenge. I don't know of means of doing this with Tomcat, but I certainly don't know everything... I should have added that by using IIS in front of Tomcat and the IIS/Tomcat connector you *can* accomplish this, however. I just don't know of any way to do this with only Tomcat in the picture (which I think would be a good thing as getting IIS out of the picture would be a good thing!) -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: From Java to C#, ASP.NET [Off Topic]
Leon Rosenberg wrote: On 1/30/06, Endre Stølsvik <[EMAIL PROTECTED]> wrote: On Sun, 29 Jan 2006, Leon Rosenberg wrote: | On 1/29/06, David Tonhofer, m-plify S.A. <[EMAIL PROTECTED]> wrote: | > Another 2c: When doing Java, you may want to stay clear of J2EE. I have | > heard it's the Wooly Mammoth framework and I have so far worked happily | > without it. I recommend a look at Bruce Tate's pamphlet here: | > | > <http://www.oreilly.com/catalog/bfljava/> | > | | Stay clear of J2EE? Not really possible, especially with your book | recommendation, hibernate and spring are heavily J2EE based. Or did | you mean EJB? How are they "J2EE based"? JDBC is part of J2EE. JTA is part of J2EE. Servlets are part of J2EE. And spring states itself as: Welcome to the home of the Spring Framework. As the leading full-stack Java/J2EE application framework, Spring delivers significant benefits for many projects, reducing development effort and costs while improving test coverage and quality. Some app server marketeers would have you believe that J2EE == EJB and Sun has not been too vocal about correcting this. The fact is that EJBs are just the most complex piece of J2EE. App server vendors love to get you all wrapped up in them because unlike most everything else in J2EE you need a full blown app server to do them, so you have to choose one of them once you place EJBs in your solution. Given that they're the most complex, they're also a piece that some, if not many, folk truly don't need -- and a piece that has taken until J2EE 5 to get right (e.g. usable) in the spec (assuming it is finally right there). -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: From Java to C#, ASP.NET [Off Topic]
Tim Lucia wrote: Hibernate is not J2EE "based". It just so happens it provides a EJB-free solution to a servlet container environment. Hibernate does not require J2EE. Nice terminology quandry that the app server marketeers have dug for us. They've painted a world of "J2EE == EJB" and "J2EE == the only (good) way to do Java in the enterprise" and transitively "EJB == the only (good) way to do Java in the enterprise". Certainly and unquestionably one of the first two equalities is patently incorrect. I'd argue that the first is incorrect and that J2EE implies use of Java and any Java enterprise APIs that are appropriate for the problem. If somehow, none were appropriate (doubtful if one considers JDBC as both a J2SE and J2EE technology), then I'd still consider that J2EE. The problem is that by creating a clear lie in their definitions, app server marketeers have left the Java industry in a silly quandry. This affects things ranging from surveys of developers asking "Which of the following do you use? (a) J2EE, (b) .NET, ..." where developers may say "no, I don't use J2EE as I don't use EJBs" to a silly stigma against things like Hibernate both when they claim they're J2EE based (for having too much to do with EJB and app server complexity) and when they're not (for not being standards based). A fine hole dug by the marketeers... -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuning Tomcat , i need some advice
I'd ditto George's advice. Unless your page generation code is really trivial, it will be the major determining factor of your performance -- not Tomcat. Thus the first steps are general JVM tuning and application code profiling and tuning. Only after you've selected the right JVM, the right basic options, fed it enough memory, and tuned your code is it generally time to turn to further Tomcat tuning. -- Jess Holle George Sexton wrote: Database interaction is by far the major issue. In my application, a page with no db interaction runs in something like 80ms, while a page with DB interaction takes something like 350-400ms. There's no silver bullet to tuning tomcat applications, and most of the advice you'll get here won't make any difference (use this connector, instead of that). So, my advice is: 1) Using JDK 1.5. It can be up to 25% faster than 1.4 2) Use the server JVM 3) Allocate sufficient memory 4) Start tuning your application. Look at query execution times, and the number of DB Interactions per page. Reduce the number of interactions by using Stored procedure, or views. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Log4j configuration on a per context basis
This is trivial if you only introduce log4j.jar in each web app. If you share log4j.jar across web apps, then you have some LoggerRepositorySelector coding ahead of you. This is easy enough via JNDI context for cases where the contextual classloader is set for you by Tomcat, but in other cases (e.g. JMX remote request threads) you have to do such classloader setup yourself. Our web app now supports a per context log4j even if log4j.jar is shared -- in which case anything outside all the web apps goes into another log4j context. Note the log4j JMX MBeans don't support this sort of thing properly (they have a hard-wired ObjectName location for starters), so you'll have to write your own if you're interested in that aspect. Oded Arbel wrote: Guys, how can I setup log4j with a context specific configuration file ? In the past I used to put a global log4j configuration in the system classpath for the tomcat, but that is no longer appropriate in my current setup. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why use mod_jk?
If you're using Apache 1.3.x or 2.0.x, mod_jk is pretty simple overall. No, you don't want to even try in-process stuff and, yes, if you have a firewall in between Apache and Tomcat that drops idle connections you should read carefully (this is covered by the docs). The only big complaint I have is that the mod_jk docs don't make it terribly clear (or didn't last I checked) exactly how to set jvmRoute in Tomcat and how extraordinarily critical this is when doing load balancing. The Tomcat docs don't make this terribly clear either -- apart from a comment in server.xml. Most everyone I know who tries mod_jk load balancing gets hung up on this one point unless/until I give them a detailed explanation. Apart from the lack of clear/obvious information on this in the mod_jk docs (which should include it considering most folk won't think to check both mod_jk and Tomcat docs), this is actually very simple as well, though. I am looking forward to mod_proxy_ajp as it is supposed be a tiny bit faster. -- Jess Holle Brad O'Hearne wrote: mod_proxy_ajp? Yet another twist. Its just hard for me to believe that "how do I integrate tomcat and apache httpd?" is such a mystery / unknown. This seems like it would be question #1 on any Tomcat FAQ. So where can I found out more about mod_proxy_ajp. Is there a Tomcat resource which explains the configuration of it? Brad Bill Barker wrote: "Brad O'Hearne" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] After wasting time trying to configure mod_jk, I thought I'd just wipe my mind free and just play dumb for a moment. If Apache can proxy requests using mod_proxy, what is the benefit of using mod_jk as an integration technique between httpd and tomcat, if integration is *not* in-process, which I understand is not recommended for Tomcat 5.5? Actually, in-process with mod_jk is only supported (and, I use the term lightly :) for TC 3.3.x. For any higher versions it doesn't work at all. You've managed to grasp the deep, dark plan of the Tomcat developers: It is expected that people will migrate to mod_proxy_ajp with Httpd 2.2+, and mod_jk is expected to move to supporting IIS/SunOne only (and, the later only if somebody steps up with interest :). Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why use mod_jk?
Brad O'Hearne wrote: I am looking forward to mod_proxy_ajp as it is supposed be a tiny bit faster. You say you are "looking forward to mod_proxy_ajp" -- does this mean its not available yet, or you just aren't using it yet? While I am glad to learn now of mod_proxy_ajp, I guess this kind of adds to my frustration a bit -- what is the way to go now and why: mod_proxy_ajp or mod_jk? mod_proxy_ajp is only for Apache 2.2 and higher. We're still in the process of moving to 2.2. 2.2.0 seems good, though, so you could jump right to it if you don't have other issues. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why use mod_jk?
Brad O'Hearne wrote: Ok, I understand what it is trying to do here. But I assume there is a connector that has to be loaded in Tomcat to enable listening for the ajp protocol on port 8009, no? Is there documentation about this anywhere? From Tomcat's side of the connection there is no difference to speak of between mod_proxy_ajp and mod_jk. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jsp:useBean and using the same bean in a page
Hi, I am working with an app that has a lot of jsp:useBean. I have come
across an error trying to use the same id multiple times in the same page. I
understand from the JSP syntax reference that this is valid and it should
just reference the original bean on any subsequent calls. Here is the
reference I am using:
http://java.sun.com/products/jsp/tags/11/syntaxref11.fm14.html
The error basically implies that I cannot use the same bean twice on a page.
I get the error key 'jsp.error.useBean.duplicate'. I check the code
org.apache.jasper.compiler.Validator:515. It uses the BeanRepository to do
'checkVariable', which has this code:
public boolean checkVariable (String bean) {
// XXX Not sure if this is the correct way.
// After pageContext is finalised this will change.
return (checkPageBean(bean) || checkSessionBean(bean) ||
checkRequestBean(bean) || checkApplicationBean(bean));
}
It doesn't seem to me that this is the correct way because I cannot use the
same bean twice in the same page. Please let me know if I am wrong about
this. Thanks.
Jess
(Please CC replies to me in 'cc' address as I am not on the list, thanks)
Stack trace:
org.apache.jasper.JasperException: /my.jsp(4,0) jsp.error.useBean.duplicate
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.
java:39)
org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:405
)
org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:100
)
org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:51
6)
org.apache.jasper.compiler.Node$UseBean.accept(Node.java:1116)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: The problem i have met
Hmmm There must be some special pitfall you folk are hitting that I don't even see... I am using log4j in my web app (quite extensively) and see loads of log messages. Could this be an odd combination of including log4j and trying to use java.util.logging? That should work (and the Tomcat dev folk know a reason it should not then they should fix this as there are cases where a library in your web app insists on one logging approach and another library on another...), but I do not do this myself -- I stick to log4j logging which is why I include log4j. Come to think of it, I seem to recall having issues getting java.util.logging output from Tomcat when I tried it once [from a low-level library where I wanted no commons or log4j dependencies]. -- Jess Holle Dean Hiller wrote: this problem didn't have much to do with having servlet knowledge so I am confused here. It had to do with setting up logging for servlets which AFAIK, they don't teach in a servlet tutorial, so if you knew servlets, it was not enough :( just as in my case. dean David Delbecq wrote: Jay a écrit : I am pretty new to tomcat. I recently read a post http://marc.theaimsgroup.com/?l=tomcat-user&m=114372017420869&w=2 which solved a problem I have been having for tomcat 5.5 also. I thank that person for posting the solution. I also read some of the responses from what appear to be the tomcat developers and was very dissappointed. I also think that is a usability problem for newbs. like tomcat team wants tomcat to only be usable for advanced users to me. This frankly dissapoints me. I think tomcat doc just aims at people having minimum knowledges background in java, servlet, j2ee specs. Teaching this background knowledge is in no point the purpose of tomcat docs. Thought the docs is not always complete, it generally provide enough information to do what you need to do, once again assuming you have that background knowledge. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Applet sharing utility class with Servlet
This is a "feature" of the servlet spec. To use a class from both client and server you're forced to have multiple copies of it in your web app -- or alternatively to do non-standard adjustments to the web app loader / classpath. If you don't have too many of these copy cases, I advise just having your build process produce the necessary copies. Unfortunately, some of us have *lots* of these cases. The lack of a "common" area which is accessible to client and server classloaders is a very unfortunate gap in the servlet spec in this case. Andrew Bubnic wrote: Hi guys, hoping someone has an answer to this: I have a servlet and an applet running in the same webapp. The servlet needs to access a class the applet .jar contains. The applet is visible to the browser. Problem is: I need to access this applet utility class (or it could be any class really, outside the WEB-INF folder but inside the current webapp) from the servlet. I don't want to actually access the running applet on the user's end, just the .class on the server webapp (so I can instantiate it etc). I also don't want to have to keep a copy of this utility class with the servlet class as a work-around as it's rather inelegant. I have heard you can modify web.xml in the webapp\WEB-INF folder to allow access to any .class/.jar in the current webapp but I haven't been able to find how to do this. If you have any ideas or leads about this problem, please let us know. Thanks guys. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.5, java 6 and jconsole not working as service
Tomcat 5.5.20 runs fine with Java 6, though I'm not sure if I tried it as a service. Martin Dubuc wrote: I haven't been successful running Tomcat on Java 6. My guess is that Tomcat can't run yet on Java 6. Martin On 1/9/07, teknokrat <[EMAIL PROTECTED]> wrote: I am running Tomcat 5.5 as a service using Java 6. I try to connect jconsole locally but it can't seem to find tomcat. Anyone know how I can do this? thanks - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: Tomcat Log4j Log Level Configuration
Paulo Alvim wrote: Hi Jojo, I'm with the same problem: I'd like to change the "log level" e also the "appender configurations" without redeploy my war (my log4j.properties file is bundled into the web-inf/classes)... This is a major failing of the WAR format as I see it. You have to redeploy everything to change anything but the deployment descriptor. That seems less than realistic for a large web application. I have thought about a few - not very good - approaches (of course the best one would be an "out-of-box" solution): - I was wondering if I could change the log level by programming against Log4j memory beans...have you already tried that? I have already done this kind of configurations with Java code to initialize the appenders and levels, but I'm not sure if there are performance or "thread safe" issues related to modified them "on fly"... Do you mean log4j management bean (MBeans)? If so, there are issues with these and use per-web-app logging repositories. I wrote my own MBeans for log4j to get around this and many other issues I encountered with the bundled MBeans. [My MBeans allow me to create a separate branch of MBeans for each log4j LoggerRepository, e.g. one per web app and one for the default LoggerRepository as well if one configures Tomcat itself to use log4j as well.] - Try to put my log4j.properties out of the war (something like "each war's log4j file into subdirectories of Tomcat's log directory"). This would also require app code to "reload" log4j configuration - I don't know if it's possible... This is doable. You could have JNDI environment entries in your deployment descriptor (your Context XML) calling out the location of your log4j properties (or XML) file. You can then have a thread watch this for changes and reapply the config file on the fly when changes are noticed. log4j has functionality for this, but it is problematic in that you can't cleanly close down the threads on web app shutdown, etc, so you're better off writing your own (or using log4j 1.3, which supposedly fixes this but is in alpha...) - Manage log4j configurations as JMX beans...I'm not using JMX in depth but it seems that I'd be able to modify the configuration this way. Oh, so you meant something else above. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authenticating with LDAP against multiple organizational units
My guess is that you need to direct the LDAP URL at the ADS "global
catalog", which oddly enough is not on port 389...
Brian Bonner wrote:
We're having a problem authenticating with Tomcat 5.5.9 against
multiple organizational units. Our LDAP server is Active Directory.
Here's our current setup:
ldap://ldapdc.thf.net:389";
userBase="dc=thf,dc=net"
userPattern="|((cn={0},ou=Users,dc=thf,dc=net)(cn={0},ou=THFUsers,dc=thf,dc=net))"
userSearch="(cn={0})"
userSubTree="true"
userRoleName="memberOf"
roleBase="cn=Users,dc=thf,dc=net"
roleSearch="(member={0})"
roleName="cn"
connectionName="cn=SecuredUser,cn=Users,dc=thf,dc=net"
connectionPassword="sample"
roleSubtree="true"
/>
When we search using this criteria, we see the following in the log:
CA 2005-10-17 11:16:31,283 Thread-1 DEBUG
org.apache.catalina.realm.RealmBase - Register Realm
Catalina:type=Realm
CA 2005-10-17 11:16:44,767 http-8080-Processor25 DEBUG
org.apache.catalina.realm.RealmBase - Checking constraint
'SecurityConstraint[Secured Pages]' against GET /secured/test.html -->
true
CA 2005-10-17 11:16:44,767 http-8080-Processor25 DEBUG
org.apache.catalina.realm.RealmBase - Checking constraint
'SecurityConstraint[Secured Pages]' against GET /secured/test.html -->
true
CA 2005-10-17 11:16:44,767 http-8080-Processor25 DEBUG
org.apache.catalina.realm.RealmBase - User data constraint has no
restrictions
However, instead, I'm prompted with the authentication form and asked
for my userid/password.
Can someone suggest what I might be doing wrong in this configuration,
or how I can enable additional logging to tell me what is failing?
Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: IIS security with tomcat
Sounds like IIS should be doing your authentication...
Steve Gaunt wrote:
Hi
I have IIS web server servicing static pdf/html content. However, I only want to allow access to these if they have been authenticated by tomcat(using jk2 connector on the AJP connections).
I dont want to move these static pdf/htmls' onto tomcat(as the folder(s) size at the root is over 10G). I've tried this and after about 10 hours of use, the tomcat website hosting the static content fails.
Ideally, the static conent should be serverd by IIS(as its good at doing that).
But I dont want just anyone being able to view these?
I've tried the response.sedREdirect("")
and passing the "www-authentication" into the header, but since the redirect
goes back to the browser and rewrites the header, this info is lossed.
HAs anyone else had similar problems ebfore??
STeve
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: IIS security with tomcat
That does not sound particularly doable to me.
I'd assume that you'd want to look to the latest Tomcat 5.5.x for the
best static file handling you can get out of it and essentially take IIS
out of the picture.
--
Jess Holle
Steve Gaunt wrote:
HI
That;'s what i'm trying to do.. But the user credentials are held within a database.
Ideally, I want to forward to tomcat, do the login for the user, and somehow tell IIS all static conent from the session(or user) is allowed. Equally, I dont want the users to bookmark the pdf/html files(as these people pay to see them).
I'm not sure how to do this with the web server, surely there must be a
standard way of achieving this. I've searched google but unable to find
information about this.
Cheers
-Original Message-
From: Jess Holle [mailto:[EMAIL PROTECTED]
Sent: Mon 17/10/2005 20:34
To: Tomcat Users List
Cc:
Subject: Re: IIS security with tomcat
Sounds like IIS should be doing your authentication...
Steve Gaunt wrote:
>Hi
>
>I have IIS web server servicing static pdf/html content. However, I only want to allow access to these if they have been authenticated by tomcat(using jk2 connector on the AJP connections).
>
>I dont want to move these static pdf/htmls' onto tomcat(as the folder(s) size at the root is over 10G). I've tried this and after about 10 hours of use, the tomcat website hosting the static content fails.
>
>Ideally, the static conent should be serverd by IIS(as its good at
doing that). But I dont want just anyone being able to view these?
>
>I've tried the response.sedREdirect("")
>
>and passing the "www-authentication" into the header, but since the
redirect goes back to the browser and rewrites the header, this info is lossed.
>
>HAs anyone else had similar problems ebfore??
>
>
>
>STeve
>
>
>__
>This email has been scanned by the MessageLabs Email Security System.
>For more information please visit http://www.messagelabs.com/email
>__
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: LDAP connections pool
It's quite possible via Apache... If it is not possible via Tomcat than this would be one of those reasons to use Apache as a web server. Javier wrote: Con fecha Tuesday, October 25, 2005, 3:16:43 PM, escribió: If you mean pooling with JNDIRealm - there is no pooling available with that realm. Tim Thanks for your reply. I've an LDAP directory and my application will validate users. As far as I know there will be a lot of connection operations I'm looking for a method to have a number of opened connections that could use to validate users. Something similar to a DB pool. Is this possible ? Thanks in advance Javier
Re: NIO/Large-scale pushes to browsers/Jetty 6 Continuations
Oscar wrote: We used BlazeDS's publish/subscribe feature to implement server-side PUSH. However, we found it didn't work well with NIO, CPU wasn't stable, What's even worse, CPU will constanly be 99.9%. The system worked well with APR. Is this just with Tomcat or did you investigate with something Grizzly based as well? I've always wondered whether NIO was the issue on various reports or just Tomcat's implementation thereof [and find the notion of native libraries for something that /should/ be a Java core competency irksome -- but perhaps that's the current reality]. -- Jess Holle
Precompiling .tag files containing Java 5 syntax?
Tomcat's JSP precompiler does not seem to be able to handle tag files containing Java 5 syntax -- it acts as if it were in "-source 1.4" [or "-source 1.3", we don't use asserts much] mode. Is this a known issue? Is there something to be done about this? I'm doing: where jasper2 is taskdef'ed to org.apache.jasper.JspC. sourceVer and targetVer are both 1.5. And, yes, of course, my specifies target and source versions as well ala: [Note the Tomcat docs should be updated to state that encoding="UTF-8" should be used as that's the default output of JspC and /not/ the default input of ...] Am I missing something here? Note that the tag files in question work fine at runtime -- they just won't precompile. -- Jess Holle
Invoking JSP/servlet from non-request thread?
I want to invoke JSPs/servlets from non-request threads, e.g. to render HTML for use in e-mails, etc. I tried the simple-minded approach (with Tomcat 6.0.18): ServletContext servletContext = MyContextMonitor.getContext( "/myContextName" ); RequestDispatcher dispatcher = servletContext.getRequestDispatcher( "/somePage.jsp" ); dispatcher.include( new Request( servletContext ), new Response() ); where Request and Response are mock HttpServletRequest and HttpServletResponse implementations. Response's output stream and writer are routed to System.out. I get the dispatcher fine. I get output if I use "/somePropertiesFile.properties" in place of "/somePage.jsp" -- but only if I use include(), not forward(). I don't get output for /somePage.jsp in either case. Any ideas? Anyone /successfully /doing this sort of thing? Is there an existing library for this that I'm overlooking? It seems really bizarre that for all the time and energy invested in servlet and JSP based HTML page generation that there's not a standard bridge to using servlets and JSPs from other threads to generate HTML files, e-mails, etc. -- Jess Holle
Re: JspC woes in Tomcat 6 (Urgent)
Try something like Dola Woolfe wrote: Hi, Just upgraded my Tomcat from 5.5 to 6.0 and noticed that my JspC task in build.xml is no longer working. The documentation for 6.0 quote is below, but with 6.0 there seems to be no such thing as server/lib and common/lib, so something is not right. Could someone plese tell me how to fix this? Thanks, Dola - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Session Replication question
I read the cluster how-to regarding. I'm still not clear on a couple of details if is just using DeltaManager and SimpleTcpCluster: 1. If useDirtyFlag is false, I assume that the session is entire replicated after each and every access. Is this correct? 2. If useDirtyFlag is true, are only the pieces of the session that were changed (via setAttribute(), removeAttribute(), etc) sent throughout the cluster? * Or is this a separately configurable option? If so, when one calls setAttribute() and/or removeAttribute multiple times on the same attribute during the same request, are the duplicate events/deltas coalesced? I'm just trying to understand the behavior and capabilities of the clustering a bit better. I naively expected to find replication only when setAttribute(), removeAttribute() or the like are called /and/ that these changes would be coalesced into a minimalistic delta that would then be pushed to other nodes in the cluster (with a separate timestamp on each attribute if necessary). -- Jess Holle
Re: Limit the number of concurrent users
You can easily do this sort of thing with a session listener -- and the code will be relatively portable across servlet engines, etc. -- Jess Holle Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mel, Woodgett, Mel (MSFC-NNM04AA02C)[STEEPLE] wrote: Let me rephrase my question. What's the best way for me to set tomcat up in way to where I can restrict the total number of concurrent users? Is this possible right out of the box with tomcat or do I have to use Apache with tomcat? Do you mean limit the number of concurrent users, or the number of concurrent connections? Filip has answered the latter, but it sounds like you want to limit /users/ -- basically, the number of active sessions. If I'm right, then this has nothing to do with Apache httpd and your solution will be entirely Java-based. You will have to do it yourself because Tomcat has no such capability (and neither does Apache httpd for that matter). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHF9Wi9CaO5/Lv0PARArMFAKCWWv8q4PKTr6lpN3sen5f87etU9gCeOCT2 +nlUCrOUEQglP4fVRNLDajk= =eG6c -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JConsole port
Yup. David kerber wrote: I guess the deafening silence in response to this question must mean that there's no standard port, and I can use any port I feel like... D David kerber wrote: Is there a standard (either de facto or formal) port to use for jmx when monitoring a tomcat app with jconsole? If so, what is it? D - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invoke JSP on tomcat startup
Sounds like you want a ContextListener, not a JSP... Andrew Hole wrote: Hello! Exists some automatic way to invoke a JSP when tomcat starts? Thanks a lot - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpSessionActivationListener not getting called in the Tomcat 5.5.20 clustered mode.
The HttpSession activation and passivation listeners in Tomcat are /quite/ broken -- at least last time I checked. I've been in the habit of patching this part of the code. I submitted a patch once, but I mixed in a few other things that were broken in this area and it was not accepted -- and I've not taken time to slice up my patch into many smaller ones so they can be individually rejected :-) [The above may sound bitter -- I'm not. I just don't have the time to spoon feed patches, especially since I'm ending up patching the same file anyway to address persistent session handling.] Giancarlo Frison wrote: I had faced the same problem, in order to 'activate' a deserialized object coming from an other VM the session object has to implement the HttpSessionBindingListener interface, not the *HttpSessionActivationListener* . The valueBound method is invoked by setAttibute's HttpSession method, inside there you would initialize and populate the transient fields. Hello I am using a *tomcat* *clustered* environment using two *tomcat* *5*.*5*.*20* servers *in* *the* Windows machine. I am using *the* *in*-memory replication for replicating *the* session. *In* my code, I have a session attribute that implements *HttpSessionActivationListener* *interface*. I expect this Listener to be *called* when *the* session gets replicated on *the* other server. I see that *the* session gets replicated but *the* Listener is *not* *getting* *called* at all. I require this listener to be *called* so that I can *initialize* some of *the* transient session attributes when *the* session is created on one *tomcat* *instance* but *the* next request goes on *the* other server. Can you please let me know why *the* *HttpSessionActivationListener* is *not* *getting* *called*? Is *there* something which I am *not* doing correctly? - 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: HttpSessionActivationListener not getting called in the Tomcat 5.5.20 clustered mode.
I sent the patch quite some time back now, so I'm not sure where it is.
Being similarly lazy I'm attaching an excerpt of the patched
StandardSession.java (from 5.5.23) with changes embedded in it.
Mark Thomas wrote:
Jess Holle wrote:
The HttpSession activation and passivation listeners in Tomcat are
/quite/ broken -- at least last time I checked.
I've been in the habit of patching this part of the code. I submitted a
patch once, but I mixed in a few other things that were broken in this
area and it was not accepted -- and I've not taken time to slice up my
patch into many smaller ones so they can be individually rejected :-)
I'm being lazy - can you point me towards your patch. I've looked at this a
couple of times and I thought we had it working correctly. If there is
still work to do I will take a look.
Mark
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
/**
* Perform the internal processing required to passivate
* this session.
*/
public void passivate() {
// Notify interested session event listeners
fireSessionEvent(Session.SESSION_PASSIVATED_EVENT, null);
// Notify ActivationListeners
// changes from here on
Context context = (Context) manager.getContainer();
Object listeners[] = context.getApplicationLifecycleListeners();
if (listeners != null) {
HttpSessionEvent event =
new HttpSessionEvent(getSession());
for (int i = 0; i < listeners.length; i++) {
if (!(listeners[i] instanceof HttpSessionActivationListener))
continue;
try {
((HttpSessionActivationListener)listeners[i])
.sessionWillPassivate(event);
} catch (Throwable t) {
manager.getContainer().getLogger().error
(sm.getString("standardSession.sessionEvent"), t);
}
}
}
}
/**
* Perform internal processing required to activate this
* session.
*/
public void activate() {
// Notify interested session event listeners
fireSessionEvent(Session.SESSION_ACTIVATED_EVENT, null);
// Notify ActivationListeners
// changes from here on
Context context = (Context) manager.getContainer();
Object listeners[] = context.getApplicationLifecycleListeners();
if (listeners != null) {
HttpSessionEvent event =
new HttpSessionEvent(getSession());
for (int i = 0; i < listeners.length; i++) {
if (!(listeners[i] instanceof HttpSessionActivationListener))
continue;
try {
((HttpSessionActivationListener)listeners[i])
.sessionDidActivate(event);
} catch (Throwable t) {
manager.getContainer().getLogger().error
(sm.getString("standardSession.sessionEvent"), t);
}
}
}
}
-
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: HttpSessionActivationListener not getting called in the Tomcat 5.5.20 clustered mode.
I believe similar changes were still necessary in 6.0.14 as well (and previously were needed in 5.0.30). Jess Holle wrote: I sent the patch quite some time back now, so I'm not sure where it is. Being similarly lazy I'm attaching an excerpt of the patched StandardSession.java (from 5.5.23) with changes embedded in it. Mark Thomas wrote: Jess Holle wrote: The HttpSession activation and passivation listeners in Tomcat are /quite/ broken -- at least last time I checked. I've been in the habit of patching this part of the code. I submitted a patch once, but I mixed in a few other things that were broken in this area and it was not accepted -- and I've not taken time to slice up my patch into many smaller ones so they can be individually rejected :-) I'm being lazy - can you point me towards your patch. I've looked at this a couple of times and I thought we had it working correctly. If there is still work to do I will take a look. Mark - 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 memory leak?
I missed the JSP -- did it disable sessions?
If not, then the most common way to cause such an issue is to use a test
harness that does not understand/preserve cookies between hits and thus
produces a different session for each hit. Empty sessions are small,
but do add up over time and choke the process. In that case the problem
is /almost/ purely one of testing methodology in that the test harness
should simulate realistic usage. I say /almost/ in that there is some
DOS prospect here -- and thus you may wish to require authentication
prior to establishing a session, for instance...
--
Jess Holle
Leon Rosenberg wrote:
i downloaded the war file and put it info webapps (it was the only webapp )
started tomcat (5.5.17)
started following in another shell:
while true; do wget "http://localhost:8080/LoadTest/something.jsp"; ; done
canceled after some thousands of iterations
i checked the memory usage via activity monitor (macosx) and tomcat
manager app. Both showed no changes.
Could it be that your python lib is keeping connection or something?
Have you checked via tomcat maanager how many connections you actually
have?
regards
Leon
On Jan 24, 2008 4:31 PM, Ofer Kalisky <[EMAIL PROTECTED]> wrote:
That's what I'm saying, I've been sitting on this for two days and can't
figure it out.
Do you mean to say that you tried it and even when accessing the JSP with
the script - your memory stays low? What am I doing wrong then?
Please notice the tomcat version and the JRE version I stated (6.0.14,
jre1.6.0_03).
One more thing: as I said, I'm trying it with 64M of max heap space, but I
figured, if it goes to 99.9% mem use, there's no use raising it (even though
I tried and it reached 99.9% after a short while)
Ofer.
- Original Message -
From: "Leon Rosenberg" <[EMAIL PROTECTED]>
To: "Tomcat Users List"
Sent: Thursday, January 24, 2008 5:25 PM
Subject: Re: Tomcat memory leak?
I downloaded your example.
So you are telling us, that simply calling a JSP file with html markup
only and without any code kills your tomcat?
Regards
Leon
On Jan 24, 2008 4:19 PM, Ofer Kalisky <[EMAIL PROTECTED]> wrote:
Ok, since sending an attachment doesn't work,
simply create a webapp by the name of LoadTest and create two files
inside:
something.jsp and something.html
the content of both files should be:
try the load.py with both:
import httplib
i = 0
while 1:
conn = httplib.HTTPConnection("localhost:8080")
conn.request("GET", "/LoadTest/something.jsp")
r1 = conn.getresponse()
if (i % 500 == 0):
print i
i = i + 1
conn.close()
sorry for any inconvenience
Ofer.
- Original Message -
From: "Ofer Kalisky" <[EMAIL PROTECTED]>
To: "Tomcat Users List"
Sent: Thursday, January 24, 2008 5:08 PM
Subject: Re: Tomcat memory leak?
I think the mailing list blocks war files...
trying with zip...
- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tomcat Users List"
Sent: Thursday, January 24, 2008 5:00 PM
Subject: Re: Tomcat memory leak?
Good Morning Ofer
I dont see attachement of /LoadTest/something.jsp
Martin-
- Original Message -
Wrom: FPEGAUTFJMVRESK
To: users@tomcat.apache.org
Sent: Thursday, January 24, 2008 9:51 AM
Subject: Tomcat memory leak?
Hi,
I know it's weird, but I'm doing the simplest thing and can't believe
there such a leak that I'm the first one to notice. I bet it's my bad,
please someone explain, what I'm doing wrong...
I created the simplest JSP and when I load test it - tomcat (6.0.14,
jre1.6.0_03) goes to 99.9% memory use in a few minutes (If I raise the
max
heap size it takes longer, but it happens several minutes afterwards),
and
when I stop bombarding it, it doesn't return to the usual percentage.
When I try the same with an HTML instead of a JSP, that returns
exactly
the same - it stays on 12%-20%, cleans with the garbage collector, and
returns to the usual percentage (about 12%).
I tried profiling with several plugins and external programs, but I
really
can't understand what's going on. They tell me that most of the
allocated
bytes are "char[]", but I'm not sure who's the allocator and if there's
anything I can do about it...
Attached are:
1. a test in python that bombards the tomcat,
2. a war with both something.jsp and something.html (they are both the
same, but when I bombard something.html everything is ok, and when I do
the
same for something.jsp - the problem occurs)
Can anyone tell me what I'm doing wrong? does it happen to you too?
Thanks, Ofer.
--
Re: Internal Tomcat4/jk2/apache2 timeout after lengthy servlet processing?
jk2 is unsupported and its usage is highly discouraged. All the good stuff from jk2 was ported to later mod_jk and mod_proxy_ajp releases. Thus grab and use the latest mod_jk if you're on Apache 2 or use mod_proxy_ajp on Apache 2.2. mod_jk's timeout is infinite by default, but for mod_proxy_ajp you have to set this to a large value explicitly. -- Jess Holle Pablo Barrón wrote: Hi!!! I've run into a configuration problem in a Tomcat4/jk2/Apache2 server (Debian Sarge 3.1), in which Java servlets are running to generate the webpages. There are some operations that need quite a lot of time of processing without user interaction (like, sending a newsletter to thousands of addresses, or uploading a huge zip and processing photographs inside), and I noticed that after such operations, the server would not send the result webpage to the client browser, even though there is no problem at the java level; all operations conclude succesfully. I made a test java class, which just waited for some time and generated a webpage in the end. So, I could verify that when these internal operations last more than 5 minutes, the browser gets no answer. If less time is used internally by the servlet to execute, the webpage is sent without any problems. Now even though the browser would not receive anything, operations were completed succesfully. I could read my debug printing in the log4j logs, and as well sending the newsletters or uncompressing zip files were successful operations. My idea then is that the problem might belong to the Apache and Tomcat intercommunication, or be a Tomcat timeout to Apache2 (?). If it was a client-server timeout, I guess then the browser should have alerted me, but Firefox (and IE for that matter) just looked as if it was waiting for something. Meanwhile, the tomcat classes logs would tell me that the operations were finished, as in normal operation. The closest I've seen to the more or less 5 minutes timeout I saw was the "Timeout" field in apache2.conf, which was 360 seconds. I've tried putting that to a high number. I've tried as well to put a huge timeout into the IfModule directives; prefork, etc. (Well I think the problem is in the Apache2 - Tomcat4 communication but I've tried almost any parameter I could find, just in case) I've tried as well to modify the workers2.properties file (for which the documentation is not really clear and some pages in jakarta give 404's, but I'm afraid I have to stick with jk2), like this: [workerEnv:] info=Global server options timing=0 debug=0 soTimeout=360 serverTimeout=360 timeout=360 and like this: [channel.socket:localhost:8009] info=Ajp13 forwarding over socket debug=0 tomcatId=localhost:8009 soTimeout=360 serverTimeout=360 timeout=360 I've modified as well /etc/tomcat4/server.xml; I've put "0" -and -1 to test- in the "connectionTimeout" value in the 8009 port AJP 1.3 Connector, and "disableUploadTimeout" to "true". I've done the same to 8180's Coyote HTTP/1.1 Connector. No results, so I'm really out of imagination, and I've been unable to find any more suggestions in the available documentation. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
%3B in path-info
We have some servlets that take rather general path-info's. When these include a /properly escaped /semicolon, invoking getPathInfo() in Tomcat results in a truncated path info. Is this a known bug? For example, one might have the request http://myhost/mywebapp/servlet/myservlet*/pathcomp1/pathcomp2/foo%3Bbar*?spaz=bot The expected result of getPathInfo() is /pathcomp1/pathcomp2/foo%3Bbar The actual result in Tomcat is: */pathcomp1/pathcomp2/foo * Note that the %3B is already converted into a ";" character in the results of getRequestURI()... This certainly would appear to be a bug in /something/. Or is this a bug or misconfiguration in mod_proxy_ajp or some such? -- Jess Holle
Re: %3B in path-info
You're right -- this works fine in the direct case. So I need to file a bug against mod_proxy_ajp instead? Or is there some chance this is in the AJP connector? Rainer Jung wrote: So are you saying, that th request goes through httpd/mod_proxy or mod_jk? If so, you should first test with direct request, so that we know, where we have to look for the problem. With mod_jk there were a couple of encoding changes and the latest versions without a forwarding JkOption I think decodes the semicolon before forwarding, because the AJP connector does not decode before looking for the jsessionid. Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: %3B in path-info
Is there any reasonable way I can tell where the issue resides, mod_proxy_ajp or the Tomcat AJP connector. I'm using Apache 2.2.8 and the Java (non-native, non-NIO) AJP connector. [The native connector is just too painful to build on half a dozen platforms...] Jess Holle wrote: You're right -- this works fine in the direct case. So I need to file a bug against mod_proxy_ajp instead? Or is there some chance this is in the AJP connector? Rainer Jung wrote: So are you saying, that th request goes through httpd/mod_proxy or mod_jk? If so, you should first test with direct request, so that we know, where we have to look for the problem. With mod_jk there were a couple of encoding changes and the latest versions without a forwarding JkOption I think decodes the semicolon before forwarding, because the AJP connector does not decode before looking for the jsessionid. Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: %3B in path-info
Mark Thomas wrote: Jess Holle wrote: You're right -- this works fine in the direct case. So I need to file a bug against mod_proxy_ajp instead? Or is there some chance this is in the AJP connector? Only if there is a bug - we haven't shown that yet ;) Could you provide some version numbers please (httpd, mod_jk, etc) Also, what setting are you using for JkOptions? http://tomcat.apache.org/connectors-doc/reference/apache.html I suspect you want JkOptions +ForwardURICompatUnparsed but read the docs carefully before making any changes so you understand the security implications. I don't believe mod_proxy_ajp provides any such options -- and I'm using that and Apache 2.2.x, not 2.0.x and/or mod_jk. At any rate, I have: BalancerMember ajp://localhost:8010 min=16 max=80 smax=40 ttl=900 keepalive=Off timeout=9 retry=1 flushpackets=on and RewriteEngine on RewriteRule ^(/MyWebAppName/(.*\.jsp(.*)|servlet/.*|.*\.jar))$ balancer://ajpWorker$1 [P] which maps all JSP, servlet, and .jar requests to Tomcat and lets Apache handle everything else. -- Jess Holle
Re: %3B in path-info
Mark Thomas wrote: Jess Holle wrote: Mark Thomas wrote: Jess Holle wrote: You're right -- this works fine in the direct case. So I need to file a bug against mod_proxy_ajp instead? Or is there some chance this is in the AJP connector? Only if there is a bug - we haven't shown that yet ;) Could you provide some version numbers please (httpd, mod_jk, etc) Also, what setting are you using for JkOptions? http://tomcat.apache.org/connectors-doc/reference/apache.html I suspect you want JkOptions +ForwardURICompatUnparsed but read the docs carefully before making any changes so you understand the security implications. I don't believe mod_proxy_ajp provides any such options -- and I'm using that and Apache 2.2.x, not 2.0.x and/or mod_jk. At any rate, I have: I couldn't see anything either. This looks like a mod_proxy_ajp bug/missing feature. I jumped the gun once by filing this against Tomcat, but it seems everything is pointing to mod_proxy_ajp. Is it time to file a bug against it? -- Jess Holle - 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: %3B in path-info
Jess Holle wrote: Mark Thomas wrote: Jess Holle wrote: Mark Thomas wrote: Jess Holle wrote: You're right -- this works fine in the direct case. So I need to file a bug against mod_proxy_ajp instead? Or is there some chance this is in the AJP connector? Only if there is a bug - we haven't shown that yet ;) Could you provide some version numbers please (httpd, mod_jk, etc) Also, what setting are you using for JkOptions? http://tomcat.apache.org/connectors-doc/reference/apache.html I suspect you want JkOptions +ForwardURICompatUnparsed but read the docs carefully before making any changes so you understand the security implications. I don't believe mod_proxy_ajp provides any such options -- and I'm using that and Apache 2.2.x, not 2.0.x and/or mod_jk. At any rate, I have: I couldn't see anything either. This looks like a mod_proxy_ajp bug/missing feature. I jumped the gun once by filing this against Tomcat, but it seems everything is pointing to mod_proxy_ajp. Is it time to file a bug against it? P.S. Where we use Apache 2 and mod_jk, we use JkOptions +ForwardURIEscaped JkOptions +FlushPackets The latter is covered in mod_proxy_ajp via "flushpackets=on", but I don't see any coverage of the former. -- Jess Holle
Re: %3B in path-info
Mark Thomas wrote: Jess Holle wrote: Mark Thomas wrote: I couldn't see anything either. This looks like a mod_proxy_ajp bug/missing feature. I jumped the gun once by filing this against Tomcat, but it seems everything is pointing to mod_proxy_ajp. Is it time to file a bug against it? Looks like it to me. Done. [https://issues.apache.org/bugzilla/show_bug.cgi?id=44803] Thanks. -- Jess Holle - 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: %3B in path-info
Rainer Jung wrote: Hmmm. Unfortunately I couldn't follow the thread earlier. As far as I know the problem is the following: A semicolon is used to separate the jsessionid in case you are using URL encoded sessions. As far as I remember the AJP connnector does *not* recognize %3Bjsessionid. So if you are using URL encoded sessions, semicolons need to be decoded before sending to Tomcat, or Tomcat needs a patch to recognize %3bjsessionid in the AJP connector. Of you don't use URL encoded sessions, you can choose the correct forward option in mod_jk. That's great in mod_jk -- and as I noted we're already using an appropriate forward option where we use mod_jk. [This is for conveying information in the path info -- not for jsessionid, where we require cookies.] Concerning mod_proxy_ajp: I'm not sure, if it is a bug. Since %3B and semicolon should be euivalent, my question is: do you get the correct path info if you use Tomcat http connector directly and use semicolon instead of %3B? ";" is not the same as %3B as I understand it. A raw ";" is reserved by the RFC and denotes a separation between path components and other data, e.g. jsessionid. An encoded ";", i.e. %3B should be able to be part of the path components, though. As Mark Thomas helped me to realize the issue is that mod_proxy_ajp has no equivalent of the option we'd been relying upon in mod_jk to resolve this issue. That's a serious gap in mod_proxy_ajp. On the other hand, there's a lot to be said for Apache 2.2 in general and mod_proxy_ajp in particular, so we really need this gap closed and can't just revert to mod_jk. -- Jess Holle - 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: %3B in path-info
Rémy Maucherat wrote: On Fri, Apr 11, 2008 at 1:58 AM, Rainer Jung <[EMAIL PROTECTED]> wrote: Rémy, I know that we cleaned reencoding of forwarded URLs up in the context of the CVE and mod_jk. The semicolon wasn't involved in the CVE though and at that time it would have been easier, if the AJP connectors had resolved %3Bjsessionid (because then we wouldn't have needed a new JK forward option). %3Bjsessionid is not a session id. JK should not be passing a decoded URL, and that's pretty much the end of the story. Agreed -- but that draws me back to the need for an option (or default behavior!) in mod_proxy_ajp wherein the URL passed to via AJP is not decoded. -- Jess Holle
Re: Few public ports w/many Tomcat instances
Mike Volk wrote: I'm a Java developer and reluctant/under-qualified server administrator formulating a strategy for transitioning two production web apps from Resin to Tomcat. I'm familiar with connecting multiple Resin instances to a single Apache instance, such that all of the Resin instances (on ports in the 808X range) are accessible via Apache on ports 80 and 443. I get the gist of how to do this using Tomcat behind Apache, and how to provide direct access to multiple instances of Tomcat standalone (without Apache) using the hostname in combination with the corresponding Tomcat instance's unique port number. Unfortunately, I must run multiple instances of Tomcat, I must run those instances on the same machine, and I cannot provide public access to that (production) machine on any ports other than 80 (http) and 443 (https). Yes, both web apps use both http and https. Is there a better/faster/easier alternative to using Apache as a front-end "port proxy server" (via vhosts) for my multiple Tomcat instances? Tomcat alone appears to provide all the web server features I need, except for the aforementioned "port proxy" functionality. Perhaps a third instance of Tomcat could do that? Perhaps there is an even more elegant solution?? I'm not aware of any better solutions. Apache does work quite well in this role. That said, it would be nice if there was a Java replacement for Apache in this infrastructure. It could still use AJP as the communication protocol and could be an instance of Tomcat or Glassfish or a special web app as far as I'm concerned -- though ideally it would use NIO rather than APR as having to build/maintain/distribute native code for various platforms is the main issue with Apache as I see it. -- Jess Holle - 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: JMX MBean
Johnny Kewl wrote: If not and its a bean in your servlet that you want to use. Then this article is the only one I've ever seen on the subject http://oss.wxnet.org/mbeans.html Essentially there is a bean Registry inside tomcat... and the idea is to get your bean into that registry... then TC will treat it like its own internal beans, and then Jconsole will see it. So... it seems you stick your bean in TC libs, you do a little XML stuff so the TC picks it up, and then you use a listener to start the bean. Then your Servlet will just use that bean. Then mbeans are actually quite complex, and getting the interfaces right is not so easy, but luckily Netbeans, and probably eclipse (not sure) has a plugin that automates the testing mbeans in your code... so together you on your way... hopefully. That side of it will help you get the Mbean right and figure out how to get a chart going in Jconsole etc. Of course you can just ignore the fact that this is Tomcat (i.e. be servlet engine independent) and register your MBeans with the platform MBean server in a different domain. [I'm assuming you're using Java 5 or 6.] Also some MBean approaches are quite complex, but standard MBeans and then the StandardMBean class when the simple minded standard MBean pattern runs out of gas are quite easy. Using the latter approach you can easily have your MBean start with a statically typed/declared MBean interface and then add dynamic operations and attributes if/when you need to. The managed MBean stuff in Tomcat itself is more complicated than most common use cases require. -- Jess Holle - 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: It¡¯s amazing, apache make TC performance decrease dramatically.
Bill Barker wrote: You haven't given your O/S details, but yes, AJP will s*ck big time on older Linux kernals with this test. Older kernals can't handle having 1000+ threads active efficiently. You could try testing again with the APR and/or (experimental) NIO AJP Connectors. These usually get the difference down to somewhat acceptable. However, using Apache+mod_jk just to increase performance is a myth, based on the state of Tomcat 8+ years ago ;). It will almost always be slower with any current version. Yet until there's a Java equivalent of mod_jk/mod_proxy_ajp load balancing some of us are wed to Apache for that if no other reason. I suspect it is possible to out-do Apache with Java in this capacity, but no such thing exists today. Of course Apache 2.2's handling of authentication against multiple LDAPs, credential caching, etc -- all without extra work -- is also pretty nice [Tomcat does not yet have this last I checked...], but wouldn't by itself be sufficient justification for Apache in a primarily JSP/servlet environment. -- Jess Holle - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Another session replication question
I somehow missed Filip Hanik's helpful response to my previous session replication question. I have one other: With DeltaManager and/or BackupManager, are multiple calls to setAttribute() and/or removeAttribute for the same attribute during the same request coalesced/collapsed? It is my understanding that the delta is sent at the end of the request -- or did I misunderstand this? If so, I would hope/assume a sequence like: setAttribute( "foo", "bar" ); setAttribute( "foo", "something else" ); removeAttribute( "foo" ); setAttribute( "baz", "bar" ); setAttribute( "baz", "something else" ); would result in the delta consisting of only removeAttribute( "foo" ); setAttribute( "baz", "something else" ); Obviously this is not so critical in this example -- but easily could be if the values passed to setAttribute() are large object graphs rather than simple strings. -- Jess Holle
Re: Another session replication question
Thanks for the info. A little more reading of the code and I clearly see that -- sorry for the dumb question. Now for the hard part - determining if we really can and should start replicating a large application grown over the last decade -- given the limitations of setAttribute/removeAttribute()-based change detection, last-request-wins session update, etc... -- Jess Holle Filip Hanik - Dev Lists wrote: hi Jess, you're example is correct, replication doesn't happen until the request is complete and is done by the ReplicationValve. Filip Jess Holle wrote: I somehow missed Filip Hanik's helpful response to my previous session replication question. I have one other: With DeltaManager and/or BackupManager, are multiple calls to setAttribute() and/or removeAttribute for the same attribute during the same request coalesced/collapsed? It is my understanding that the delta is sent at the end of the request -- or did I misunderstand this? If so, I would hope/assume a sequence like: setAttribute( "foo", "bar" ); setAttribute( "foo", "something else" ); removeAttribute( "foo" ); setAttribute( "baz", "bar" ); setAttribute( "baz", "something else" ); would result in the delta consisting of only removeAttribute( "foo" ); setAttribute( "baz", "something else" ); Obviously this is not so critical in this example -- but easily could be if the values passed to setAttribute() are large object graphs rather than simple strings. -- Jess Holle - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JMX] org.apache.catalina.session.StandardManager not serializable
Caldarale, Charles R wrote: From: Emmanuel Soden [mailto:[EMAIL PROTECTED] Subject: Re: [JMX] org.apache.catalina.session.StandardManager not serializable Using Tomcat 5.5.27 with JDK 1.5.0_11, I'm trying to retrieve the attribute "manager" from the MBean "Catalina:J2EEApplication=none,J2EEServer=none, j2eeType=WebModule,name=//localhost/". I don't think there's any requirement for any app to guarantee that attributes are serializable, and I suspect trying to make StandardManager so would create a host of issues inside Tomcat. Perhaps you should try retrieving the attributes you're interested in from this JMX location instead: "Catalina:type=Manager,path=/,host=localhost" Its attributes are all retrievable, at least according to JConsole when I try to retrieve an attribute like "managedResource" from the MBean "Catalina:host=localhost,type=Host" >From a brief perusal of the 6.0 code (sorry, not the level you're using), there appears to be extremely limited use of the "managedResource" attribute, despite its presence in most of the MBeans. Looks like in the vast majority of cases, the attribute is never set. More generally I have had cases where I've had an attribute exposed via JMX for /in-process /usage that then blows chunks with out-of-process usage. This should be avoided, but where it cannot be it should be documented as "the way things are" and possibly addressed by replaceObject(). [In my recent case I used replaceObject() to replace my non-serializable data with an approximation thereof whose toString() would show something somewhat meaningful in a remote JMX console.] -- Jess Holle
Re: Performance of APR
David Boreham wrote: I think you also need to factor in the labor cost to manage two different servers. I know that in our production deployments we could buy many many machines for the cost of the time we've spent trying to make AJP work. Tomcat could be 10x slower than Apache and I'd still use it to avoid the hassle. Of course if you need load balancing across multiple Tomcats you either need Apache or a dedicated load balancer appliance. Also Apache 2.2 allows easy configurable authentication (or a single resource/URL) against multiple authentication repositories, e.g. multiple LDAPs. Last I investigated Tomcat did not. I'd love to see a simple world of only needing Tomcat and no front-end web server. For starters Tomcat should provide high-performance load-balancing from one "front-end" Tomcat to multiple "backend" Tomcats and easy authentication against multiple LDAPs. After that there are other issues, e.g. security providers that provide Apache but not Tomcat plug-ins, but these would seemingly impact far fewer folk. In fact, I'd bet fairly few of us need the multi-LDAP stuff -- just giving good, high-performance load balancing over Tomcats by a Tomcat would be huge. -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
David Boreham wrote: Jess Holle wrote: David Boreham wrote: I think you also need to factor in the labor cost to manage two different servers. I know that in our production deployments we could buy many many machines for the cost of the time we've spent trying to make AJP work. Tomcat could be 10x slower than Apache and I'd still use it to avoid the hassle. Of course if you need load balancing across multiple Tomcats you either need Apache or a dedicated load balancer appliance. You can make your own LB using Tomcat. Yes, I /could/, but Apache already does it. I don't want to invest enough of my own time in such a thing to put it on an equal footing with mod_jk and mod_proxy_ajp. Until someone does, though, Apache is a really necessary piece in a lot of configurations. -- Jess Holle
Re: Performance of APR
Mladen Turk wrote: When it comes to the large file serving then the OS sendfile support in Tomcat Native outperforms the standard Java IO by an order of magnitude (In some of my tests up to 4 times), and with constant memory usage regardless of file size. There is also some other advanced features like Thread per request processing model, and much faster OpenSSL compared to JSSE. I have a presentation from ApacheCon EU 2007 that has some performance figures: http://people.apache.org/~mturk/tc6apconneu07.pdf Which is all cool. If you have to support lots of different platforms, though, APR seems to be hassle than its worth -- especially given that I already need Apache for load balancing. Pure Java is really, really nice if you're in this boat. That's not knocking APR -- just wishing we'd get the whole problem licked really well in Java and wouldn't have to deal with native code messes (like building/linking on AIX or learning enough about Apache's guts to make substantive patches). -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
Gregor Schneider wrote: Well, if you don't want to deal with the APR (which I don't think is all that complicated), maybe new NIO-connector is worth a try: http://tomcat.apache.org/tomcat-6.0-doc/config/http.html However, I haven't seen any benchmarks comparing NIO with APR, especially when it comes to SSL Btw., a hardware-loadbalancer is not all that expensive... It is when you're talking commercial software using Tomcat. If this was an internal usage of Tomcat, fine and good. Telling everyone that uses your product on Tomcat to use a hardware load balancer just to have more than one Tomcat serving the load is a non-starter, though. -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance of APR
David Boreham wrote: Jess Holle wrote: You can make your own LB using Tomcat. Yes, I /could/, but Apache already does it. I don't want to invest enough of my own time in such a thing to put it on an equal footing with mod_jk and mod_proxy_ajp. Until someone does, though, Apache is a really necessary piece in a lot of configurations. I took the opposite view. It is worth my time to write it. If it ends up being reasonably generic (not sure about that yet) then I'll open source it. Perhaps it would be... I also had a strong multi-LDAP requirement, though, which is not addressed until 6.0.19. Then there's the remaining question about 3rd-party security plug-ins our customers might be using... -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpSessionActivationListener problems
Last I checked the Tomcat source code neither activation nor passivation listeners were ever called. I believe I provided a patch for this but a glance at the source code will make the issue rather obvious (it's not hard to find or understand). [I'd provide a patch for this but we have a number of patches to this particular area of source that overlap. Others are of a bit more controversial nature and I have not kept them separate.] -- Jess Holle Rui Pedro wrote: Hi! I'm implementing one tomcat cluster solution (tomcat 5.5-20). One of the things that I need to know is when the session jumps from one node to the other. I read that I can use the HttpSessionActivationListener listener to detect that type of occurence. To do so, I put one object in the users session that implements the HttpSessionActivationListener interface, the problem is that when I kill one of the clusters node the methods sessionDidActivate an sessionWillPassivate never occurr ... Is HttpSessionActivationListener supported by tomcat? Can you help me? Thanks in advance, Rui Pereira - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Logging servlet time and connections
Beware of acceptCount. If you use this with the AJP connector and don't enable the native connector, then you won't get what you expect -- and last I checked the documentation gave no warning of this. In this scenario once you exceed maxThread minus 2 simultaneous connections (there's a clear off by 2 error here somewhere) any additional simultaneous connections go into some sort of weird limbo, are never processed, and eventually time out. This is irrespective of the value of acceptCount used, which is simply ignored in this case! You'd /expect/ a warning to be logged if acceptCount is non-zero and is simply going to be ignored. You'd also expect 503's for requests that are not going to be handled -- not this weird limbo thing. Overall this is a pretty big gotcha -- especially for those of us supporting enough odd ball platforms that continuously building the native connector for all of these platforms is a non-starter. [One might say just build it once, but we've also had issues with the native connector that are not reproducible with the pure-Java connector.] This has to be one of the ugliest Tomcat warts I've ever run into. -- Jess Holle Caldarale, Charles R wrote: From: cr...@thetimmermans.net [mailto:cr...@thetimmermans.net] Subject: RE: Logging servlet time and connections It could be user sessions if thats whats available. You can implement an HttpSessionListener to track sessions coming and going within a webapp. See the servlet spec for details Basically the acceptCount for the connector is much higher than the maxThread count. The two values are unrelated, so one being higher than the other is irrelevant. Tomcat just passes the acceptCount to the TCP/IP stack, and has no means of examining what the TCP/IP stack does with it So some connections are being held (queued?) without processing. Are you sure? Regardless, such information is not available to Tomcat, but it /may/ be available from your OS No, just when the servlet starts processing and when its complete (we do know the exact servlet we are worried about). It's probably easiest to add logging to the particular servlet to get that specific information. Once the logging calls are added, you can control whether or not they are recorded by manipulating conf/logging.properties. You may be able to get Tomcat to display such fine-grained detail, but it would likely require setting a logging level of DEBUG, which would get way too much data written and be a performance problem. - 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
method invocations in EL?
I note in http://java.dzone.com/articles/unified-el-learns-method that in JEE 6 EL finally allows method invocations. Is there any chance this feature can be used in JSPs in Tomcat 6 today? If so, how? -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: method invocations in EL?
That's unfortunate. One can apparently drop this upgrade into Glassfish. I don't, however, need Glassfish -- just a servlet engine. Nor do I need most Servlet 3.0 stuff at this time. A better Tomcat 6 would be nice, though :-) Tim Funk wrote: I doubt this will be seen in tomcat 6. The closest you'll get are the function taglibs functionality. -Tim Jess Holle wrote: I note in http://java.dzone.com/articles/unified-el-learns-method that in JEE 6 EL finally allows method invocations. Is there any chance this feature can be used in JSPs in Tomcat 6 today? If so, how? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Websphere / Apache similarities
Just to be clear, there are a lot of "should" statements below and other cases that should use this key word. JSPs, servlets and filters /should /be portable between servlet engines supporting the same spec level. In most cases they are. There are, however, bugs and forgiving behaviors specific to each servlet engine. Thus you may encounter bugs specific to WebSphere or cases where Tomcat interpreted the specs in a more forgiving manner than WebSphere, which generally seems to use the most restrictive interpretation of the spec where anything is subject to interpretation. -- Jess Holle Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 3/3/2009 11:54 AM, André Warnier wrote: - Websphere itself is a Java servlet server, unrelated to Tomcat despite my mistaken impressions to the contrary, but implementing the same servlet specification as Tomcat. I think this is important enough to point out, so I will: Java servlet servers /all/ implement the same servlet specification. Different versions of app servers support different versions of the specification, though. For instance, Tomcat 5.x implements servlet 2.4 and JSP 2.0 while Tomcat 6.x implements servlet 2.5 and JSP 2.1. It seems to have additional functionalities compared to Tomcat, but since I do not understand them and think I don't need them, it should be ok. That's the case for most people. Those "additional functionalities" are the "rest" of the J2EE stuff -- the stuff other than servlets and JSPs. I basically wanted to know if I could run a couple of servlets on it which I run on Tomcat Yes. and run also the UrlRewriteFilter Yes. and the Jespa NTLM authentication filter (maybe yes, I'll ask ioplex). Probably. Basically, if it runs under a servlet container, it should run under a J2EE container (the latter is a superset of the former). Websphere by itself, like Tomcat, can probably serve static content too. I'm sure it can. Enjoy! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmtuZ0ACgkQ9CaO5/Lv0PDsngCfUQqYyeM/KuoM98KBVgqqV+nv YGgAn2oppuYW+8cdWG3VJX/pWyjeJRi3 =mCCX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why we need two servers (httpd and tomcat)
Robin Wilson wrote: For the record, my answer was neither stupid or reflexive. I simply pointed out why someone might want 2 layers of servers (httpd and tomcat). And certainly, my rationale is both sound and arguable at the same time. As for your assertion that 2 layers of security is just complexity and not more secure - you obviously haven't run many enterprise production systems. Security in an enterprise system is all about 'layers' of protection. And sure, if they hack one layer - they are probably good enough to hack the next layer. But that's where intrusion detection and a variety of other system come into play. It's all about slowing down the advance of the attack until you can do something about it. As for performance, have you run any load testing against tomcat vs. apache - especially on static files? Apache exceeds tomcat in performance by a large margin. When you are serving millions of pages a day, and tens of millions of static files (images, css, js, videos, audios, etc.), that makes a significant difference in the amount of hardware you have to throw at the problem. So you may be absolutely correct - it is not 'necessary' in a lot of cases. But in many production - enterprise - deployments, it can be useful to have a layer of web servers and a separately managed layer of application servers - and that same model works just fine with Apache and Tomcat. I think the Tomcat folk would dispute your assertion on performance -- in particular when Tomcat is used with native APR. That said, the biggest reason I know of for Apache fronting Tomcat is load balancing across Tomcats. If you have a hardware load balancer doing that, then there are lesser reasons, e.g.: * there are more security plug-ins for Apache (e.g. SiteMinder and the like), * multi-LDAP authentication support is built into Apache, * various existing Apache modules (e.g. mod_redirect) allow some classes of problems to be solved by configuration that would require coding in Tomcat. On this last note, however, I'd say that writing necessary filter/listener/handler code for Tomcat can generally be done in a manner that is portable to any up-to-date servlet engine, is /far/ easier than writing code for Apache modules, and is sometimes even easier than achieving the same end by configuring modules in Apache (where that is approach is sufficient). -- Jess Holle
Re: Why we need two servers (httpd and tomcat)
Jess Holle wrote: Robin Wilson wrote: For the record, my answer was neither stupid or reflexive. I simply pointed out why someone might want 2 layers of servers (httpd and tomcat). And certainly, my rationale is both sound and arguable at the same time. As for your assertion that 2 layers of security is just complexity and not more secure - you obviously haven't run many enterprise production systems. Security in an enterprise system is all about 'layers' of protection. And sure, if they hack one layer - they are probably good enough to hack the next layer. But that's where intrusion detection and a variety of other system come into play. It's all about slowing down the advance of the attack until you can do something about it. As for performance, have you run any load testing against tomcat vs. apache - especially on static files? Apache exceeds tomcat in performance by a large margin. When you are serving millions of pages a day, and tens of millions of static files (images, css, js, videos, audios, etc.), that makes a significant difference in the amount of hardware you have to throw at the problem. So you may be absolutely correct - it is not 'necessary' in a lot of cases. But in many production - enterprise - deployments, it can be useful to have a layer of web servers and a separately managed layer of application servers - and that same model works just fine with Apache and Tomcat. I think the Tomcat folk would dispute your assertion on performance -- in particular when Tomcat is used with native APR. That said, the biggest reason I know of for Apache fronting Tomcat is load balancing across Tomcats. If you have a hardware load balancer doing that, then there are lesser reasons, e.g.: * there are more security plug-ins for Apache (e.g. SiteMinder and the like), * multi-LDAP authentication support is built into Apache, It is my understanding that the next Tomcat release will provide multi-LDAP authentication support, by the way. * various existing Apache modules (e.g. mod_redirect) allow some classes of problems to be solved by configuration that would require coding in Tomcat. On this last note, however, I'd say that writing necessary filter/listener/handler code for Tomcat can generally be done in a manner that is portable to any up-to-date servlet engine, is /far/ easier than writing code for Apache modules, and is sometimes even easier than achieving the same end by configuring modules in Apache (where that is approach is sufficient).
Re: Form Authentication and status (response) code
That's the unfortunate way of form-based authentication. It's an application convention rather than a protocol-level standard -- it's not a standard but rather a loose convention and has to be handled by the application code rather than seamlessly with at protocol handling level. As such it's fine and good for consumption by interactive user sessions in a web browser -- as users can grok conventions just fine unless they're horrifically convoluted. Unfortunately, for any other form of client (e.g. a programmatic, non-interactive service in the extreme case or even an interactive client that is not browser based but rather is written against some HTTP client library or another) form-based authentication is a royal mess. It would be a lot better if form-based authentication standardized around returning a 401 -- ideally with some header information as to how to proceed to respond to the challenge. Unfortunately, responding with a 401 is not really legal here and indeed results in bad behavior from some HTTP client libraries (e.g. that built into Java, for instance). So form-based authentication is an obnoxious mutt -- but a mutt that everyone seems to have fallen in love with. This isn't Tomcat's fault, however, and Tomcat is doing the normal thing by returning a 200 here. As for tricks to see if your 200 isn't really a 200, you can: 1. Check the response Content-Type if the expected Content-Type isn't one that could possibly be used by a login form or 2. Add some other custom header to your response. If it's not there but you got a 200, then something hijacked the response -- quite probably a login form. -- Jess Holle On 9/1/2011 5:49 PM, Mabry Tyson wrote: Summary: When requiring form authentication, Tomcat responds to an unauthenticated GET request with a HTTP status code of 200 (OK) and the login page. I believe that to be in violation of the HTTP standards. The problem: Software makes a GET request to a web server. It gets back a 200 status code. By RFC 2616, that code indicates "the request has succeeded". The software then takes the resulting page as the successful response to the GET request. However, in some cases this response is NOT a successful response but is instead a login form. By using a 200 status code, Tomcat is misrepresenting that the login form is the response to the request. My believe is a 4xx code (client error) is appropriate, or possibly a 3xx code (Redirection) might be appropriate. Unfortunately, the RFC indicates that a 401 (Unauthorized) response MUST have a header that is only appropriate for basic or digest authentication. So a status code of 401 is not legal in this situation. It seems unlikely that I'm the first to comment on this. It must have been discussed extensively before. Can anyone tell me (1) What is the reason behind saying the login form is a successful response? (2) Where is a pointer to the discussions? (3) What is an appropriate (non-ad hoc) way to determine that Tomcat is returning a login form rather than the requested resource? (I have done a quick search of the Internet, of Tomcat FAQ, and of outstanding Tomcat bugs, but didn't find this.) For instance, here are the headers when doing a GET of a login protected page from the examples shipped with Tomcat: > GET /examples/jsp/security/protected/index.jsp HTTP/1.1 > User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3 > Host: xxx.example.com > Accept: */* > < HTTP/1.1 200 OK < Server: Apache-Coyote/1.1 < Pragma: No-cache < Cache-Control: no-cache < Expires: Wed, 31 Dec 1969 19:00:00 EST < Set-Cookie: JSESSIONID=99FD7582647EEF539C449AEBBA5365EB; Path=/examples < Content-Type: text/html < Content-Length: 1413 < Date: Thu, 01 Sep 2011 22:15:29 GMT while the content starts with Login Page for Examples action='j_security_check;jsessionid=99FD7582647EEF539C449AEBBA5365EB' > P.S. For anyone maintaining the examples, shouldn't vendor examples demonstrate the best practices? I'd suggest you indicate the Content-Type and the charset. Also, it would be handy if the web.xml showed how to have the login page be served up by https (along with a note explaining that you don't do it here since you don't know that https willl be available). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Form Authentication vs. Tomcat Restart
When doing a graceful shutdown of Tomcat, the sessions are persisted to disk and then re-read on startup (at least in all reasonably recent versions). Oddly, however, form-based authentication does not seem to survive a graceful restart. Rather one has to log in again. Is this known? Intentional? Configurable? -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication vs. Tomcat Restart
Okay, I now notice this plainly stated in the documentation for JNDIRealm (which I'm using): The cached user is *not* saved and restored across sessions serialisations. That seems a bit odd... On 12/6/2011 5:12 PM, Jess Holle wrote: When doing a graceful shutdown of Tomcat, the sessions are persisted to disk and then re-read on startup (at least in all reasonably recent versions). Oddly, however, form-based authentication does not seem to survive a graceful restart. Rather one has to log in again. Is this known? Intentional? Configurable? -- Jess Holle
Re: Form Authentication vs. Tomcat Restart
I should have noted that this is with Tomcat 7.0.23, but it seemed unlikely to be JVM (Java 6 Update 29) or OS (Windows 7) specific. Of course given that I found that the documentation clearly states this behavior, I suspect this is longstanding Tomcat behavior. My remaining question is /why/ Tomcat behaves this way. If one quickly restarts Tomcat for some reason and session data is preserved, you really don't want all the users to have to login again do you? -- Jess Holle On 12/6/2011 7:05 PM, André Warnier wrote: Jess Holle wrote: When doing a graceful shutdown of Tomcat, the sessions are persisted to disk and then re-read on startup (at least in all reasonably recent versions). Oddly, however, form-based authentication does not seem to survive a graceful restart. Rather one has to log in again. Is this known? Intentional? Configurable? There should be a template for messages on this list : Tomcat version : Java version : platform OS & version : - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication vs. Tomcat Restart
Yes, I now note this in the documentation. The question remains, however: /why /does it work this way? On 12/7/2011 6:34 AM, Mohammad M. AbuZer wrote: Tomcat does that for every all Form Authentication even if you used `DatabaseRealm` it doesn't save logged user. On Wed, Dec 7, 2011 at 2:24 PM, Jess Holle wrote: I should have noted that this is with Tomcat 7.0.23, but it seemed unlikely to be JVM (Java 6 Update 29) or OS (Windows 7) specific. Of course given that I found that the documentation clearly states this behavior, I suspect this is longstanding Tomcat behavior. My remaining question is /why/ Tomcat behaves this way. If one quickly restarts Tomcat for some reason and session data is preserved, you really don't want all the users to have to login again do you? -- Jess Holle On 12/6/2011 7:05 PM, André Warnier wrote: Jess Holle wrote: When doing a graceful shutdown of Tomcat, the sessions are persisted to disk and then re-read on startup (at least in all reasonably recent versions). Oddly, however, form-based authentication does not seem to survive a graceful restart. Rather one has to log in again. Is this known? Intentional? Configurable? There should be a template for messages on this list : Tomcat version : Java version : platform OS& version : --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Any servlet API event to denote change in session id
I note that in recent versions of Tomcat (e.g. 7.0.23), the session id changes when you do a form-based authentication. I do not see any sort of notice via anything one can listen to via the servlet API to receive notice of this change. This makes things rather ugly if one is monitoring the sessions oneself -- as their identity changes out from under you without any notice. Am I missing something here? [Yes, I note the container event, but that necessitates Tomcat-specific code, etc -- especially given that this isn't fired as a JMX notification anywhere that I can see.] -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Any servlet API event to denote change in session id
On 12/7/2011 11:47 AM, Mark Thomas wrote: On 07/12/2011 17:04, Jess Holle wrote: I note that in recent versions of Tomcat (e.g. 7.0.23), the session id changes when you do a form-based authentication. I do not see any sort of notice via anything one can listen to via the servlet API to receive notice of this change. This makes things rather ugly if one is monitoring the sessions oneself -- as their identity changes out from under you without any notice. Am I missing something here? [Yes, I note the container event, but that necessitates Tomcat-specific code, etc -- especially given that this isn't fired as a JMX notification anywhere that I can see.] No, you aren't missing anything. Note the session object does not change, just the value returned for the ID. This will hopefully get fixed in Servlet 3.1 Your other option is to turn off the session fixation protection (not recommended). Thanks. I have a request listener and can use it to notice session id changes by the end of a request at least, update all my tracking data, and log the occurrence for interested parties. It's a little later in the scheme of things than I'd like, but efficient enough. -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication vs. Tomcat Restart
You get an error when that's what's occurring, though. On 12/7/2011 12:55 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jess, On 12/6/11 6:17 PM, Jess Holle wrote: Okay, I now notice this plainly stated in the documentation for JNDIRealm (which I'm using): The cached user is *not* saved and restored across sessions serialisations. That seems a bit odd... I wouldn't think that should be a problem: subsequent requests (after a restart) should re-create whatever data are necessary. We used to have this problem, and it turned out that we had a few objects in the session that were serializable yet still not un-serializable (because they didn't have no-arg constructors, for instance). Is it possible you are having a problem like that? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7ftpgACgkQ9CaO5/Lv0PAxJgCfW8G91XwwLTiUAXoYO16NCojL aNUAoLysh1BGs942flGrKpVv1i40AsPN =zzm/ -END PGP SIGNATURE- - 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
Re: ThreadLocals, context listeners and classloader leaks
On 1/26/2012 10:38 AM, Mark Thomas wrote: OK. ThreadLocals have no place in a web application. Period. If a programmer insists on using them, then it is their responsibility to clean up the mess they leave behind. Tomcat's memory leak detection and prevention code goes some way to clearing up things like this but it is never going to cover every case. Mark Or put another way, you have a choice: 1. Use ThreadLocals the way you'd have assumed you could, but don't expect to ever restart your web app without leaking tons of memory. 2. Use ThreadLocals, but be sure you religiously clean up after yourself by the time your web app is fully shut down. 3. Don't use ThreadLocals. If you use someone else's library that uses ThreadLocals then you'll probably end up in forced into A. That said, there could and arguably should be another choice: 4. Select a special mode in a servlet engine that shuts down all threads that have ever serviced requests for a given web app when it is shutdown (and code your web app to shutdown any threads it creates, obviously!), e.g. after they complete servicing any request in progress. [It could just replace all request threads with new ones after the requests currently in progress complete.] That's assuming the servlet engine is nice enough to provide such a mode. If it did, however, I believe that would resolve any ThreadLocal issues without one having to avoid using a perfect natural and useful Java language feature. I'd argue all servlet engines should really provide this feature for just this reason. That said, I can live with A. -- Jess Holle
Re: Tomcat does not honor acceptCount configuration variable
If you're talking about the non-native AJP connector, then this is a long-standing issue. acceptCount is essentially ignored in this case and all concurrent requests above pool size /minus 2/ go off into limbo and are not handled properly. I don't understand the off-by-2 error, but it is clearly there. If you're talking about some other connector, then I cannot speak to that -- as I use the pure Java (non-NIO for stability) connector. Native connectors are just too painful to build, update, and troubleshoot across all the platforms I deal with. This clearly isn't going to change no matter how stable these connectors are and I need to use Apache anyway, so native connectors are a dead end. It's either old-IO or NIO, but it needs to be pure Java for me. -- Jess Holle On 5/10/2010 7:35 AM, André Warnier wrote: Timir Hazarika wrote: Andre, Response from Leon just about summarizes this issue: the shock absorber you mention is not configurable. Setting the acceptCount to 1 or nine hundred produces exactly the same behavior in terms of connections awaiting response. Then that would be a bug, no ? In the sense that the documentation says : acceptCount The maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default value is 100. http://tomcat.apache.org/tomcat-6.0-doc/config/http.html The "stricter" scheme hence, serves as a usable application workaround for now. If the above bug is real, then yes, it makes a difference. I still believe that handling this at the level of a front-end makes more sense. At least there, you can return something nice rather than brutally rejecting the connection, and you can also examine the request to determine if you really want to block it or not. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat Form Authentication Timeout Behavior
I've noticed that if I POST to an authenticated URL in a web app configured for form-based authentication, Tomcat delivers the login form, and then replays the POST just fine *unless* the current state of the browser is one where I had already been authenticated but that session had timed out. In that case, Tomcat fails to deliver the POST data. I assume this is a known issue/limitation. If not, is there some configuration setting I'm missing or some such? This is with Tomcat 7.0.23. -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Form Authentication POST data not preserved?
I posted a query recently wherein I thought that POST data was being lost *only* if the user had been authenticated, their session timed out, and then they POST'ed to a URL requiring authentication -- thus having their request interrupted for a form-based login. I know Tomcat is supposed to preserve the POST data in this case as well as in the case where one had not yet authenticated prior to the POST, but I'd thought that the latter case worked. As someone nicely pointed out, that makes no sense. So here's the issue: Neither case works. My POST data is always lost here. I've tried various values of maxSavePostSize, including leaving it unspecified -- to no avail. [I had it set to -1 and maxPostSize also set to -1, which I also tried leaving unspecified.] I've tried various things -- all with no luck. This is with Tomcat 7.0.23. I'm pretty sure I was having similar issues with 7.0.25 as well. [No, I didn't really downgrade -- I'm just working in a context that's still using 7.0.23 at the moment.] I'm left wondering what could be causing the issue. -- Jess Holle P.S. The lack of wisdom of setting maxSavePostSize is clear enough to me now. I'll be setting this to a large but still not egregious value once I figure out the rest of this... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
In case this makes any difference this is with the AJP BIO connector. On 2/3/2012 4:51 PM, Jess Holle wrote: I posted a query recently wherein I thought that POST data was being lost *only* if the user had been authenticated, their session timed out, and then they POST'ed to a URL requiring authentication -- thus having their request interrupted for a form-based login. I know Tomcat is supposed to preserve the POST data in this case as well as in the case where one had not yet authenticated prior to the POST, but I'd thought that the latter case worked. As someone nicely pointed out, that makes no sense. So here's the issue: Neither case works. My POST data is always lost here. I've tried various values of maxSavePostSize, including leaving it unspecified -- to no avail. [I had it set to -1 and maxPostSize also set to -1, which I also tried leaving unspecified.] I've tried various things -- all with no luck. This is with Tomcat 7.0.23. I'm pretty sure I was having similar issues with 7.0.25 as well. [No, I didn't really downgrade -- I'm just working in a context that's still using 7.0.23 at the moment.] I'm left wondering what could be causing the issue. -- Jess Holle P.S. The lack of wisdom of setting maxSavePostSize is clear enough to me now. I'll be setting this to a large but still not egregious value once I figure out the rest of this... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Or could this be getting loused up by having a servlet request filter that calls getParameterMap() first thing? I'd *assume* not -- as that would be pretty hokey... On 2/3/2012 4:53 PM, Jess Holle wrote: In case this makes any difference this is with the AJP BIO connector. On 2/3/2012 4:51 PM, Jess Holle wrote: I posted a query recently wherein I thought that POST data was being lost *only* if the user had been authenticated, their session timed out, and then they POST'ed to a URL requiring authentication -- thus having their request interrupted for a form-based login. I know Tomcat is supposed to preserve the POST data in this case as well as in the case where one had not yet authenticated prior to the POST, but I'd thought that the latter case worked. As someone nicely pointed out, that makes no sense. So here's the issue: Neither case works. My POST data is always lost here. I've tried various values of maxSavePostSize, including leaving it unspecified -- to no avail. [I had it set to -1 and maxPostSize also set to -1, which I also tried leaving unspecified.] I've tried various things -- all with no luck. This is with Tomcat 7.0.23. I'm pretty sure I was having similar issues with 7.0.25 as well. [No, I didn't really downgrade -- I'm just working in a context that's still using 7.0.23 at the moment.] I'm left wondering what could be causing the issue. -- Jess Holle P.S. The lack of wisdom of setting maxSavePostSize is clear enough to me now. I'll be setting this to a large but still not egregious value once I figure out the rest of this... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
On 2/3/2012 5:26 PM, Konstantin Kolinko wrote: 2012/2/4 Jess Holle: I posted a query recently wherein I thought that POST data was being lost *only* if the user had been authenticated, their session timed out, and then they POST'ed to a URL requiring authentication -- thus having their request interrupted for a form-based login. I know Tomcat is supposed to preserve the POST data in this case as well as in the case where one had not yet authenticated prior to the POST, but I'd thought that the latter case worked. As someone nicely pointed out, that makes no sense. Why? The saved data is kept in session. If session times out (that means: it is removed from the server) the data that was kept in it becomes lost as well as the session itself. Or maybe I do not quite understand you (try rephrase your statements, listing the events in chronological order). How's this? Case 1: 1. Browse to (anonymously accessible) data entry form without having logged in yet 2. Click to POST data to authenticated result page URL 3. Fill in login form 4. See result page Case 2: 1. Log in 2. Browse to data entry form (anonymous or otherwise) 3. Allow session to time out (or force this on the server) 4. Click to POST data to authenticated result page URL 5. Fill in login form 6. See result page I'd expect to see the results in both cases reflect the POST data. Initially I had thought that Case #1 worked but Case #2 didn't. That makes no sense -- as others pointed out. Now I see that neither case works. -- Jess Holle
Re: Form Authentication POST data not preserved?
Yes, I'm using Tomcat authentication. Yes, the issue is after authentication on the POST retry. On 2/4/2012 12:27 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jess, On 2/3/12 5:59 PM, Jess Holle wrote: Or could this be getting loused up by having a servlet request filter that calls getParameterMap() first thing? I'd *assume* not -- as that would be pretty hokey... Probably not: Tomcat's valves (including the one that performs authentication) all fire before any of the webapp-specified filters run. In any case, the problem you observe is *after* authentication when the POST should be re-tried, right? Silly question: you *are* using Tomcat's authentication, right? I mean, if you're using something else like ACEGI (does that even still exist -- other than as Spring Security?) then you'll have to look somewhere else. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8teKEACgkQ9CaO5/Lv0PAmYwCeI0qfe5iNv/8X3z3eN4PyKtm1 6YYAoKteM140ZuIVbr9e01IP9aZf+rZq =aUyr -END PGP SIGNATURE- - 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
Re: Form Authentication POST data not preserved?
I've done all the basic troubleshooting tweaks I can think of, trying 7.0.25 and 7.0.23, switching my web.xml back to the 2.5 spec level, reducing from a combination of 2 JNDI realms to 1, cranking lots of loggers up to full verbosity, etc. In all cases I lose the POST parameters. I guess I either ignore this (ouch) or really dig into debugging Tomcat's internals (which while far easier than trying to do so with httpd is still not where I'd wanted to spend my time). -- Jess Holle On 2/4/2012 5:49 PM, Jess Holle wrote: Yes, I'm using Tomcat authentication. Yes, the issue is after authentication on the POST retry. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
On 2/5/2012 8:29 AM, Konstantin Kolinko wrote: 2012/2/5 Jess Holle: I've done all the basic troubleshooting tweaks I can think of, trying 7.0.25 and 7.0.23, switching my web.xml back to the 2.5 spec level, reducing from a combination of 2 JNDI realms to 1, cranking lots of loggers up to full verbosity, etc. In all cases I lose the POST parameters. 1. You have to pay attention to Cookie/Set-Cookie headers that are sent between Server and Client. The value there is session id. Just a note: upon successful authentication there should be one more Set-Cookie header sent by the server, because session id will be changed (but not the session itself). You can use browser plugins (like Firefox Live Http Headers or Firebug), network sniffers (Wireshark) or just configure your access log to log those headers. The standard Tomcat Manager web application can be used to inspect active sessions and their attributes. Nothing appears to be amiss with respect to Set-Cookie and Cookie headers. 2. Enable debug logging for FormAuthenticator class. org.apache.catalina.authenticator.FormAuthenticator.level=FINE If you configure logging to use OneLineFormatter, it will include thread id and it will be easier to match it against access log (if access log is configured to print thread ids as well). E.g. 1catalina.org.apache.juli.FileHandler.formatter = org.apache.juli.OneLineFormatter I had already increased verbosity for FormAuthenticator -- nothing seemed amiss from what I could tell there. It /said/ it was restoring the original request from the session. I never see anything about a POST body being restored, but I'm not sure if there is any logging to this effect. http://wiki.apache.org/tomcat/FAQ/Developing#Debugging Thanks. I've got that part down. The harder part is rebuilding pieces of Tomcat with full debug information (I'm assuming Tomcat is normally not built with local variable debug information) and finding my way through unfamiliar code. But that's life :-) -- Jess Holle
Re: Form Authentication POST data not preserved?
On 2/5/2012 9:26 AM, Konstantin Kolinko wrote: build.xml: build.properties.default: compile.debug=true Thus debug information should already be there. I usually start with setting some breakpoints. In your case take a look at FormAuthenticator#saveRequest() and #restoreRequest() methods and where they are called from. Thanks. I've already seen via a heap dump that the request is saved with the correct content body. So now the only question that remains is why it does not get restored. -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
On 2/5/2012 9:43 AM, Jess Holle wrote: On 2/5/2012 9:26 AM, Konstantin Kolinko wrote: build.xml: build.properties.default: compile.debug=true Thus debug information should already be there. I usually start with setting some breakpoints. In your case take a look at FormAuthenticator#saveRequest() and #restoreRequest() methods and where they are called from. Thanks. I've already seen via a heap dump that the request is saved with the correct content body. So now the only question that remains is why it does not get restored. Diving in deeper, I see that AbstractAjpProcessor.action() is setting the bodyBytes perfectly for the ActionCode.REQ_SET_BODY_REPLAY case here. After that is done, however, I don't see anything that tries to read AbstractAjpProcessor.bodyBytes. org.apache.catalina.connector.Request.readPostBody() seems to completely ignore this data. I'm thinking some refactoring in this area completely broke this use case at least for the AJP BIO path. Or can someone offer evidence that the breakage is less general than this? -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
On 2/5/2012 10:38 AM, Jess Holle wrote: Diving in deeper, I see that AbstractAjpProcessor.action() is setting the bodyBytes perfectly for the ActionCode.REQ_SET_BODY_REPLAY case here. After that is done, however, I don't see anything that tries to read AbstractAjpProcessor.bodyBytes. org.apache.catalina.connector.Request.readPostBody() seems to completely ignore this data. I'm thinking some refactoring in this area completely broke this use case at least for the AJP BIO path. Or can someone offer evidence that the breakage is less general than this? I'm not seeing any evidence as to how org.apache.catalina.connector.Request is convinced to use the new bodyBytes from AbstractAjpProcessor here, neither in 7.0.25 or looking back at previous tags. Am I missing something here? Note that I can see how the HTTP connectors could work in this regard -- I'm just not seeing how the AJP connectors could. -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
On 2/5/2012 11:15 AM, Konstantin Kolinko wrote: I think this issue is specific to AJP. For HTTP connectors a similar issue was noted and fixed here: https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9 I think adding the following line to "REQ_SET_BODY_REPLAY" case in AbstractAjpProcessor#action() will fix this bug: endOfStream = false; That did the trick! [I just did this via the debugger without a rebuild, but same thing.] Could someone please patch this into trunk so it's in the next Tomcat release? Until then I can certainly patch it into my own Tomcat. I just don't want to maintain this patch forever (nor have everyone else suffer from this bug in the AJP case). -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
On 2/5/2012 11:22 AM, Jess Holle wrote: On 2/5/2012 11:15 AM, Konstantin Kolinko wrote: I think this issue is specific to AJP. For HTTP connectors a similar issue was noted and fixed here: https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9 I think adding the following line to "REQ_SET_BODY_REPLAY" case in AbstractAjpProcessor#action() will fix this bug: endOfStream = false; That did the trick! [I just did this via the debugger without a rebuild, but same thing.] Could someone please patch this into trunk so it's in the next Tomcat release? By "patch", I mean "commit", of course :-) Until then I can certainly patch it into my own Tomcat. I just don't want to maintain this patch forever (nor have everyone else suffer from this bug in the AJP case). -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form Authentication POST data not preserved?
On 2/5/2012 11:24 AM, Jess Holle wrote: On 2/5/2012 11:22 AM, Jess Holle wrote: On 2/5/2012 11:15 AM, Konstantin Kolinko wrote: I think this issue is specific to AJP. For HTTP connectors a similar issue was noted and fixed here: https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9 I think adding the following line to "REQ_SET_BODY_REPLAY" case in AbstractAjpProcessor#action() will fix this bug: endOfStream = false; That did the trick! [I just did this via the debugger without a rebuild, but same thing.] Could someone please patch this into trunk so it's in the next Tomcat release? By "patch", I mean "commit", of course :-) Until then I can certainly patch it into my own Tomcat. I just don't want to maintain this patch forever (nor have everyone else suffer from this bug in the AJP case). Also it strikes me that maxSavePostSize should really be backed up by a use of a SoftReference in SavedRequest. This would allow one to allow relatively large POST bodies to be saved unless/until this threatened to consume the JVM's overall memory resources, at which point the POST bodies could be dropped. As it stands now one has to choose between vicious treatment of large POST bodies (i.e. dropping all the user's data) and opening oneself wide open to quick and easy (and possibly accidental) DOS attacks. -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
