Re: [OT] Memory Leak in Tomcat
I know it has its advantages, that's why I used it :] but if the memory leak will continue, and I won't figure it out, I think I'd have to start looking for alternate possibilities Thanks Hila 2011/2/24 Jeffrey Janner jeffrey.jan...@polydyne.com -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, February 23, 2011 10:11 AM To: Tomcat Users List Subject: Re: [OT] Memory Leak in Tomcat -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 הילה, On 2/23/2011 10:51 AM, הילה - צוות אגורה wrote: the user that runs the tomcat service is a domain user, but I specify the user name and password of this user under log on tab on the service properties. it's not a problem since the password is encrypted, but in the xml file it's in clear text. It's a good thing those credentials don't need to be decrypted in order to be used. Congratulations: you've covered your ass. Not sure exactly what Windows does once you've entered a verified user/pw combination for a service. I'm guessing that it stores the password somehow, because if you change the password, the service won't start next time. However, this is a nice (?) feature of using SQL Server. Already validated user credentials can be passed by the OS to SQL Server to be validated for database logon. It's their version of SSO for the database. (Note: I don't find it an overwhelming advantage for determining to use that specific database software.) __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
Re: [OT] Memory Leak in Tomcat
I'll try to check what you suggested. sounds like something that maybe shed some light on this issue. Thanks :] 2011/2/23 André Warnier a...@ice-sa.com הילה wrote: Yes, I've read you other mail about the Jprofiler. I've run the Jprofiler for a weak until it generated a stuck process on the DB and crashed the application (even though it ran on the app server, and not the DB server) I'm not too familiar with Tomcat tweaks and java monitoring, so i'll try to go over your mail again and see if I can extract from it something that I can work with :] I hate to barge in (again?) in what is starting to look like a nice slinging match, but I think that we have already pretty much established that the memory leak, if any, happens in the jDTS (?) driver and/or the ntlmauth.dll that it is using, and not in Tomcat code. If it is in the ntlmauth.dll, I doubt that any Java tool will show anything. הילה, how exactly are you seeing that the Tomcat process is leaking memory ? With the MS Task Manager ? And, where exactly does that ntlmauth.dll come from ? @Chris : Apparently, the database being used accepts either plain text authentication, or NTLM authentication. And apparently also, the setup is such that in either case, the login to the database is done using a single user-id, provided by Tomcat. One can discuss if this is, in the general scheme of things, an appropriate way in terms of security of access to the data in the database. But in the case of plain text authentication, the user-id and password used are stored in a Tomcat configuration file, in plain text. In the case of the NTLM authentication, the user-id under which tomcat runs can be easily discovered, but the password cannot. So I would think that in that limited sense, using NTLM offers an improvement. Now of course if at the same time, a bug in the jDTS driver or the ntlmauth.dll causes the Tomcat process to need more and more memory over time, the advantage is less evident. To nevertheless make some progress at identifying the culprit, I suggest the following procedure : Leave the user-id under which Tomcat itself is running as it is, using the Windows Domain user. Also leave the database as it is. But change back the authentication used for the database, to the plain-text setting. This way, the jDTS driver will still be there, but it will no longer be using the additional dll, and will authenticate to the DB with the plain-text user-id and password. Then check if the Tomcat process is still leaking memory. If it is not, then you know for sure that the leak is in ntlmauth.dll (or in the jDTS driver, but only when it using NTLM authentication). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance Tuning Tomcat 7...
On 24/02/2011 06:42, Tony Anecito wrote: Hi Mark, I setup a simple servlet with no code in the doGet() method running in Tomcat 7.0.8 and using jvm 1.6.22 and using httpclient from apache commons lib and I am lucky to get 2.8msec per request as measured at the client. I am thinking the commons httpclient is slow itself. So what did you use for the client side? I was using JMeter. Key configuration was: - servlet that did nothing - http keepalive enabled - dual core test machine - single JMeter thread - all on localhost The above configuration meant that there was only a single thread used on Tomcat. The results on OSX were *much* better than those on Windows although I don't recall the details. Also, I looked at the test results someone ran using Apache httpclient and they took the total number of requests and the time it took to run and came out with an absurd number because the response times were much longer than the number they calaculated. I could do the same thing by say taking 100 requests that ran in parallel and took 100msec each and divide by 100 and say it took 1msec per request but that is not what the user would see. I've done some tests along those lines in the past with the same simple servlet and the result of (total time)/(total number of requests) was largely similar regardless of how many requests were processed in parallel. In short, the more threads, the longer each request took. I saw the best throughput where parallel threads was at or just above the number of cores available (unsurprisingly). A real app is likely to be different. Just interesting how people can twist statistics. Indeed. We often say on this list that you can construct a load-test to show that any combination of Tomcat connector with/without httpd is the 'best'. It all depends on the test. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
Jeffrey Janner wrote: .. Not sure exactly what Windows does once you've entered a verified user/pw combination for a service. I'm guessing that it stores the password somehow, because if you change the password, the service won't start next time. It is stored in whatever format, encrypted or not or hashed or not, in whatever store the Domain Controller uses to store user credentials. It doesn't matter. NTLM authentication afterward works using tokens which somehow encode the information needed by a server to verify that the client is who it says it is, and the server is who it says it is. The point is that the password is not stored in clear on the client, when client means whatever host is trying to authenticate itself. It is of coursee fleetingly in memory at some point, to construct the authentication tokens, but is not kept. Only the token is kept. However, this is a nice (?) feature of using SQL Server. Already validated user credentials can be passed by the OS to SQL Server to be validated for database logon. It's their version of SSO for the database. (Note: I don't find it an overwhelming advantage for determining to use that specific database software.) No it isn't, not in this case. in the current scenario, the user for which there is SSO is the user-id under which the Tomcat process itself is running. It is /not/ the users which connect to Tomcat and run the applications. All these users connect to Tomcat, and are or not authenticated using whatever method Tomcat implements. But then, the credentials used to connect to the database are the credentials of the Tomcat process, not the ones of the users. That is why is was questioning how much in fact of a security this brings. The problem is merely moved, to the level of how users authenticate with the Tomcat application. Once they have done that, they can access any information which is accessible by this Tomcat user. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
On 24 February 2011 09:42, André Warnier a...@ice-sa.com wrote: Jeffrey Janner wrote: .. Not sure exactly what Windows does once you've entered a verified user/pw combination for a service. I'm guessing that it stores the password somehow, because if you change the password, the service won't start next time. It is stored in whatever format, encrypted or not or hashed or not, in whatever store the Domain Controller uses to store user credentials. It doesn't matter. NTLM authentication afterward works using tokens which somehow encode the information needed by a server to verify that the client is who it says it is, and the server is who it says it is. The point is that the password is not stored in clear on the client, when client means whatever host is trying to authenticate itself. It is of coursee fleetingly in memory at some point, to construct the authentication tokens, but is not kept. Only the token is kept. André, I'd be interested in how you arrived at these assertions. In particular, I don't believe your first sentence. I can start a service that logs on as a domain account when my domain member (a laptop) is not connected to the domain. Therefore the domain member is storing something somewhere, not just the DC. And any time something is stored somewhere it is subject to attack, as the Linux-based tools for changing Windows administrator passwords demonstrate rather well - Windows may not allow direct SAM hive access, but a foreign OS has no such compunctions. This is all a long way from the original subject, of course. I routinely use SSPI authentication to SQL Server when I can do, as it does reduce the attack surface somewhat. SSPI generally makes it harder for an attacker to retrieve the credentials used to authenticate a database client to SQL Server. It makes no difference to any attack that subverts the client directly in order to attack through an existing or client-created new connection, of course. - Peter
Re: Secure AJP over ssl
Or it could be in the world of outsourcing you have a giant pool of 1st, 2nd, and 3rd level support who are offshore which need access to perform basic trouble shooting before escalation. And 90% of them have no idea they have access but getting them access when they would need it becomes a giant hassle. But since everyone is on the ACL - its secure :) -Tim On 2/23/2011 2:44 PM, Mladen Turk wrote: On 02/23/2011 07:28 PM, Jason Pyeron wrote: encrypting the data transfer between those boxes cause you can just as well make sure the proper persons have the network access. That list includes 78 people. You mean 78 people monitor your network for trouble or you have your production servers in the same network segment as your local intranet? Cannot tell which one is worse :) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: how to caculate the PV,ip,PU according to the tomcat log
TO *Christopher Schultz*: 2011/2/23 Christopher Schultz ch...@christopherschultz.net -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 To whom it may concern, On 2/18/2011 7:38 PM, maven apache wrote: how to caculate the PV,ip,PU according to the tomcat log? Good question. What are PV, ip, and PU? Thanks for your attention and Sorry for my negligence. PV: page view, how many people visit a page. IP: how many ips visitor the website within one day or one hour... PU:Unique Visitor, For example: visitor A(ip:10.0.0.1) scan the site :http://www.xx.com/index.html http://www.xx.com/about.html Visitor B (ip:10.0.0.2) scan the same two pages Then VIsitor A change his/her ip to 10.0.0.3 (but its cookie in her/his browser is not change) and visitor the two pages again. Then from all of the above,the ips=3 (three distinct ips) pv=2 (two pages) PU=2 (just two different person,although three ip. Is this clear? If not,I can add more. :) For the ip I can use : select count(distinct ip)... Okay, that explains /one/ question. What about the others? But how about the pv and pu? I have no idea, please do me a favor if you know. If you can tell us what those abbreviations mean, perhaps we can write your SQL statements for you. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1kEkUACgkQ9CaO5/Lv0PDPQwCeMGyWknG04hZ1v2xrH9B5WuHT JBQAnjoe1/b0f3/hcSZOKfd0BuOI9WvE =1KL4 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Issues with ntlmauth.dll on Apache Tomcat/5.5.26 (SQL server Windows Authentication)
Hi, We have a problem on our production servers . Tomcat was running fine and we decided to use the SQL server Window Authentication by adding ntlmauth.dll in system32 windows folder and updating the jtds to version jtds1.2.5.jar as instructed by the website. This has caused a memory leak in the tomcat process i.e. if observed using the Windows Task Manager the memory usage for the tomcat6.exe process would go up until restart is required due to OutOfMemory exception. Our java application runs fine and no memory leak is reported there when observed using JConsole or JProfiler. Are you aware of any problems with this procedure? Is this a known issue? I have searched the Internet for a solution and have not been able to find anything regarding this for weeks now. I would really appreciate it if you could get back to me on this, as it is causing a lot of problems to our service. Best regards, Bledar Mema
Re: Choosing the right worker
Hi, We are not observing a failover. Our index page served by our first app server (worker1) was returning a 500 http status code, whereas the same index page served by our second app server (worker2) was returning normally (http status = 200). Yet the 500 error page was getting all the way back to the client. The docs say, The redirect flag on worker1 tells the lb_worker to redirect the requests to worker2 only if worker1 is in error state. In other cases worker2 will not receive any requests, thus acting like a hot standby. But we are still seeing our second app server get an equal number of requests. So could you clarify how to set up so that both nodes get an equal number of requests, but if one returns an error code, all requests will go to the other? Thanks, - Dave Christopher Schultz-2 wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave, On 2/23/2011 3:32 PM, laredotornado wrote: We're using 6.0.24, running on two servers. In our workers.properties file on the web server, we have ... ===Begin workers.properties == worker.lbroute.balance_workers=worker1,worker2 worker.worker1.type=ajp13 worker.worker1.host=ip_addr1 worker.worker1.port=8000 worker.worker1.lbfactor=1 You might want to look into using worker templates: you can set all of this stuff for a single template worker and inherit them in the individual ones. Useful for a consistent configuration for all workers in a lb cluster. worker.worker1.redirect=worker2 This should failover to worker2 if worker1 suffers an error, even though worker2 is set to disabled. The docs say as much: you can use this as a hot standby. You might want to look at the ping_mode, good, bad settings, too. How can I configure my workers.properties file so that if the index page of our sites is throwing a 500 http status code, it will fail over to the other worker? If your index page is being served by Tomcat/worker1, then this configuration should fail-over to worker2. Is that not what you are observing? If not, then please tell us what you are observing. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1lkCsACgkQ9CaO5/Lv0PADywCfewAFL3/W5C7EVSL91NFxbBfA hNsAn34/DRp5KmNHJwb4P/b6co0bTRhq =pmf7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- View this message in context: http://old.nabble.com/Choosing-the-right-worker-tp30998571p31004353.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Issue with oralce drive under tomcat 7
We have classes for oracle, Microsoft, and db2 and each class is specific to the vendor. I have inherited the code. I also question why class name are different and why removing ojdbc6.jar from app\lib worked. Sincerely, Robert Jenkin Surecomp Services, Inc. 2 Hudson Place, 4th Floor Hoboken, NJ 07030 Skype: robert.jenkin Office: 201 217 1437 | Direct: 201 716 1219 | Mobile: 908 251 0537 http://www.Surecomp.com -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, February 23, 2011 6:15 PM To: Tomcat Users List Subject: Re: Issue with oralce drive under tomcat 7 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 2/22/2011 9:24 PM, Caldarale, Charles R wrote: From: robert.jen...@surecomp.com [mailto:robert.jen...@surecomp.com] Subject: Issue with oralce drive under tomcat 7 Caused by: java.lang.ClassCastException: oracle.jdbc.driver.OracleResultSetMetaData cannot be cast to oracle.jdbc.OracleResultSetMetaData This is frequently caused by having the JDBC driver jar in more than one location. If you're using Tomcat's DBCP capability, the jar must be in Tomcat's lib directory - only. If you're doing your own connection pooling (or none at all), the jar should be in the webapp's WEB-INF/lib directory - only. Make sure the jar is not also in some other location, such as jre/lib, or the endorsed directory. Odd that the class names are different... and that your suggestion worked. Copy/paste error? Robert, may I ask why you were casting to an Oracle-specific interface in the first place? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1llP8ACgkQ9CaO5/Lv0PAE0wCcCP0Bbq0GmdDJBeOG3Z6ksPoP dHEAnj01yUcjYwrHqXYqo6RlZP3PQhwM =vi8b -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org This mail was sent via Mail-SeCure System.
Re: Response.SendRedirect problems
Hi Ashwin I am too facing the same issue now , On redirection the port number is getting omitted, Since this is a 2 years back thread, I suppose you might have got the solution, Please reply back with the solution. thanks faheem ashwin soorkeea wrote: Hello all, I have a problem for my application and this prob is causing an entire netw= ork of users from using my application. I will appreciate if you guys can help me solve my prob. It concerns the servlet response.sendRedirect(...) method. When using the response.sendRedirect(/myexample) in my java class, i do n= ot want the servlet engine to reconstruct an absolute URL, before sending the response to the browser. I want it to b= e handle by the browser keeping it relative throughout the application. I know it's possible, but i dunno how to do it. Can you he= lp ?=20 The URL reconstruction by the servlet engine during a redirection is causin= g some problems in my application. Example: I have this link on browser http://127.0.0.1:port_number, when performing= a sendRedirect, i'm losing the port_number during the url reconstruction by the servlet engine. On the other hand, i have another application that is interconnected, but i= n this application, the url is relative throughout, even though it passes through the response.sendRedirect(...) and consequently, i do not= have this prob in this application. Im using tomcat-4.1 and i'm checking the URL redirection using the HTTP liv= e header plugins for firefox. Thank you for your help. Regards, Ashwin _ i’m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -- View this message in context: http://old.nabble.com/Response.SendRedirect-problems-tp14361975p31005032.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
programming question
Hi, What is the very basic structure of a web application that is connected to a database through a connection pool, but would not require to restart itself or restart Tomcat when the database goes down - let say for maintenance ? Telling otherwise how to write a webapp that would survive a database recycling and would not require human interactions to make it work again. Thanks ahead, János - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: programming question
On 2/24/2011 10:49 AM, János Löbb wrote: Hi, What is the very basic structure of a web application that is connected to a database through a connection pool, but would not require to restart itself or restart Tomcat when the database goes down - let say for maintenance ? Telling otherwise how to write a webapp that would survive a database recycling and would not require human interactions to make it work again. I've never had trouble having my app reconnect after restarting the database; the tomcat db connection classes handle that transparently, AFAIK. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: programming question
On Feb 24, 2011, at 10:58 AM, David kerber wrote: On 2/24/2011 10:49 AM, János Löbb wrote: Hi, What is the very basic structure of a web application that is connected to a database through a connection pool, but would not require to restart itself or restart Tomcat when the database goes down - let say for maintenance ? Telling otherwise how to write a webapp that would survive a database recycling and would not require human interactions to make it work again. I've never had trouble having my app reconnect after restarting the database; the tomcat db connection classes handle that transparently, AFAIK. Well, I have here programmers who are writing web applications and those are stuck if I recycle the database. Therefore I have to do a 1 hour hokusz-pokusz, shutting down Tomcat, etc... all over the place, before I can recycle the database. So I just would like to know what would be the structure or skeleton of the simplest java web app that would not die if the database is pulled underneath and would reconnect like charm after the database is back again. When I mention them that their programs should handle the situation resulting from the database bounce automagically and not the dba handling the web app or Tomcat shutdowns and restarts, they look at me like I came from Mars or Saturn :-) So, I just want to know how it is done in the real world :-) Thanks ahead, János - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AccessLogValve pattern (timestamp, bytes sent and time taken)
Thank you for the answer Chris. You noted about confirmation of some
issues, and I'd been waiting for it until now.
You stated that For a simple request, the timing will include any time
blocking on response buffers... and it would be good enough for me, if
confirmed.
And I would like some clarification on Depending on exactly where the
Valve falls within the Valve chain and how the RequestDispatcher works
with Valves, it may or may not include time to render the response at all.
On 2/22/2011 10:12 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Antonios,
On 2/21/2011 11:05 AM, Antonios Kogias wrote:
If we use tomcat 7.0.8, the timing for the whole request processing
cycle will incorporate transmit time?
e.g. if using HTTP/1.0, will it represent the total time until the
teardown of the connection? Or will it be the net processing time
/before/ transmission starts (i.e. time to prepare the http response and
push it to the network layer)?
(I'd like Konstantin to confirm the following, presuming it's true...)
The Valve terminates after the servlet (the code actually doing the
work) completed its work. For a simple request, the timing will include
any time blocking on response buffers but can't by definition include
any time waiting for the client to drain the buffer.
Depending on exactly where the Valve falls within the Valve chain and
how the RequestDispatcher works with Valves, it may or may not include
time to render the response at all. Let me explain:
Many servlets look like this:
public void doGet(...) {
try {
// do some stuff
getRequestDispatcher(/result.jsp).forward(request, response);
} catch (Exception e) {
// log the error, whatever
getRequestDispatcher(/error.jsp).forward(request, response);
}
}
If the Valve wraps around only the original request (to, say, servlet
/foo) then you're only timing the execution of the code shown above:
the processing of result.jsp (or error.jsp for that matter) will be
shown in a separate log message.
I don't believe Apache httpd has a notion of an internal request forward
the way that Java does, so I'm not sure there's an analog, there.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1kGKkACgkQ9CaO5/Lv0PA8WgCeP0uLrgXyT2sHkwRkbaVtsrkC
ZDsAoJQpc75Zl8iJYPzRPgKOhlOef/gw
=Ysn0
-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: programming question
When I mention them that their programs should handle the situation resulting from the database bounce automagically and not the dba handling the web app or Tomcat shutdowns and restarts, they look at me like I came from Mars or Saturn :-) If you code the app to use a connection pool, the connections are cached. The connection pool can be configured to test the connection, and remove it from the pool if it has been closed. In this way as the app asks for a connection, if the database has been restarted, old connections will be dropped and new ones created. Various different ways to configure the connection pool - in the app or in the container. We use DBCP and works fine for us in the scenario you describe Just search google for tomcat database connection pool. HTH Chris
Re: programming question
With tomcat's built-in database pooling, just adding a validation query to the resource config should be all that's necessary. On each borrow of a connection, the connection is tested and closed if the test fails. Failed connections are replaced with new ones. --David On 2/24/2011 10:49 AM, János Löbb wrote: Hi, What is the very basic structure of a web application that is connected to a database through a connection pool, but would not require to restart itself or restart Tomcat when the database goes down - let say for maintenance ? Telling otherwise how to write a webapp that would survive a database recycling and would not require human interactions to make it work again. Thanks ahead, János - 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: programming question
On 2/24/2011 11:35 AM, chris derham wrote: When I mention them that their programs should handle the situation resulting from the database bounce automagically and not the dba handling the web app or Tomcat shutdowns and restarts, they look at me like I came from Mars or Saturn :-) If you code the app to use a connection pool, the connections are cached. The connection pool can be configured to test the connection, and remove it from the pool if it has been closed. In this way as the app asks for a connection, if the database has been restarted, old connections will be dropped and new ones created. That's what I do, but I handle it in my app instead of using DBCP. Various different ways to configure the connection pool - in the app or in the container. We use DBCP and works fine for us in the scenario you describe Just search google for tomcat database connection pool. HTH Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: a problem about my jsf-tomcat application on opening
thank you Could you tell me how you got these results ? regards 2011/2/23 Caldarale, Charles R chuck.caldar...@unisys.com: From: ahmet temiz [mailto:ahmettemi...@gmail.com] Subject: a problem about my jsf-tomcat application on opening How can I enable its opening in first try. Fix your webapp. It's returning a 302 (redirect) in response to the URL you posted, with a hard-coded target of localhost: HTTP/1.1 302 Moved Temporarily Server: Apache-Coyote/1.1 X-Powered-By: JSF/1.2 Set-Cookie: JSESSIONID=384D773B1106F0A2965D629CE3A03E60; Path=/pro1 Location: http://localhost:8080/pro1/bir.jsf Content-Language: en-US Content-Length: 0 Date: Wed, 23 Feb 2011 14:27:45 GMT This is your webapp's doing, not Tomcat's. Someone has hard-coded localhost into a filter, servlet, or JSP, or the configuration files thereof. - 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 -- Ahmet Temiz Jeoloji Müh. Afet ve Acil Durum Yönetimi Başkanlığı Planlama ve Zarar Azaltma Dairesi Başkanlığı Bilgi ve CBS grubu Eskişehir Yolu 10. km. Lodumlu / Ankara Tel : 0 312 2872680 / 1535 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: a problem about my jsf-tomcat application on opening
From: ahmet temiz [mailto:ahmettemi...@gmail.com] Subject: Re: a problem about my jsf-tomcat application on opening Could you tell me how you got these results ? http://www.fiddler2.com/fiddler2/ Coupled with the knowledge that Tomcat doesn't do anything like what you're seeing - unless you're running behind a proxy. If you are, you'll need to set the proxyName and proxyPort attributes on your Connector elements in server.xml: http://tomcat.apache.org/tomcat-6.0-doc/config/http.html - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: a problem about my jsf-tomcat application on opening
From: Caldarale, Charles R Subject: RE: a problem about my jsf-tomcat application on opening unless you're running behind a proxy. Enable the AccessLogValve in your server.xml file to see if you are getting requests via a proxy. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] Memory Leak in Tomcat
-Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Thursday, February 24, 2011 3:43 AM To: Tomcat Users List Subject: Re: [OT] Memory Leak in Tomcat Jeffrey Janner wrote: .. Not sure exactly what Windows does once you've entered a verified user/pw combination for a service. I'm guessing that it stores the password somehow, because if you change the password, the service won't start next time. It is stored in whatever format, encrypted or not or hashed or not, in whatever store the Domain Controller uses to store user credentials. It doesn't matter. NTLM authentication afterward works using tokens which somehow encode the information needed by a server to verify that the client is who it says it is, and the server is who it says it is. The point is that the password is not stored in clear on the client, when client means whatever host is trying to authenticate itself. It is of coursee fleetingly in memory at some point, to construct the authentication tokens, but is not kept. Only the token is kept. However, this is a nice (?) feature of using SQL Server. Already validated user credentials can be passed by the OS to SQL Server to be validated for database logon. It's their version of SSO for the database. (Note: I don't find it an overwhelming advantage for determining to use that specific database software.) No it isn't, not in this case. in the current scenario, the user for which there is SSO is the user- id under which the Tomcat process itself is running. It is /not/ the users which connect to Tomcat and run the applications. All these users connect to Tomcat, and are or not authenticated using whatever method Tomcat implements. But then, the credentials used to connect to the database are the credentials of the Tomcat process, not the ones of the users. That is why is was questioning how much in fact of a security this brings. The problem is merely moved, to the level of how users authenticate with the Tomcat application. Once they have done that, they can access any information which is accessible by this Tomcat user. Isn't that the point of authentication in the application/Tomcat? (Note, I'm intentionally misinterpreting your use of the term Tomcat user here, as you seem to be mixing the different authentication levels in your argument.) Here's the proper setup the OP is attempting to implement: 1: End user's authenticate the application using whatever method they deem necessary. 2: Tomcat/application authenticates to SQL Server either via plaintext uid pw stored in XML file, or via SSO token derived from Tomcat process login. The differences: a) The plaintext is available rather easily to anyone who can access said XML file, either via Tomcat or some other means. Those credentials can be used to launch an attack on the DB from the Tomcat server, or any other server. b) The SSO is available directly iff the attacker manages to crash Tomcat or infect it and the attack must take place via the Tomcat process. c) It is probably possible to grab the Windows SSO token used by the Tomcat process by locating it on disk and somehow making it useable for attacking the SQL Db. I don't tread too deeply in the security waters, but I think that would have made big news if it was easy. Note: I'm not particularly trying to argue that this is an ultimately secure mechanism for authenticating Tomcat to the SQL Server database. But it does allow the checking of the box next to No passwords stored in cleartext line on the security gestapo's checklist. __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
RE: [OT] Memory Leak in Tomcat
-Original Message- From: peter.crowth...@googlemail.com [mailto:peter.crowth...@googlemail.com] On Behalf Of Peter Crowther Sent: Thursday, February 24, 2011 3:57 AM To: Tomcat Users List Subject: Re: [OT] Memory Leak in Tomcat On 24 February 2011 09:42, André Warnier a...@ice-sa.com wrote: Jeffrey Janner wrote: .. Not sure exactly what Windows does once you've entered a verified user/pw combination for a service. I'm guessing that it stores the password somehow, because if you change the password, the service won't start next time. It is stored in whatever format, encrypted or not or hashed or not, in whatever store the Domain Controller uses to store user credentials. It doesn't matter. NTLM authentication afterward works using tokens which somehow encode the information needed by a server to verify that the client is who it says it is, and the server is who it says it is. The point is that the password is not stored in clear on the client, when client means whatever host is trying to authenticate itself. It is of coursee fleetingly in memory at some point, to construct the authentication tokens, but is not kept. Only the token is kept. André, I'd be interested in how you arrived at these assertions. In particular, I don't believe your first sentence. I can start a service that logs on as a domain account when my domain member (a laptop) is not connected to the domain. Therefore the domain member is storing something somewhere, not just the DC. And any time something is stored somewhere it is subject to attack, as the Linux-based tools for changing Windows administrator passwords demonstrate rather well - Windows may not allow direct SAM hive access, but a foreign OS has no such compunctions. The local Windows OS caches logon credentials and does a local authentication iff the domain controller is not available -- specifically for the purpose of allowing logins in that case. Those credentials are stored somewhere on disk (probably somewhere under C:\Windows\security, or perhaps in the registry), and potentially usable by an attacker. However, if the credentials cannot be verified by other networked machines, those systems are supposed to reject them. My original point was that I don't know the mechanism for storing credentials in the Services. It appears that they are store in the registry, but I cannot tell if they are encryptions of the credentials themselves or the token returned from authentication. In either case, if you change the password on the domain, you have to change it on the service or it won't start. This is all a long way from the original subject, of course. I routinely use SSPI authentication to SQL Server when I can do, as it does reduce the attack surface somewhat. SSPI generally makes it harder for an attacker to retrieve the credentials used to authenticate a database client to SQL Server. It makes no difference to any attack that subverts the client directly in order to attack through an existing or client-created new connection, of course. - Peter p.s. before the spell-check nazi's comment on it, the iff above was intentional. __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
When will SingleThreadModel be removed?
Hi All, When do you think SingleThreadModel will go from deprecated to being gone? I noticed with Tomcat 7 it is still present so I am assuming Servlet 3.0 api still has it present. Is it true by default all JSP's use it unless otherwise specified? Thanks, -Tony - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: When will SingleThreadModel be removed?
From: Tony Anecito [mailto:adanec...@yahoo.com] Subject: When will SingleThreadModel be removed? When do you think SingleThreadModel will go from deprecated to being gone? Not soon enough. I noticed with Tomcat 7 it is still present so I am assuming Servlet 3.0 api still has it present. And still deprecated. Is it true by default all JSP's use it unless otherwise specified? No - read the JSP spec; the default value for isThreadSafe is true and has been for quite some time. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: When will SingleThreadModel be removed?
Thanks I did some more research and found out you are right about the isThreadSafe setting. I thought I saw otherwise somewhere else. -Tony - Original Message From: Caldarale, Charles R chuck.caldar...@unisys.com To: Tomcat Users List users@tomcat.apache.org Sent: Thu, February 24, 2011 1:34:24 PM Subject: RE: When will SingleThreadModel be removed? From: Tony Anecito [mailto:adanec...@yahoo.com] Subject: When will SingleThreadModel be removed? When do you think SingleThreadModel will go from deprecated to being gone? Not soon enough. I noticed with Tomcat 7 it is still present so I am assuming Servlet 3.0 api still has it present. And still deprecated. Is it true by default all JSP's use it unless otherwise specified? No - read the JSP spec; the default value for isThreadSafe is true and has been for quite some time. - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: When will SingleThreadModel be removed?
Either way when Oracle removes it it will be like Y2K all over again. All the sites using Java will have to inspect all the code JSP's somehow. The hope is no one was crazy enough to use SingleThreadModel but of course the temptation to use a thread safe model (though it can be misused and made non-threadsafe) will be great to the casual developer not realizing they put a ticking timebomb in the container. Thanks, -Tony - Original Message From: Tony Anecito adanec...@yahoo.com To: Tomcat Users List users@tomcat.apache.org Sent: Thu, February 24, 2011 1:48:49 PM Subject: Re: When will SingleThreadModel be removed? Thanks I did some more research and found out you are right about the isThreadSafe setting. I thought I saw otherwise somewhere else. -Tony - Original Message From: Caldarale, Charles R chuck.caldar...@unisys.com To: Tomcat Users List users@tomcat.apache.org Sent: Thu, February 24, 2011 1:34:24 PM Subject: RE: When will SingleThreadModel be removed? From: Tony Anecito [mailto:adanec...@yahoo.com] Subject: When will SingleThreadModel be removed? When do you think SingleThreadModel will go from deprecated to being gone? Not soon enough. I noticed with Tomcat 7 it is still present so I am assuming Servlet 3.0 api still has it present. And still deprecated. Is it true by default all JSP's use it unless otherwise specified? No - read the JSP spec; the default value for isThreadSafe is true and has been for quite some time. - 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 - 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: When will SingleThreadModel be removed?
From: Tony Anecito [mailto:adanec...@yahoo.com] Subject: Re: When will SingleThreadModel be removed? Either way when Oracle removes it it will be like Y2K all over again. My guess is that it will never be removed - just as all the other deprecated classes and APIs deprecated over ten years ago are still hanging around. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: When will SingleThreadModel be removed?
I am betting you are right. Have you ever scanned for it? I was thinking jarscan might do the trick but it does not cover jsp's where the isThreadSafe is set to false. I am just hinking it is good from a System Admin point of view that it is there. Or maybe not :] Thanks, -Tony - Original Message From: Caldarale, Charles R chuck.caldar...@unisys.com To: Tomcat Users List users@tomcat.apache.org Sent: Thu, February 24, 2011 2:16:36 PM Subject: RE: When will SingleThreadModel be removed? From: Tony Anecito [mailto:adanec...@yahoo.com] Subject: Re: When will SingleThreadModel be removed? Either way when Oracle removes it it will be like Y2K all over again. My guess is that it will never be removed - just as all the other deprecated classes and APIs deprecated over ten years ago are still hanging around. - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: When will SingleThreadModel be removed?
Okay maybe the best way is to do a form of grep and jarscan. Grep for the isThreadSafe existance and jarscan for the SingleThreadModel class. Regards, -Tony - Original Message From: Tony Anecito adanec...@yahoo.com To: Tomcat Users List users@tomcat.apache.org Sent: Thu, February 24, 2011 2:26:22 PM Subject: Re: When will SingleThreadModel be removed? I am betting you are right. Have you ever scanned for it? I was thinking jarscan might do the trick but it does not cover jsp's where the isThreadSafe is set to false. I am just hinking it is good from a System Admin point of view that it is there. Or maybe not :] Thanks, -Tony - Original Message From: Caldarale, Charles R chuck.caldar...@unisys.com To: Tomcat Users List users@tomcat.apache.org Sent: Thu, February 24, 2011 2:16:36 PM Subject: RE: When will SingleThreadModel be removed? From: Tony Anecito [mailto:adanec...@yahoo.com] Subject: Re: When will SingleThreadModel be removed? Either way when Oracle removes it it will be like Y2K all over again. My guess is that it will never be removed - just as all the other deprecated classes and APIs deprecated over ten years ago are still hanging around. - 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 - 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: [OT] Memory Leak in Tomcat
Jeffrey Janner wrote: -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Thursday, February 24, 2011 3:43 AM To: Tomcat Users List Subject: Re: [OT] Memory Leak in Tomcat Jeffrey Janner wrote: .. Not sure exactly what Windows does once you've entered a verified user/pw combination for a service. I'm guessing that it stores the password somehow, because if you change the password, the service won't start next time. It is stored in whatever format, encrypted or not or hashed or not, in whatever store the Domain Controller uses to store user credentials. It doesn't matter. NTLM authentication afterward works using tokens which somehow encode the information needed by a server to verify that the client is who it says it is, and the server is who it says it is. The point is that the password is not stored in clear on the client, when client means whatever host is trying to authenticate itself. It is of coursee fleetingly in memory at some point, to construct the authentication tokens, but is not kept. Only the token is kept. However, this is a nice (?) feature of using SQL Server. Already validated user credentials can be passed by the OS to SQL Server to be validated for database logon. It's their version of SSO for the database. (Note: I don't find it an overwhelming advantage for determining to use that specific database software.) No it isn't, not in this case. in the current scenario, the user for which there is SSO is the user- id under which the Tomcat process itself is running. It is /not/ the users which connect to Tomcat and run the applications. All these users connect to Tomcat, and are or not authenticated using whatever method Tomcat implements. But then, the credentials used to connect to the database are the credentials of the Tomcat process, not the ones of the users. That is why is was questioning how much in fact of a security this brings. The problem is merely moved, to the level of how users authenticate with the Tomcat application. Once they have done that, they can access any information which is accessible by this Tomcat user. Isn't that the point of authentication in the application/Tomcat? (Note, I'm intentionally misinterpreting your use of the term Tomcat user here, as you seem to be mixing the different authentication levels in your argument.) Here's the proper setup the OP is attempting to implement: 1: End user's authenticate the application using whatever method they deem necessary. 2: Tomcat/application authenticates to SQL Server either via plaintext uid pw stored in XML file, or via SSO token derived from Tomcat process login. The differences: a) The plaintext is available rather easily to anyone who can access said XML file, either via Tomcat or some other means. Those credentials can be used to launch an attack on the DB from the Tomcat server, or any other server. b) The SSO is available directly iff the attacker manages to crash Tomcat or infect it and the attack must take place via the Tomcat process. c) It is probably possible to grab the Windows SSO token used by the Tomcat process by locating it on disk and somehow making it useable for attacking the SQL Db. I don't tread too deeply in the security waters, but I think that would have made big news if it was easy. Note: I'm not particularly trying to argue that this is an ultimately secure mechanism for authenticating Tomcat to the SQL Server database. But it does allow the checking of the box next to No passwords stored in cleartext line on the security gestapo's checklist. Hi. I agree with all of the above, and maybe I did not say it clearly, but that is also what I meant. 1) authenticating the Tomcat process to the DB system by means of an NTLM-based authentication, is a degree more secure than via a clear-text userid/password combination, because it this last case, the userid/password combination have to be stored somewhere on the Tomcat server in clear. 2) this however, by itself, does /not/ provide a Single-Sign-On capability for the users, at least not vis-a-vis the DB system. A true user-level SSO would have the *user* credentials being used to authenticate to the DB system, which is not the case here. The only user authenticatiing to the DB system, is whatever user-id Tomcat runs under. 3) This is what I meant by merely displacing the issue : whichever user is accepted by Tomcat can now use the Tomcat applications to access the contents of the database. That is because Tomcat is authenticated to the DB system, and all accesses to the DB are made by Tomcat under its own user-id. So now the issue is : how (and even if) the users authenticate to Tomcat. (The OP did not mention that part). Let me give a stupid example : imagine that Tomcat authenticates users by means of the conf/tomcat-users.xml file. Then getting hold of /that/ file would allow anyone to login to Tomcat, and automatically gain access to the database (through
Re: Issues with ntlmauth.dll on Apache Tomcat/5.5.26 (SQL server Windows Authentication)
BLEDAR MEMA wrote: Hi, We have a problem on our production servers . Tomcat was running fine and we decided to use the SQL server Window Authentication by adding ntlmauth.dll in system32 windows folder and updating the jtds to version jtds1.2.5.jar as instructed by the website. This has caused a memory leak in the tomcat process i.e. if observed using the Windows Task Manager the memory usage for the tomcat6.exe process would go up until restart is required due to OutOfMemory exception. Our java application runs fine and no memory leak is reported there when observed using JConsole or JProfiler. Are you aware of any problems with this procedure? Is this a known issue? I have searched the Internet for a solution and have not been able to find anything regarding this for weeks now. I would really appreciate it if you could get back to me on this, as it is causing a lot of problems to our service. This is the same issue as the thread entitled Memory Leak in Tomcat. Perhaps you want to browse it. The answer is the same : you should ask the jTDS (jDTS ?) people about it. It does not seem to have anything to do with Tomcat per se. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7 missing Tomcat 6's Context disableURLRewriting Setting?
Is this capability somewhere else, perhaps not needed anymore, or perhaps still on the backlog to be ported up to TC7?
Re: Tomcat 7 missing Tomcat 6's Context disableURLRewriting Setting?
On 24/02/2011 22:44, Scott Hamilton wrote: Is this capability somewhere else, perhaps not needed anymore, or perhaps still on the backlog to be ported up to TC7? See ServletContext.setSessionTrackingModes() Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 7 missing Tomcat 6's Context disableURLRewriting Setting?
Holy smokes that was a quick response! Thanks!!! -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Thursday, February 24, 2011 5:47 PM To: Tomcat Users List Subject: Re: Tomcat 7 missing Tomcat 6's Context disableURLRewriting Setting? On 24/02/2011 22:44, Scott Hamilton wrote: Is this capability somewhere else, perhaps not needed anymore, or perhaps still on the backlog to be ported up to TC7? See ServletContext.setSessionTrackingModes() Mark - 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
Exception in hibernate3 relating to timeout
hi, I am not sure if i am ringing the correct list, but i am sure people here must have encountered this problem. I am new to hibernate and when i ran the code on server it was fine , strangely next day it keep on giving this error till i restart tomcat. The last packet successfully received from the server was 54,880,316 milliseconds ago. The last packet sent successfully to the server was 54,880,317 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem. I have searched a lot on net and added the following properties on hibernate.cfg.xml, as people there were suggesting this,but of no use. !-- Sessions and transactions -- !-- Use the C3P0 connection pool provider -- property name=hibernate.c3p0.min_size5/property property name=hibernate.c3p0.max_size20/property property name=hibernate.c3p0.timeout300/property property name=hibernate.c3p0.max_statements50/property property name=hibernate.c3p0.idle_test_period3000/property property name=current_session_context_classthread/property Pl. help me. I have used hibernate3 with myeclipse as the development environment, and am using mysql 5.x and centos (Linux) with Tomcat 5.x -- Thanks and kind Regards, Abhishek jain
