Application - Struts 1.2, Tomcat 6
Action class calls a service which through DAO executes a query and returns results.
The query is not long running and gives results in seconds when run directly over the database (through SQL client say SQL Developer), but, when the user browses through application front end and same query is run in background through the application, the system hangs and the response either times out or takes a lot of time.
Issue is specific to one particular screen implying that app server to db server connectivity is ok.
Is there a way to enable debug logging of Tomcat/ Struts without any code change, to identify one out of the two scenarios below or any other scenarios possible?
The query is taking the time.
The response is not being sent back to the browser.
P.S. - Debugging or code change to add logging is not an immediate option.
Something to look at is a "Java Profiler". The one that I've used and have liked is YourKit.
Related
I have a java web app that is running inside tomcat and the application has a page (JSP) where users clicks (some buttons on that web page) which results in hitting a query behind the page and reloads it with new information and sometimes that query takes longer than expected and I want to kill the query automatically if it runs longer than x minutes. How can I achieve that at tomcat side, is that even possible with any tomcat server configurations like timeout or anything, if so could someone please guide me or show an example configuration or setting change I can try? Thanks
I think you are looking for Statement.setQueryTimeout which is a feature of JDBC, not of any specific application server, etc. You will want to call that method and set an appropriate timeout. Your queries will throw SQLTimeoutException if the timeout elapses and your application will have to decide what to do next.
I have a web server which is presenting some data from a Cloudera cluster. The data are stored on HBase and the cluster is secured with Kerberos. When I try to perform a get, the server hangs without logging any error.
So far I've tried:
Launching the webserver from command line after a kinit (the server is just for testing purpose, so log-in duration and complex procedures to start it are not an issue)
The runAs approach described in here, both with and without the configuration file import from this answer.
The CLASSPATH configuration approach described here
Global authentication with UserGroupInformation.loginUserFromKeytab (with and without all the configurations from point 2 and 3)
I've executed all the gets from hbase shell after kiniting with the web server's user and they work in reasonable time (less than a second, while the last time I left the connection open the server didn't respond in over an hour), so it's not a performance or authorization issue. Inside the same web server, with every configuration listed, I'm able to perform other actions, like connecting to HBase and getting the table instances.
I've also checked the logs from Kerberos, HBase and my web server and none of them presents any error. In fact, I'm pretty much afraid that the authorization works, but it just gets stuck in some loop during the get.
UPDATES: After more testing, I've verified that there is a user set right before the call to HBase's API. Also, I've checked and no calls are made to HBase. So this is not an authentication problem, but something else. Did anybody have the same problem?
I am experiencing a weird problem in a GWT application. I have multiple RPC calls which work correctly, however if one of them takes longer than 30 seconds on the server side (for example a database or web service call took a long time), the server side code gets repeated (literally; the code get executed again).
I do not experience this in my develompent environment, however when I deploy the application (container is Jetty 6.1.24 on Ubuntu 12.04 LTS) and connect to it from a browser (regardless of the type), the problem starts to exist.
Since I do not think this a designed GWT behaviour (but I might be wrong ofcourse) I am basically looking for ways to debug this and find out the reason for it. Thanks in advance!
Some more information would be great to understand what is going on, but I would start the investigation by first narrowing down whether the erroneous GWT-RPC call is triggered on the client or server.
To see if the extra GWT-RPC request originates from the browser, in Google Chrome, go to View->Developer->Developer Tools.. Click on the Network Tab.
As you reproduce your steps, the Network Tab will show you every request sent to the server.
If you see the erroneous GWT-RPC request logged in this Network Tab View, then the request is fired off from the GWT-compiled Javascript in the application. With SuperDevMode, you can then set debug breakpoints in the browser and see what is triggering the request.
If the erroneous GWT-RPC is not shown in the Network Tab View, then the server-side method is somehow triggered by your server code/configuration. Set some debug breakpoints on your server code, and drill down the call stack to see what is calling the method.
Hope that helps to get started on the investigation.
I have an java application that interacts with Salesforce. Application processes a batch of requests (~100 requests). Before starting processing of each batch, it calls login() to Salesforce but it never calls logOut() from it in the end. Same cycle happens with next batch. Problem we are facing is, time it takes for a query to return result from Salesforce keeps on increasing until we restart the whole application. After which, query time significantly drops.
My questions are:
Could it be due to repeated logins and never logging out?
I have experimented with logout. It seems, no matter which host I login from, If once logged in, Salesforce always returns same sessionId. That means, if I logout on one host, it logs out on all hosts. That would require us to put logic to handle such unexpected situations on other hosts. How do other people manage session among multiple hosts?
Appreciate any inputs.
I want to post my findings here. It seems that slow down in queries was due to frequent repeated logins. In my case it was once every 5 mins. Recently logic was changed to login only once and handle any exception that might arise out of session time out/re login if required etc. After this change now, our queries are taking same time and don't slow down.
We are in the process of creating a training mode for our ColdFusion (9) sites.
The system will allow our users, after logging in, to switch from production mode to training mode by clicking on a link.
When they switch, the data-sources will be switched allowing the data to be safely modified.
We are also going to implement a test SMTP server, using the SubEthaSMTP Java project, in order to capture the emails that are sent from the training mode and display them to the user in a web page.
We can launch the SMTP server as a stand alone process or service without much trouble.
The nicer solution would be to launch server as part of the ColdFuson runtime at the point that the user switches to training mode.
We would create a true Java thread that would persist on a Server level scope for the length of any training sessions and then some arbitrary time out period. If the server times out and a new training session is initiated we would initiate a new SMTP server.
My essential question is, therefore, is it a bad idea to run an ongoing thread in the ColdFusion runtime this way?
I can't see a problem with doing this, although you ought to test to see what resources SubEthaSMTP uses and make sure it's not going to cause you issues. It looks to have minimal dependencies (essentially just SLF4J, which ColdFusion 9 & 10 already provide)
From the example page it looks to be pretty easy to set up and drop into a long-running scope. I think you're right to pick the server scope, as you may have problems using application or anything more volatile, as there'll be a situation where application scope would timeout and be reset, but you'd loose all references to the Mail Server instance.
Please update the post with your findings, as I'd be interested in seeing what you find.