Re: Detecting blocked RPC
In fact there where an error in the called URL we forget to add at the end of the URL the RPC servlet url-pattern. So In post we where just asking the index... Now this have been corrected, we have an answer which is 405 or 500 depending on how we construct the CURL or WGET request. So we still need to understand what is wrong. Too answer to you point, yes we are sure that we have a problem in our servlet because this one is blocked while tomcat can still serve index.html, images or other servlets. Actually we are not able to debug it because the are no logs in our log4j or in tomcat logs signalling that there is something wrong. More over we have this problem at a frequency than less 1 per month and only in production environnement so it is not easy to find the reason. Next time I will ty a kill -3 on the tomcat to look if there is some blocked threads. Actually we are just trying to detect it as soon as possible to be able to restart the application (if possible before a cusomer detects it). I totally agree that it is not clean and a definitive solution but in a first time we are trying to not create disappointment with our customers. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Detecting blocked RPC
We've noticed on our application that sometime some RPC does not answer. When we load the index.html every this is correctly started, but when user try to login = send an RPC to check is user/pass he never receive an answer. Actually we didn't have a clue why we do not have answer and the only thing we found to solve it is to restart the tomcat... Yeah... Not really nice ! More over when this problem occurs we are notified because a customer complains about it. We would like to detect it more quickly. The idea would be to send periodicaly via a POST a request to check if we have an answer (invalid login for example). We try to send a POST using curl but we only get index.html as answer : ( How can we generate a compatible RPC POST request ? Is there something specifying how a request is built ? Is there any better solution to check that a RPC servlet is alive ? Thanks for reading ! -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Detecting blocked RPC
On 03/22/2011 10:06 AM, Mogoye wrote: We've noticed on our application that sometime some RPC does not answer. When we load the index.html every this is correctly started, but when user try to login = send an RPC to check is user/pass he never receive an answer. Actually we didn't have a clue why we do not have answer and the only thing we found to solve it is to restart the tomcat... Yeah... Not really nice ! More over when this problem occurs we are notified because a customer complains about it. We would like to detect it more quickly. The idea would be to send periodicaly via a POST a request to check if we have an answer (invalid login for example). We try to send a POST using curl but we only get index.html as answer : ( How can we generate a compatible RPC POST request ? Is there something specifying how a request is built ? Is there any better solution to check that a RPC servlet is alive ? Maybe instead start a watchdog timer before the request. Cancel the request when the timer expires. Cancel the timer when the request returns. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Detecting blocked RPC
Well a RPC request will be done via HTTP/TCP so the only way to lost the answer is when the server does not respond within TCP's timeout. If the timeout is reached I think GWT will call the RPC request's onFailure method. So as long as your servlet responds somehow, RCP requests should be fine. So you could either POST nonsense to the servlet (which would result in an exception and this exception is probably the content of your received index.html. See AbstractRemoteServiceServlet.java for exception handling details). If its not then you have posted nonsense to a wrong url) or you could overwrite doGet in the servlet and let it respond with http 200 along with OK and then do a GET on the servlet and check if you received OK. But in general I think you have either a misconfigured Tomcat or a significant bug in your server side application (because you have said it works again if you restart tomcat). So I would definitely make a code review / tomcat configuration review and/or do some logging. Maybe Tomcat receives all RPC requests but your application is, at some point, in a state where the servlet just could not finish its job (waits for something) and thus does not respond (maybe there is no database connection available from a connection pool or a synchronized block never completes and threads have to wait or something like that). -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
