Failed JDBC connection hangs Tomcat
We have the same problem, that described in http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg58799.html There is ServletContextListener in our application, that schedule two tasks for repeated fixed rate execution on context initialization (Timer.scheduleAtFixedRate). First task is executed every minute. It queries MS SQL server, second task is executed every hour. If MS SQL server goes down, first task tries to use connection to database. After this Tomcat may hang: when user tries to download a page, he or her will wait for a long time (more that 1 day). At the same time second taks (that is executed every hour) works as it was expected: there are corresponding entries in log file. First task is executed in separate thread, and I do not understand how can it hang whole tomcat (at least one context). We use JDK 1.5, tomcat 5.0.28. The same problem was on 1.4.2. Both for MS and JTDS drivers :-( Does somebody know how can I prevent tomcat from hang in such situations? Thank you in advance, Igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
I marked my response as OT, I think we're going down that road (not exactly unusual for us)... Dakota Jack wrote: What I was getting at is the fact that if I return a page to the browser that have ten images, all referencing ResourceAction, what's happening is that the browser is making ten separate requests TO THE APP SERVER, whereas in a "typical" setup, these requests would be handled by the fronting web servers. It's clearly more resource-intensive in your approach. I am not clear what part of the process you are referring to, Frank. We both agree that the first delivery of the page is via the "front server" (I tend to only use the "back server" anyway). I wasn't clear on that part I guess, but it doesn't change my argument. I guess your saying the pages aren't even JSPs, which is fine. Doesn't really change anything though except that there's no servlet involvement to serve the initial page, which is slightly better. That's cool... If there are ten calls to ten images, as you assume for discussion purposes, then there will be ten calls either way. That's correct. Just basic HTTP here :) > I think you are saying that in addition there will be a penalty of a pass to a server that can handle Servlets or an equivalent technology that will respond to the ProtocolPage by routing the call to some Action, Command, or whatever in some language, in the way I suggest. Is that right? If so, let me know and we will go from there after you confirm. That's it exactly. The web server has to forward the .do request to the app server, which then serves the images, 10 total servlet invocations in all. Yes, there would be ten requests either way, but one assumes that the web server can serve static content more efficiently than any Action you can devise. Perfectly logical argument, ceteris paribus (I love using Greek in real conversations!), because that's exactly what web servers are optimized to do. I wouild need, as you would too I assume, more information on the actual penalty. Absolutely. The only assumption I'm making is that there IS a penalty. There are any number of factors that would go into how big or small it is, whether it's enough to outweigh the benefits of the approach. I make no attempt here to reach any conclusion on the magnitude of the problem, if it is a problem at all. > I suspect that it is relatively small and, when you introduce sophisticated state and caching options, it may be faster. Relative to what? To the web server dealing with it? I would suspect it's actually relatively BIG compared to that. I'm certainly willing to be proved wrong though. I don't dismiss what you are saying. Don't get me wrong. I just have learned to get the data and then to see what the real difference is. And I would agree that's the right frame of mind in all things :) It may in fact be such a small penalty that it's worth ignoring. I have a suspicion it's not, but without empirical data, it's just a hypothesis. When considering costs and so on, I am not sure whether the balance goes to which side. I would suspect, from my experience, that software maintenance and so on would clearly outweigh the hardware and associated requirements. That might be true... one other point to remember though is that the more "unusual" things you do, the harder it will be to get people able to maintain it. I fight standards at work as much as the next guy just because creative people don't like standards forced on them, but clever solutions usual equal difficult to maintain solutions. I don't think I'm telling you something you don't know :) But, that's not my argument, so don't spend any time on it. Just another side track we could go down :) I am surprised at this. You may be right, but my sense is that this difference is not really that important when everything else is taken into account. Even if you had to cluster multiple machines instead of one, say, as a ratio, that would seem to be *probably* cheaper as a GUESS. I don't know. We could look at some data and if you have any handy I would love to see it. I don't have any handy, but I agree, some real data here would be better than us bantering back and forth for the next week :) I suppose the simplest thing to do is set up a test where you serve 10 static images from a web server vs. 10 images from your ResourceAction with a web server in front of the app server and see what the overall response time is. It would be a little rough, but at least we could tell if there is a perceivable difference or not. Then we get into whether thousands of imperceivable hits accumulate enough over time to hurt us. That's obviously far trickier to guage, but that's the kind of things us enterprise architects have to bother about. :) I think the bigger hit is reading the danged thing. This obviously is especially so when there is an ongoing use of changing the JSP page. This has no penalty with ProtocolPages. Not
Where is "jkstatus" function in jk version 1.2.8?
I understand that the jk 1.2.8 connector supercedes the deprecated jk2 connector. I had read previous posting that indicated version 1.2.8 of jk contained equivalent or better function/features than jk2. However the jk2 connector contains documentation on a "jkstatus" administration interface that seems to offer monitoring and (maybe) some management functions. I do not see this in the jk documentation. Is that feature there? Thanks - Richard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Catalina Log File - Coyote can't register jmx for protocol
> From: HockChai Lim [mailto:[EMAIL PROTECTED] > Subject: Catalina Log File - Coyote can't register jmx for protocol > > I'm new to tomcat and java programming. When I start > Tomcat, I see the following in the Catalina Log File. > What is that mean and should I be worried about it? Whatever error or stack trace you were trying to include didn't make it through to the list. Also, please tell us what version of Tomcat you're using, which JDK, which OS, etc. - 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]
Catalina Log File - Coyote can't register jmx for protocol
I'm new to tomcat and java programming. When I start Tomcat, I see the following in the Catalina Log File. What is that mean and should I be worried about it? thanks __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT]Re: logging remote IP address
On Sat, 29 Jan 2005 22:58:01 -0500, Parsons Technical Services > "Not true - the combination of IP address and PORT must be unique, not just > the IP address. This is the essence of how NAT and proxies work." Yes, once again, I agree with this. Jack -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Well, I sure got excited, though. Back to reality! ;-) > What I was getting at is the fact that if I return a page to the browser > that have ten images, all referencing ResourceAction, what's happening > is that the browser is making ten separate requests TO THE APP SERVER, > whereas in a "typical" setup, these requests would be handled by the > fronting web servers. It's clearly more resource-intensive in your > approach. I am not clear what part of the process you are referring to, Frank. We both agree that the first delivery of the page is via the "front server" (I tend to only use the "back server" anyway). If there are ten calls to ten images, as you assume for discussion purposes, then there will be ten calls either way. I think you are saying that in addition there will be a penalty of a pass to a server that can handle Servlets or an equivalent technology that will respond to the ProtocolPage by routing the call to some Action, Command, or whatever in some language, in the way I suggest. Is that right? If so, let me know and we will go from there after you confirm. > Agreed. I do see the advantage of this approach, but it's the minuses > I'm more concerned with. No matter which way you slice it, there's more > server resources being utilized. That's a big minus when your talking > about scalability. I wouild need, as you would too I assume, more information on the actual penalty. I suspect that it is relatively small and, when you introduce sophisticated state and caching options, it may be faster. I don't dismiss what you are saying. Don't get me wrong. I just have learned to get the data and then to see what the real difference is. When considering costs and so on, I am not sure whether the balance goes to which side. I would suspect, from my experience, that software maintenance and so on would clearly outweigh the hardware and associated requirements. > I think you point out some valid advantages... if nothing else, just > doing away with having to deal with URLs is a very good thing. But I > think the performance hit, and certainly the server load, in a "typical" > Enterprise environment, would make this not a great idea. I am surprised at this. You may be right, but my sense is that this difference is not really that important when everything else is taken into account. Even if you had to cluster multiple machines instead of one, say, as a ratio, that would seem to be *probably* cheaper as a GUESS. I don't know. We could look at some data and if you have any handy I would love to see it. > Then again, I say the exact same thing about ASP.Net and JSF because the > whole idea of calling a server for relatively simple UI events strikes > me as a horrible idea until we have far better networks than we have > today, and I seem to be in the minority there, so if I might be wrong > there, I might be wrong here too :) I think the bigger hit is reading the danged thing. This obviously is especially so when there is an ongoing use of changing the JSP page. This has no penalty with ProtocolPages. > My wife wouldn't agree with the listening part :) Well, I bet you are being too humble. I am happy to say that my wife just thinks I am the most adorable, wonderful, guy. Go figure, eh? > I think in enterprise-type environments this is a pretty standard > approach with fairly well agreed upon benefits. Anything that breaks it > has to exceed those benefits. As my father used to say, that's a tough > nut to crack! Nothing wrong with trying to build the hammer though :) Technology seems to get ahead of rumor in our little world of web work. So, I definitely would like to revisit this. I am going to squeeze getting the *facts* in here soon. > Absolutely it is, but as I pointed out, it's being interpreted on the > browser side. That's where the issue comes in to play I think, > especially in a distributed environment. I'd be interested to hear your > thoughts on this point... This seems to be false to me. Maybe I misunderstand you. I don't think the browser has a clue whether we are looking at src='myCss.css' or src='resource.do?file=myCss.css'. Right? Jack -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." - T
Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Dakota Jack wrote: I am going to tell you something that you might have missed. There is no need to have a JSP page to do this. This is NOT dynamic content. This is strictly HTML. I fully understand that. Keep in mind that a recent project I did required that images be served out of a database. To do this I wrote a BLOBServerAction that results in tags like this: (with the query URL encoded of course). This is very much like what you do, except that my BLOBServerAction allows me to serve any BLOB-type from a database. Very similar concept, which is why I know where you are coming from full well. The key here is the use of a PROTOCOL instead of a URL. What happens when you do that is not immediately obvious. Personally, I avoid URLs whenever possible as they merely couple your work to options you probably will frequently wish you did not have to take. Read on! I can't say I understand what your saying here. Can you dumb it down a bit for an old man? :) The ResourceAction requires Struts but does not require JSP. Cool? Remember that Struts has nothing to do with JSP, Velocity, etc. This is pure HTML requiring Struts. Absolutely. Putting everything under WEB-INF removes this choice because every request has to be routed to your app servers now. Surprisingly, perhaps, not so! There is nothing in an HTML page that has the Struts protocol for the ResourceAction code which makes that page dynamic, even though the content is. This is pure HTML. That is why it works so great inside Flash ActionScript too. You cannot, after all, put JSP inside Flash ActionScript. What I was getting at is the fact that if I return a page to the browser that have ten images, all referencing ResourceAction, what's happening is that the browser is making ten separate requests TO THE APP SERVER, whereas in a "typical" setup, these requests would be handled by the fronting web servers. It's clearly more resource-intensive in your approach. As I said before, if your environment is a single server anyway, even if you have a web server in front of an app server, this probably doesn't make much difference, although it will always make some becuase the app server is involved instead of just the web server. That was my original point. Frankly, no pun intended, Frank, I have considered doing all tags via something like this and through Struts Actions. That would mean that your page designers would have freedom you could not believe and that the same pages could work for any backend language. Agreed. I do see the advantage of this approach, but it's the minuses I'm more concerned with. No matter which way you slice it, there's more server resources being utilized. That's a big minus when your talking about scalability. What do you think? I think you point out some valid advantages... if nothing else, just doing away with having to deal with URLs is a very good thing. But I think the performance hit, and certainly the server load, in a "typical" Enterprise environment, would make this not a great idea. Then again, I say the exact same thing about ASP.Net and JSF because the whole idea of calling a server for relatively simple UI events strikes me as a horrible idea until we have far better networks than we have today, and I seem to be in the minority there, so if I might be wrong there, I might be wrong here too :) Don't you know better than to get me talking? ;-) LOL That's why I love talking to you. You not only have a lot to say, you also listen. Nice combination! My wife wouldn't agree with the listening part :) In larger scenarios, the whole point of the web servers (well, most of the point anyway) is to offload that work from the app servers and gain efficiency. Division of labor and all that jazz. :) Agreed, although I would certainly love to see a huge discussion by the mavens in the area on that one. I think that there is more than meets the eye to that. Still, however, agreed! I think in enterprise-type environments this is a pretty standard approach with fairly well agreed upon benefits. Anything that breaks it has to exceed those benefits. As my father used to say, that's a tough nut to crack! Nothing wrong with trying to build the hammer though :) Certainly there are things one would have to do in a distributed environment, but the fact that there is a complete decoupling by using a protocol rather than a URL makes all these problems easily solveable. You can do wonders with this sort of thing which you would never consider prior to doing this. You ought to try it on some project and watch where you will be surprised. This is so efficient and flexible. Remember, the code src='resource.do?file='my.css' is stricly HTML. Absolutely it is, but as I pointed out, it's being interpreted on the browser side. That's where the issue comes in to play I think, especially in a distributed environment. I'd be interested to hear your thoughts on this point
[OT]Re: logging remote IP address
From: Dakota Jack [mailto:[EMAIL PROTECTED] Subject: Re: logging remote IP address The IP address that is exposed to the public, which is the one I use, has to be different or there would be no way to get back to the client machine. Charles Wrote: "Not true - the combination of IP address and PORT must be unique, not just the IP address. This is the essence of how NAT and proxies work." To expand on this, the job of a nat or pat device is not only to re-write the IP in the packet for as you say the packet would never return to the user, but to also keep track of all the connections established out bound and where they come from on the inside. When you make a request you send out a packet. It's destination is port 80 but the source on your machine may be any upper port. So it could look like: Source 192.168.10.31 port 14984 Destination 206.67.68.2 port 80 When the pat/nat devices gets done Source 67.34.126.21 port 44543 Destination 206.67.68.2 port 80 What is critical is that the pat/nat device remembers that: 192.168.10.31 port 14984 equals 67.34.126.21 port 44543 and thus reverses the changes in the packet. If another machine goes out it will get a unique port and thus the pat/nat device can keep track of which one is which. As for what is nat and pat. nat: Network address translation. All inside adresses are converted to one (Masqurade) outside address or one inside address is translated into a specific outside address. With the later your client will alwas have the same address. pat: pooled address translation. Same as Masqurade but done with a pool of addresses to support more clients. Hope this helps. Doug PS I think we left the pavement a long time ago, and thus this would be off topic. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP under /WEB-INF folder PROTOCOL PAGES (ProtocolPages)
Hi, Frank, Always good discussing these matters with you. I think you are going to get a kick out of the turn this reply to your response will get. I AM GOING TO REVEAL WHY I THINK THAT THE BASIC STRUTS ARCHITECTURE, AND .do IN PARTICULAR, IS THE WAVE OF THE FUTURE, NOT THE PAST. [Imagine "Mission Impossible" music in the background.] I have great faith in the Servlet, but not the JSP, idea. I am going to tell you something that you might have missed. There is no need to have a JSP page to do this. This is NOT dynamic content. This is strictly HTML. So, the page that has this is not thereby crippled at all in this sense. There is nothing in using this that changes HTML to JSP or any other dynamic pages. That is the miracle of "returns null;" This is a different kettle of fish. Please note, also that the HTML for the ResourceAction can access any server it wants. This is highly flexible, not staid and bound. ' The key here is the use of a PROTOCOL instead of a URL. What happens when you do that is not immediately obvious. Personally, I avoid URLs whenever possible as they merely couple your work to options you probably will frequently wish you did not have to take. Read on! On Sat, 29 Jan 2005 20:10:08 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Lo, Frank. You really don't lose anything. You just gain a choice. > > There is a lot more to be said on this, but you probably would know > > everything on this anyway, so I will leave it at that. > > That's not strictly true though Jack (neither your premise that you > don't lose anything or that I know everything about this, I almost > certainly don't!)... > > In some environments, as I'm sure you know and probably have even dealt > with, you have a bunch of web servers in front of a bunch of app > servers. The web servers serve static content like images, stylesheets > and usually server-side includes, things like that, while the app server > handles JSPs and actual server-side (servlet) code. The ResourceAction requires Struts but does not require JSP. Cool? Remember that Struts has nothing to do with JSP, Velocity, etc. This is pure HTML requiring Struts. > Putting everything under WEB-INF removes this choice because every > request has to be routed to your app servers now. Surprisingly, perhaps, not so! There is nothing in an HTML page that has the Struts protocol for the ResourceAction code which makes that page dynamic, even though the content is. This is pure HTML. That is why it works so great inside Flash ActionScript too. You cannot, after all, put JSP inside Flash ActionScript. Frankly, no pun intended, Frank, I have considered doing all tags via something like this and through Struts Actions. That would mean that your page designers would have freedom you could not believe and that the same pages could work for any backend language. I have done some dabbling with this and have internally called them ProtoCallPages. I suspect the use of JPP (a sort of Action page language which is based on having to have the code off the page) in conjunction with Servlets is much better than in conjunction with JSP or other tag based ideas. We'll see in time. What do you think? I am sure that there are huge issues to consider but my experience with ResoureAction tells me that things might work out fine. I actually sort of compound JPP with some Struts form tags to get dynamic images with language, size, background and foreground colors (or images), fonts, etc. all dynamic but requiring only a protocol for my part. I have considered just droping the Struts part altogether and keeping JPP doing all the form stuff with pure HTML but with all the dynamic results you get from things like JSP, ASP, etc. Anyway, enough of this. Don't you know better than to get me talking? ;-) LOL That's why I love talking to you. You not only have a lot to say, you also listen. Nice combination! >In larger scenarios, > the whole point of the web servers (well, most of the point anyway) is > to offload that work from the app servers and gain efficiency. Division > of labor and all that jazz. :) Agreed, although I would certainly love to see a huge discussion by the mavens in the area on that one. I think that there is more than meets the eye to that. Still, however, agreed! > I'd certainly agree that if a particular situation doesn't call for such > a distributed environment in the first place, than it's a moot point, > and what you suggest certainly has some benefits. But if that's not the > case, or if it some day might not be the case (i.e., your app might have > to scale into such an environment), then it could become an issue and > people should be aware of it before they make their decision. > > I also don't know what effect this might have in a true distributed > environment (i.e., might it be a problem if one request, say for an > image, is serviced by one machine, while another services the JSP > exe
RE: Updating webapps in a running production cluster.
Peter, I used the Jan 19th version of Tomcat 5.5.7, Apache 2.0.52 (build for ssl), jk 1.2.8, Windows XP SP2 and Sun JRE 1.5 SP1. - Richard Peter Rossbach wrote: > Hello, > > with which tomcat version you test this, please try the new 5.5.7 and > tell us the result! :-) > Please tell us your env, Apache, mod_jk JDK, OS > > Thanx > Peter > > PS: You can find my cluster dev template at > http://tomcat.objektpark.org/examples/05_02_tomcat_example.tar.gz, > Sorry the docs are german and it works with tomcat 5.5.5m jdk 5, > apache > 2.0.52, mod_jk 1.2.8 on Windows/Linux > > Roberto Cosenza schrieb: > >> Sorry if I insist with this post. >> Has anybody succeeded in updating a webapp in a tomcat cluster >> without loosing (any)requests? I´m wondering if this is possible at >> all with tomcat. >> If we don´t provide a solution we are forced to switch to an other >> servlet container :- Does anybody know if moving to Jboss, with >> tomcat as a servlet container, will help? >> >> Thanx >> - Original Message - >> From: "Roberto Cosenza" <[EMAIL PROTECTED]> >> To: "Tomcat Users List" >> Sent: Thursday, January 20, 2005 8:59 PM >> Subject: Re: Updating webapps in a running production cluster. >> >> >> >> >>> We have done some testing in this direction. >>> Two tomcat in a cluster, with session replication. >>> Shutdown B, update B, restart B >>> Shutdown A, update A, restartAB >>> >>> What we experience is that, when shutting down any of the two >>> servers. 1) Few requests are lost (let's say, on our machine, for >>> 0.30 seconds?) 2) Objects stored in the session disappear >>> temporarly, causing eventually annoing npe's. We were wondering if >>> it is possible to achieve an higher reliability but >>> >>> >> we >> >> >>> didn not succeed. >>> /roberto >>> >>> - Original Message - >>> From: "Derrick Koes" <[EMAIL PROTECTED]> >>> To: "Tomcat Users List" >>> Sent: Thursday, January 20, 2005 8:46 PM >>> Subject: RE: Updating webapps in a running production cluster. >>> >>> >>> >>> This is how we update apps in time critical situations. Shut one >>> down and update. Bring it back up. Shut the next down and update. >>> Bring it back >>> >>> >> up >> >> >>> and so on. >>> >>> >>> >>> >>> >>> >>> >>> >>> - >>> 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Updating webapps in a running production cluster.
Roberto Cosenza wrote: > I do mean mod_jk2. Could this be the problem? > /roberto Yes - jk2 is deprecated. From what I understand jk 1.2.8 has all significant function of jk2 and is much more stable/reliable. I am not sure whether it has the "jkstatus" function however. BTW, My tests that showed failover working fine were performed with the Tomcat 5.5.7 from Jan. 19th, 2005. - Richard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP under /WEB-INF folder
> Lo, Frank. You really don't lose anything. You just gain a choice. > There is a lot more to be said on this, but you probably would know > everything on this anyway, so I will leave it at that. That's not strictly true though Jack (neither your premise that you don't lose anything or that I know everything about this, I almost certainly don't!)... In some environments, as I'm sure you know and probably have even dealt with, you have a bunch of web servers in front of a bunch of app servers. The web servers serve static content like images, stylesheets and usually server-side includes, things like that, while the app server handles JSPs and actual server-side (servlet) code. Putting everything under WEB-INF removes this choice because every request has to be routed to your app servers now. In larger scenarios, the whole point of the web servers (well, most of the point anyway) is to offload that work from the app servers and gain efficiency. Division of labor and all that jazz. :) I'd certainly agree that if a particular situation doesn't call for such a distributed environment in the first place, than it's a moot point, and what you suggest certainly has some benefits. But if that's not the case, or if it some day might not be the case (i.e., your app might have to scale into such an environment), then it could become an issue and people should be aware of it before they make their decision. I also don't know what effect this might have in a true distributed environment (i.e., might it be a problem if one request, say for an image, is serviced by one machine, while another services the JSP execuetion itself?). This might never arise, or it might not be a problem at all even if it does, but it could be something for someone to explore is my point. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Dakota Jack wrote: On Sat, 29 Jan 2005 17:17:03 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: One thing worth pointing out about this is that you'll lose the benefit of fronting your app server with a web server... You won't be able to offload the serving of images, stylesheets and such, from the app server to the web server. That's probably not a big problem in many cases where a single server with a decent set of specs can handle the load anyway, but in a more robust "enterprise" environment, your really kind of defeating the purpose of a fleet of web servers in front of a number of app servers. Lo, Frank. You really don't lose anything. You just gain a choice. There is a lot more to be said on this, but you probably would know everything on this anyway, so I will leave it at that. Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updating webapps in a running production cluster.
I am not sure which app server you are thiking of switching to, but I work for a Fortune 500 which uses Webspere, Weblogic and Tomcat. And ALL of them have issues with sessions getting lost during restarts. There just is no way around it. There will be requests lost in the very small window wherein the requests to the server going down all of a sudden will stop responding. If there are any connections to the container, they will be hung for a a period of time (I have noticed around 20-40 seconds). It happens. One way of mitigating this is to only bounce during off hours. We have windows really late at night or early morning (depeding on regions served). One other thing that might get you where you need to go is to turn on servlet reloading. This will cause a hit in performance (and is not recommended for production environments), but when a servlet is changed, Tomcat will reload it. This will cause a check every request to a servlet to see if it has changed (at least, that is what happens with 4.x). Ben Ricker On Sat, 29 Jan 2005 09:47:28 +0100, Roberto Cosenza <[EMAIL PROTECTED]> wrote: > Sorry if I insist with this post. > Has anybody succeeded in updating a webapp in a tomcat cluster without > loosing (any)requests? > I´m wondering if this is possible at all with tomcat. > If we don´t provide a solution we are forced to switch to an other servlet > container :- > Does anybody know if moving to Jboss, with tomcat as a servlet container, > will help? > > Thanx > - Original Message - > From: "Roberto Cosenza" <[EMAIL PROTECTED]> > To: "Tomcat Users List" > Sent: Thursday, January 20, 2005 8:59 PM > Subject: Re: Updating webapps in a running production cluster. > > > We have done some testing in this direction. > > Two tomcat in a cluster, with session replication. > > Shutdown B, update B, restart B > > Shutdown A, update A, restartAB > > > > What we experience is that, when shutting down any of the two servers. > > 1) Few requests are lost (let's say, on our machine, for 0.30 seconds?) > > 2) Objects stored in the session disappear temporarly, causing eventually > > annoing npe's. > > We were wondering if it is possible to achieve an higher reliability but > we > > didn not succeed. > > /roberto > > > > - Original Message - > > From: "Derrick Koes" <[EMAIL PROTECTED]> > > To: "Tomcat Users List" > > Sent: Thursday, January 20, 2005 8:46 PM > > Subject: RE: Updating webapps in a running production cluster. > > > > > > > > This is how we update apps in time critical situations. Shut one down and > > update. Bring it back up. Shut the next down and update. Bring it back > up > > and so on. > > > > > > > > > > > > > > > > > > - > > 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] > > -- Ben Ricker He's just this guy, you know? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP under /WEB-INF folder
On Sat, 29 Jan 2005 17:17:03 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > One thing worth pointing out about this is that you'll lose the benefit > of fronting your app server with a web server... You won't be able to > offload the serving of images, stylesheets and such, from the app server > to the web server. That's probably not a big problem in many cases > where a single server with a decent set of specs can handle the load > anyway, but in a more robust "enterprise" environment, your really kind > of defeating the purpose of a fleet of web servers in front of a number > of app servers. Lo, Frank. You really don't lose anything. You just gain a choice. There is a lot more to be said on this, but you probably would know everything on this anyway, so I will leave it at that. Jack -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: configure: error: Unsupported operating system "freebsd5.3"
> From: Bagus [mailto:[EMAIL PROTECTED] > Subject: configure: error: Unsupported operating system "freebsd5.3" > > Hmm... I guess I'm not even sure if I should be running Jakarta > as a daemon as the first page of the set up recommends. First, it's not "Jakarta", it's Tomcat. Jakarta is the cover name for the multitude of Java-based products developed by the Apache Software Foundation. Second, you probably shouldn't try running Tomcat as a daemon until after you've gotten your feet wet. It's unfortunate that the setup documentation drops people into the deep end before they need to go there. All you really need to do is download the desired Tomcat version, unzip or untar it (use a GNU-compatible tar tool for those versions), then consult the RUNNING.txt file. If you can't move up to the 1.5 JRE (or 5.0, whatever Sun is calling it this week), you'll also need to download the Compat package and install it. For your first attempts, use the installation directory defaults; you can move things around later after you have some experience. You do not need anything else installed just to exercise Tomcat. > Also, just wondering, why come isn't there a single > installation system that sets all of this up for me? > Ant, Jakarta, Struts, Cocoon, etc. Because they're different products from different authors/vendors. Use Google and the numerous FAQs and mail archives to get help on configuring these together, should you actually want to use them. But as stated earlier, you don't need anything beyond the basic Tomcat download to play with JSPs and servlets. - 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]
Re: JSP under /WEB-INF folder
One thing worth pointing out about this is that you'll lose the benefit
of fronting your app server with a web server... You won't be able to
offload the serving of images, stylesheets and such, from the app server
to the web server. That's probably not a big problem in many cases
where a single server with a decent set of specs can handle the load
anyway, but in a more robust "enterprise" environment, your really kind
of defeating the purpose of a fleet of web servers in front of a number
of app servers.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Dakota Jack wrote:
On Sat, 29 Jan 2005 09:00:39 -0500, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
Just from a curiosity standpoint Jack... I've already decided it's not
an approach I'd advocate, but I am interested to know how you serve
things like graphics and stylesheets from under WEB-INF. I assume all
your graphics are actually server by an Action (a trick I've pulled when
serving images from a database), and I further assume your stylesheets
aren't just linked in...
You can also put this sort of Struts protocol into Flash ActionScript, etc.
To be complete on this list:
public final class ResourceAction
extends Action {
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException,
ServletException {
String file = request.getParameter("file");
String ext = file.substring(file.lastIndexOf('.') + 1);
String type = null;
String path = null;
if ("gif".equals(ext)) {
type = "image/gif";
path = path("gif");
} else if ("jpg".equals(ext)) {
type = "image/jpeg";
path = path("jpeg");
} else if ("css".equals(ext)) {
type = "text/css";
path = path("css");
} else if ("flash".equals(ext)) {
type = "application/x-shockwave-flash";
path = path("flash");
} else if ("text".equals(ext)) {
type = "text/plain";
path = path("text");
} else if ("js".equals(ext)) {
type = "text/javascript";
path = path("js");
} else if ("png".equals(ext)) {
type = "image/png";
path = path("png");
} else if ("html".equals(ext)) {
type = "text/html";
path = path("html");
} else if ("applet".equals(ext)) {
type = "application/x-java-applet";
path = "classes" + File.separator + "com" + File.separator +
"crackwillow" + File.separator + "applet";
}
String name = Classpath.WEB_INF + path + file;
response.setContentType(type);
response.setHeader("Cache-Control", "");
response.setHeader("Pragma", "");
response.setHeader("Expires", "");
response.addHeader("Content-Disposition","filename=" + name);
try {
FileInputStream fis = new FileInputStream(name);
BufferedInputStream bis = new BufferedInputStream(fis);
byte[] bytes = new byte[bis.available()];
OutputStreamos= response.getOutputStream();
bis.read(bytes);
os.write(bytes);
os.flush();
os.close();
} catch (IOException ioe) {
StdOut.log(SiteConstant.ERROR_LOG,"ResourceAction: problem file
is: " + name + "\n" + StackTrace.trace(ioe) + "\n" +
ioe.getMessage());
}
return null;
}
private String path(String fileType) {
return "resource" + File.separator + "content_type" +
File.separator + fileType + File.separator;
}
} ///;-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
configure: error: Unsupported operating system "freebsd5.3"
Hi there, Any idea why I might get that error on running configure from my $CATALINA_HOME/bin/jsvc_src/ directory? I'm a newbie and this is my first Jakarta-tomcat installation. This is the first step I've taken since getting my jdk1.4.2 running on my new FreeBSD 5.3 box. It's like this: [root][/usr/local/jakarta-tomcat-5.5.4/bin/jsvc-src]: ./configure *** Current host *** checking build system type... i386-unknown-freebsd5.3 checking host system type... i386-unknown-freebsd5.3 checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib *** Java compilation tools *** checking for javac... /usr/local/jdk1.4.2/bin/javac checking wether the Java compiler (/usr/local/jdk1.4.2/bin/javac) works... yes checking for jar... /usr/local/jdk1.4.2/bin/jar *** Host support *** checking C flags dependant on host system type... failed configure: error: Unsupported operating system "freebsd5.3" Hmm... I guess I'm not even sure if I should be running Jakarta as a daemon as the first page of the set up recommends. http://jakarta.apache.org/tomcat/tomcat-5.5-doc/setup.html Do I need to do that configuration at all? I noticed this page doesn't have the jsvc stuff: http://www.coreservlets.com/Apache-Tomcat-Tutorial/#Introduction Ok, and while I'm chiefly concerned with why I get the error message mentioned in the subject, I'm beginning to see that I'm in deeper than I thought: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/appdev/installation.html Says I have to have Ant and a bunch of other stuff in place before I can have a jsp page that can query my mysql database. Is this true? If this is the case, what does a standalone jakarta-tomcat installation get you? Also, just wondering, why come isn't there a single installation system that sets all of this up for me? Ant, Jakarta, Struts, Cocoon, etc. I'm a little overwhelmed... but determined. Thanks, Bagus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updating webapps in a running production cluster.
I do mean mod_jk2. Could this be the problem? /roberto - Original Message - From: "Peter Rossbach" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Saturday, January 29, 2005 10:42 PM Subject: Re: Updating webapps in a running production cluster. Please update to Apache 2.0.52 and I hope you mean mod_jk 1.2.8 not a mod_jk2 Regards Peter Roberto Cosenza schrieb: >We used : >jakarta-tomcat-5.5.4 >apache 2.0.49 >mod_jk2 (jakarta-tomcat-connectors-1.2.8-src) >Linux webster2 2.4.26 #11 SMP Thu Apr 22 13:16:46 CEST 2004 i686 i686 i386 >GNU/Linux >jdk-1_5_0_01-linux-i586.bin >CATALINA_OPTS='-Xmx512m -Xms256m -XX:MaxPermSize=256M' > >I will test a new version and let you know. > >- Original Message - >From: "Peter Rossbach" <[EMAIL PROTECTED]> >To: "Tomcat Users List" >Sent: Saturday, January 29, 2005 8:04 PM >Subject: Re: Updating webapps in a running production cluster. > > >Hello, > >with which tomcat version you test this, please try the new 5.5.7 and >tell us the result! :-) >Please tell us your env, Apache, mod_jk JDK, OS > >Thanx >Peter > >PS: You can find my cluster dev template at >http://tomcat.objektpark.org/examples/05_02_tomcat_example.tar.gz, >Sorry the docs are german and it works with tomcat 5.5.5m jdk 5, apache >2.0.52, mod_jk 1.2.8 on Windows/Linux > >Roberto Cosenza schrieb: > > > >>Sorry if I insist with this post. >>Has anybody succeeded in updating a webapp in a tomcat cluster without >>loosing (any)requests? >>I´m wondering if this is possible at all with tomcat. >>If we don´t provide a solution we are forced to switch to an other servlet >>container :- >>Does anybody know if moving to Jboss, with tomcat as a servlet container, >>will help? >> >>Thanx >>- Original Message - >>From: "Roberto Cosenza" <[EMAIL PROTECTED]> >>To: "Tomcat Users List" >>Sent: Thursday, January 20, 2005 8:59 PM >>Subject: Re: Updating webapps in a running production cluster. >> >> >> >> >> >> >>>We have done some testing in this direction. >>>Two tomcat in a cluster, with session replication. >>>Shutdown B, update B, restart B >>>Shutdown A, update A, restartAB >>> >>>What we experience is that, when shutting down any of the two servers. >>>1) Few requests are lost (let's say, on our machine, for 0.30 seconds?) >>>2) Objects stored in the session disappear temporarly, causing eventually >>>annoing npe's. >>>We were wondering if it is possible to achieve an higher reliability but >>> >>> >>> >>> >>we >> >> >> > > > > >- >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: Updating webapps in a running production cluster.
Please update to Apache 2.0.52 and I hope you mean mod_jk 1.2.8 not a mod_jk2 Regards Peter Roberto Cosenza schrieb: We used : jakarta-tomcat-5.5.4 apache 2.0.49 mod_jk2 (jakarta-tomcat-connectors-1.2.8-src) Linux webster2 2.4.26 #11 SMP Thu Apr 22 13:16:46 CEST 2004 i686 i686 i386 GNU/Linux jdk-1_5_0_01-linux-i586.bin CATALINA_OPTS='-Xmx512m -Xms256m -XX:MaxPermSize=256M' I will test a new version and let you know. - Original Message - From: "Peter Rossbach" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Saturday, January 29, 2005 8:04 PM Subject: Re: Updating webapps in a running production cluster. Hello, with which tomcat version you test this, please try the new 5.5.7 and tell us the result! :-) Please tell us your env, Apache, mod_jk JDK, OS Thanx Peter PS: You can find my cluster dev template at http://tomcat.objektpark.org/examples/05_02_tomcat_example.tar.gz, Sorry the docs are german and it works with tomcat 5.5.5m jdk 5, apache 2.0.52, mod_jk 1.2.8 on Windows/Linux Roberto Cosenza schrieb: Sorry if I insist with this post. Has anybody succeeded in updating a webapp in a tomcat cluster without loosing (any)requests? I´m wondering if this is possible at all with tomcat. If we don´t provide a solution we are forced to switch to an other servlet container :- Does anybody know if moving to Jboss, with tomcat as a servlet container, will help? Thanx - Original Message - From: "Roberto Cosenza" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Thursday, January 20, 2005 8:59 PM Subject: Re: Updating webapps in a running production cluster. We have done some testing in this direction. Two tomcat in a cluster, with session replication. Shutdown B, update B, restart B Shutdown A, update A, restartAB What we experience is that, when shutting down any of the two servers. 1) Few requests are lost (let's say, on our machine, for 0.30 seconds?) 2) Objects stored in the session disappear temporarly, causing eventually annoing npe's. We were wondering if it is possible to achieve an higher reliability but we - 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: Updating webapps in a running production cluster.
We used : jakarta-tomcat-5.5.4 apache 2.0.49 mod_jk2 (jakarta-tomcat-connectors-1.2.8-src) Linux webster2 2.4.26 #11 SMP Thu Apr 22 13:16:46 CEST 2004 i686 i686 i386 GNU/Linux jdk-1_5_0_01-linux-i586.bin CATALINA_OPTS='-Xmx512m -Xms256m -XX:MaxPermSize=256M' I will test a new version and let you know. - Original Message - From: "Peter Rossbach" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Saturday, January 29, 2005 8:04 PM Subject: Re: Updating webapps in a running production cluster. Hello, with which tomcat version you test this, please try the new 5.5.7 and tell us the result! :-) Please tell us your env, Apache, mod_jk JDK, OS Thanx Peter PS: You can find my cluster dev template at http://tomcat.objektpark.org/examples/05_02_tomcat_example.tar.gz, Sorry the docs are german and it works with tomcat 5.5.5m jdk 5, apache 2.0.52, mod_jk 1.2.8 on Windows/Linux Roberto Cosenza schrieb: >Sorry if I insist with this post. >Has anybody succeeded in updating a webapp in a tomcat cluster without >loosing (any)requests? >I´m wondering if this is possible at all with tomcat. >If we don´t provide a solution we are forced to switch to an other servlet >container :- >Does anybody know if moving to Jboss, with tomcat as a servlet container, >will help? > >Thanx >- Original Message - >From: "Roberto Cosenza" <[EMAIL PROTECTED]> >To: "Tomcat Users List" >Sent: Thursday, January 20, 2005 8:59 PM >Subject: Re: Updating webapps in a running production cluster. > > > > >>We have done some testing in this direction. >>Two tomcat in a cluster, with session replication. >>Shutdown B, update B, restart B >>Shutdown A, update A, restartAB >> >>What we experience is that, when shutting down any of the two servers. >>1) Few requests are lost (let's say, on our machine, for 0.30 seconds?) >>2) Objects stored in the session disappear temporarly, causing eventually >>annoing npe's. >>We were wondering if it is possible to achieve an higher reliability but >> >> >we > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Freezes unexpectedly
In the end, It had nothing to do with Tomcat. Just for the record, the problem was the JTDS JDBC Driver combined with the DBCP Pooling. Looks like JTDS doesn't like pooling that much... we switched to antother driver and everything went all right. Thanks !!! VTR Ravi Kumar wrote: > > This might be something related to number of simultaneous users increasing > some threshold. > > Similar thing happens in our intranet server also and at that time a message > like Internal Server Error. Your servlet container is bing upgraded ... > appears. > > VTR Ravi Kumar. > > > > Diego Espada wrote: > >> Hi, >> >> we are having a serious problem with Tomcat 5.0.27. We have a web server in production that is supposed to be 7x24, but it keeps hanging after a few hours with no apparent cause. We have to keep restarting it. One time, Tomcat logged that it was running out of threads (150), so I changed this value to 2000 in the xml server config file and only seemed to make things worse... now it hangs more often that before, probably twice a day or more. >> >> The hangup does not follow any pattern... it can be at any moment in the day, some days it doesn't hang and some days it hangs three or four times. >> >> The log doesn't say anything useful. It seems that Tomcat just stops logging after the hang up occurs. >> >> My Tomcat is deployed on a Windows 2000 Server with jdk 1.4.2_05 as a service. It is not using the server jvm yet. >> Any configurations I should look ? any optimizations ? any clues ? >> >> 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updating webapps in a running production cluster.
Hello, with which tomcat version you test this, please try the new 5.5.7 and tell us the result! :-) Please tell us your env, Apache, mod_jk JDK, OS Thanx Peter PS: You can find my cluster dev template at http://tomcat.objektpark.org/examples/05_02_tomcat_example.tar.gz, Sorry the docs are german and it works with tomcat 5.5.5m jdk 5, apache 2.0.52, mod_jk 1.2.8 on Windows/Linux Roberto Cosenza schrieb: Sorry if I insist with this post. Has anybody succeeded in updating a webapp in a tomcat cluster without loosing (any)requests? I´m wondering if this is possible at all with tomcat. If we don´t provide a solution we are forced to switch to an other servlet container :- Does anybody know if moving to Jboss, with tomcat as a servlet container, will help? Thanx - Original Message - From: "Roberto Cosenza" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Thursday, January 20, 2005 8:59 PM Subject: Re: Updating webapps in a running production cluster. We have done some testing in this direction. Two tomcat in a cluster, with session replication. Shutdown B, update B, restart B Shutdown A, update A, restartAB What we experience is that, when shutting down any of the two servers. 1) Few requests are lost (let's say, on our machine, for 0.30 seconds?) 2) Objects stored in the session disappear temporarly, causing eventually annoing npe's. We were wondering if it is possible to achieve an higher reliability but we didn not succeed. /roberto - Original Message - From: "Derrick Koes" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Thursday, January 20, 2005 8:46 PM Subject: RE: Updating webapps in a running production cluster. This is how we update apps in time critical situations. Shut one down and update. Bring it back up. Shut the next down and update. Bring it back up and so on. - 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: commons-loggin instead of loggers
Put log4j-1.2.9.jar and commons-logging-1.0.4.jar (not
commons-logging-api.jar!!) in CATALINA_HOME/common/lib and
log4j.properties in CATALINA_HOME/common/classes and make the properties
file look something like...
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-5p[%-8.8t]: %39.39c %-6r - %m%n
log4j.appender.LOCALHOST=org.apache.log4j.RollingFileAppender
log4j.appender.LOCALHOST.File=${catalina.home}/logs/localhost.log
log4j.appender.LOCALHOST.MaxFileSize=1000KB
log4j.appender.LOCALHOST.MaxBackupIndex=1
log4j.appender.LOCALHOST.layout=org.apache.log4j.PatternLayout
log4j.appender.LOCALHOST.layout.ConversionPattern=%-5p[%-8.8t]: %39.39c
%-6r - %m%n
log4j.appender.MYAPP=org.apache.log4j.DailyRollingFileAppender
log4j.appender.MYAPP.File=${catalina.home}/logs/localhost_myapp.log
log4j.appender.MYAPP.DatePattern='.'-MM-dd
log4j.appender.MYAPP.layout=org.apache.log4j.PatternLayout
log4j.appender.MYAPP.layout.ConversionPattern=%c{1} %-6r - %m%n
log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost]=INFO,
LOCALHOST
log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost]=false
log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/myapp]=INFO,
MYAPP
log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/myapp]=false
log4j.rootLogger=INFO, A1
Don't try using a log4j.xml file. The logger names above are illegal id
attribute values and will cause an XML parsing error. The "name"
attribute is defined as of type "id" in the log4j.dtd. This won't be an
issue in Log4j-1.3 but still is, and will always be, in Log4j-1.2.x.
BTW, Valves are like Filters, but at the server level rather than at the
application level. The fact that a Valve might log something doesn't make
it a logger itself.
Jake
At 06:58 PM 1/29/2005 +0100, you wrote:
>Hi,
>
>Loggers seems to have disappeared since 5.5 release
>It seems that we must use commons-loggin
>
>Does someone have an example to replace my classical logger which was in
>my context
>
> prefix="myappli_log." suffix=".txt" timestamp="true"/>
>
>
>
>PS: What is exactly the diff between a Logger and a Valve ? It seems to
>cover the same things ?
>
>
>
>Phil
>
>-
>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: logging remote IP address
> From: Dakota Jack [mailto:[EMAIL PROTECTED] > Subject: Re: logging remote IP address > > The IP address that is exposed to the public, which is > the one I use, has to be different or there would be no > way to get back to the client machine. Not true - the combination of IP address and PORT must be unique, not just the IP address. This is the essence of how NAT and proxies work. - 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]
RE: Updating webapps in a running production cluster.
Roberto Cosenza wrote: > Sorry if I insist with this post. > Has anybody succeeded in updating a webapp in a tomcat cluster > without loosing (any)requests? > I´m wondering if this is possible at all with tomcat. > If we don´t provide a solution we are forced to switch to an other > servlet container :- > Does anybody know if moving to Jboss, with tomcat as a servlet > container, will help? Roberto, The short answer is yes, if you use Tomcat 5.x session replication and failover loadbalancing such as the JK connector. Please check the thread titled: "JK, Session Replication/Clustering, SSL and failover in Tomcat 5" - it documents some of the configuration needed for this to happen. I have tested this and when one Tomcat instance fails, all sessions and requests fail over seamlessly - the user is not prompted login again, etc. That said, I am having a problem on session synchronization when the failed or shutdown instance is restarted and needs to replicate all of the sessions back. Filip Hanik is looking into this further. HTH - Richard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat'evolution abstract
On Sat, 29 Jan 2005 19:02:25 +0100, Philippe Mathieu <[EMAIL PROTECTED]> wrote: > Hi, > I'm a little bit lost in the releases; > Does anyone could tell me precisely since which release ... : > > - Tomcat takes account of JSP 2.0 ? 5.0+ > - Realms are integrated in Tomcat ? 4.0+ (with API changes) > - DBCP (pools) are integrated in Tomcat ? 4.1+ > - the invoker servlet in not set by default ? (4.1.12 ?) Yes. > - The DataSourceRealm is integrated in Tomcat ? 4.1.something > - Context description can be put directly in catalina/localhost ? 5.0.0+ > - DBCP syntax has been changed ? (5.5.4 ?) 5.5.0+ > - loggers have disappeared ? (5.5.4 ?) 5.5.0+ > - JDK 1.5 compliant ? (5.5.4 ?) 5.5.0+ - Removal of DefaultContext (replaced by conf/context.xml and other per host files) 5.5.0+ - JDT as the JSP code compiler 5.5.0+ (but it had very serious bugs in that build ;) ) -- x Rémy Maucherat Developer & Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logging remote IP address
On Fri, 28 Jan 2005 20:43:20 -0500, Parsons Technical Services <[EMAIL PROTECTED]> wrote: > Definitely possible. Not as unlikely as you think. I know of shops that put > a whole bunch of users on the same IP. > > Then there are schools that put a hundreds of classroom machines on one IP. > > Doug If you remember the context in which I am working here, this is not so clear. I know why you think it is and from the context in which you are talking, I understand why you say that. However, remember that each person or machine that has access to a server in order to make a request must be uniquely identified or that person or machine cannot get a response. This could take quite a while to discuss, actually. The IP address that is exposed to the public, which is the one I use, has to be different or there would be no way to get back to the client machine. So, we may be talking about same IP in a different sense. Remember that distinctions you may be making in URLs I am making in IPs. There might not even be a URL (i.e. non-number URI) in my case. Jack -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP under /WEB-INF folder
On Sat, 29 Jan 2005 09:00:39 -0500, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> Just from a curiosity standpoint Jack... I've already decided it's not
> an approach I'd advocate, but I am interested to know how you serve
> things like graphics and stylesheets from under WEB-INF. I assume all
> your graphics are actually server by an Action (a trick I've pulled when
> serving images from a database), and I further assume your stylesheets
> aren't just linked in...
You can also put this sort of Struts protocol into Flash ActionScript, etc.
To be complete on this list:
public final class ResourceAction
extends Action {
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException,
ServletException {
String file = request.getParameter("file");
String ext = file.substring(file.lastIndexOf('.') + 1);
String type = null;
String path = null;
if ("gif".equals(ext)) {
type = "image/gif";
path = path("gif");
} else if ("jpg".equals(ext)) {
type = "image/jpeg";
path = path("jpeg");
} else if ("css".equals(ext)) {
type = "text/css";
path = path("css");
} else if ("flash".equals(ext)) {
type = "application/x-shockwave-flash";
path = path("flash");
} else if ("text".equals(ext)) {
type = "text/plain";
path = path("text");
} else if ("js".equals(ext)) {
type = "text/javascript";
path = path("js");
} else if ("png".equals(ext)) {
type = "image/png";
path = path("png");
} else if ("html".equals(ext)) {
type = "text/html";
path = path("html");
} else if ("applet".equals(ext)) {
type = "application/x-java-applet";
path = "classes" + File.separator + "com" + File.separator +
"crackwillow" + File.separator + "applet";
}
String name = Classpath.WEB_INF + path + file;
response.setContentType(type);
response.setHeader("Cache-Control", "");
response.setHeader("Pragma", "");
response.setHeader("Expires", "");
response.addHeader("Content-Disposition","filename=" + name);
try {
FileInputStream fis = new FileInputStream(name);
BufferedInputStream bis = new BufferedInputStream(fis);
byte[] bytes = new byte[bis.available()];
OutputStreamos= response.getOutputStream();
bis.read(bytes);
os.write(bytes);
os.flush();
os.close();
} catch (IOException ioe) {
StdOut.log(SiteConstant.ERROR_LOG,"ResourceAction: problem file
is: " + name + "\n" + StackTrace.trace(ioe) + "\n" +
ioe.getMessage());
}
return null;
}
private String path(String fileType) {
return "resource" + File.separator + "content_type" +
File.separator + fileType + File.separator;
}
} ///;-)
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be
crows. We are poor . . . but we are free."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat'evolution abstract
Hi, I'm a little bit lost in the releases; Does anyone could tell me precisely since which release ... : - Tomcat takes account of JSP 2.0 ? - Realms are integrated in Tomcat ? - DBCP (pools) are integrated in Tomcat ? - the invoker servlet in not set by default ? (4.1.12 ?) - The DataSourceRealm is integrated in Tomcat ? - Context description can be put directly in catalina/localhost ? - DBCP syntax has been changed ? (5.5.4 ?) - loggers have disappeared ? (5.5.4 ?) - JDK 1.5 compliant ? (5.5.4 ?) Knowing these answers will help me to help the others ;-) -- Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
commons-loggin instead of loggers
Hi, Loggers seems to have disappeared since 5.5 release It seems that we must use commons-loggin Does someone have an example to replace my classical logger which was in my context prefix="myappli_log." suffix=".txt" timestamp="true"/> PS: What is exactly the diff between a Logger and a Valve ? It seems to cover the same things ? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP under /WEB-INF folder
Just from a curiosity standpoint Jack... I've already decided it's not an approach I'd advocate, but I am interested to know how you serve things like graphics and stylesheets from under WEB-INF. I assume all your graphics are actually server by an Action (a trick I've pulled when serving images from a database), and I further assume your stylesheets aren't just linked in... -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Dakota Jack wrote: On Tue, 28 Dec 2004 13:57:33 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: I think his problem is probably linking to stylesheets and such... Actually, now I have to ask you... if you put *everything* under WEB-INF, I assume you are serving all graphics from a fronting web server then? Otherwise, any document returned to the user that links back to a resource under WEB-INF won't be reachable, which was the crux of his problem as I understood it, that's why he was talking about includes and such all over the place. But, if you really are serving everything from there, how are you doing it? Just curious at this point :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Dakota Jack wrote: I don't know why you are saying that css and/or js must be placed directly under "WebRoot". Why do you? I can give you various solutions, once I find out what the problem is supposed to be. There is no issue, by the way, with putting your JSP files under WEB-INF. There are other ways to protect access, but this is, I think, a good one too. Jack Frank, are you still interested in this? I just noticed it. Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logging remote IP address
Mark wrote: I'm just tring to see if http request that came from one IP address has more then 1 client behind it. I've seen on some webpages that My IP is displayed as both external and internal - so it means it's doable - but the question is how to get this info in Tomcat. If your local an your external (NATed) IP addresses are both displayed by a webpage you access, you are almost certainly accessing this site via a proxy that set the "X-Forwarded-For" HTTP-header-field to contain your local IP (the IP the proxy itself was accessed from). But that's nothing you can rely on. Regards mks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tomcat-5.0.27 authentication/authorization
Hi. You can find discusion here: http://groups-beta.google.com/group/comp.lang.java.programmer tomcat-5.0.27 authentication/authorization http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/d86b1db12a57638d/1532ba9c63e42da3?q=tomcat-5.0.27+authentication%2Fauthorization&_done=%2Fgroup%2Fcomp.lang.java.programmer%2Fsearch%3Fgroup%3Dcomp.lang.java.programmer%26q%3Dtomcat-5.0.27+authentication%2Fauthorization%26qt_g%3D1%26searchnow%3DSearch+this+group%26&_doneTitle=Back+to+Search&&d#1532ba9c63e42da3 Hi all. Tomcat, and any other servlet server, when we use "FORM" with j_security_check, j_username, j_password and , check our user name and password against database (or anything else - but this wasn't important now) and then PUT_SOMETHING_FOR_RECOGNITION_SOMEWHERE (I think in servlet session?) for repossess. After that we can access resource specified in if we have THAT_SOMETHING (role). And THAT_SOMETHING will be passed automatically to EJB if we use EJB, and so on.. Is it possible to put THAT_SOMETHING from my code i.e. servlet? For example, if I want to use in JSP other name for j_security_check, j_username, j_password, or I want to use other presentation for my web app like Swing or simmilar? I could check user name or anything else by myself and then put THAT_SOMETHING and proceed like I was make real j_security_check. Do you know how to do this? P.S. I can't use JAAS. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updating webapps in a running production cluster.
Sorry if I insist with this post. Has anybody succeeded in updating a webapp in a tomcat cluster without loosing (any)requests? I´m wondering if this is possible at all with tomcat. If we don´t provide a solution we are forced to switch to an other servlet container :- Does anybody know if moving to Jboss, with tomcat as a servlet container, will help? Thanx - Original Message - From: "Roberto Cosenza" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Thursday, January 20, 2005 8:59 PM Subject: Re: Updating webapps in a running production cluster. > We have done some testing in this direction. > Two tomcat in a cluster, with session replication. > Shutdown B, update B, restart B > Shutdown A, update A, restartAB > > What we experience is that, when shutting down any of the two servers. > 1) Few requests are lost (let's say, on our machine, for 0.30 seconds?) > 2) Objects stored in the session disappear temporarly, causing eventually > annoing npe's. > We were wondering if it is possible to achieve an higher reliability but we > didn not succeed. > /roberto > > - Original Message - > From: "Derrick Koes" <[EMAIL PROTECTED]> > To: "Tomcat Users List" > Sent: Thursday, January 20, 2005 8:46 PM > Subject: RE: Updating webapps in a running production cluster. > > > > This is how we update apps in time critical situations. Shut one down and > update. Bring it back up. Shut the next down and update. Bring it back up > and so on. > > > > > > > > > - > 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]
