search

hastapasta / financereport

Automatically exported from code.google.com/p/financereport
0 stars 0 forks source link

Tracking issue for "The last packet..." gadget error messages. #280

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Full error message:

The last packet successfully received from the server was 36,727,995 
milliseconds ago.  The last packet sent successfully to the server was 
36,733,072 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

This seems to only happen in IE.

Original issue reported on code.google.com by hastapas...@gmail.com on 22 Apr 2011 at 2:23

GoogleCodeExporter commented 8 years ago 
I was seeing these this morning (4/22/2011).

Original comment by hastapas...@gmail.com on 22 Apr 2011 at 2:24

GoogleCodeExporter commented 8 years ago 
I think this is related to null pointer exceptions occuring in tomcat. The jsp 
datasource page never returns, hence the timeout message.

Original comment by hastapas...@gmail.com on 22 Apr 2011 at 2:40

GoogleCodeExporter commented 8 years ago 
Need to monitor the tomcat console.

Original comment by hastapas...@gmail.com on 22 Apr 2011 at 2:40

GoogleCodeExporter commented 8 years ago 
Need to check this a couple of times throughout the day and figure out how to 
put a monitor on it.

Original comment by hastapas...@gmail.com on 22 Apr 2011 at 2:42

GoogleCodeExporter commented 8 years ago 
I promoted the new jsp pages and java library yesterday and so far haven't seen 
any null pointer exceptions. 

I also have a multitest job crontabbed for every minute.

Original comment by hastapas...@gmail.com on 25 Apr 2011 at 1:27

GoogleCodeExporter commented 8 years ago 
These errors still show up temporarily, most often in the morning.

Haven't been able to discern a pattern or come up with a cause.

Original comment by hastapas...@gmail.com on 27 Apr 2011 at 4:35

GoogleCodeExporter commented 8 years ago 
Saw issues the morning of 4/27/2011.

Original comment by hastapas...@gmail.com on 27 Apr 2011 at 5:54

GoogleCodeExporter commented 8 years ago 
Saw issues again today (5/17). Need to do a test but I don't think these are 
being generated from within the jsp file. I added unique codes to all of the 
googleError() calls to better track this.

Original comment by hastapas...@gmail.com on 6 May 2011 at 10:21

GoogleCodeExporter commented 8 years ago 
I'm going to disable the multitest cron tab that tests the datasource response 
times until I get this resolved.

Original comment by hastapas...@gmail.com on 15 May 2011 at 2:12

GoogleCodeExporter commented 8 years ago 
Opened a thread in the google visualization api forum:

http://groups.google.com/group/google-visualization-api/browse_thread/thread/895
9bc2a8eb07df9

Original comment by hastapas...@gmail.com on 16 May 2011 at 9:14

GoogleCodeExporter commented 8 years ago 
When you get the error in one browser, try accessing the page from another 
browser.

Also wonder if this has something to do with having multiple gadgets in one 
page.

Original comment by hastapas...@gmail.com on 17 May 2011 at 12:50

GoogleCodeExporter commented 8 years ago 
I just saw this error when issuing the datasource url directly in the browser 
so it looks like this has nothing to do with google gadgets (and explains the 
lack of a response on the gadget forums). 

It is weird though that when I access allassets/main.php, which issues the same 
datasource url 3 times, the error is only returned one of those times. It might 
be thread related in that only one of the threads is having a problem.

Here is a stackoverflow thread with some suggestions:
http://stackoverflow.com/questions/2172570/tomcat6-cant-connect-to-mysql-the-dri
ver-has-not-received-any-packets-from-the

Original comment by hastapas...@gmail.com on 19 May 2011 at 2:36

GoogleCodeExporter commented 8 years ago 
I added autoConnect=true to the jdbc url in context.xml.

Original comment by hastapas...@gmail.com on 19 May 2011 at 3:43

GoogleCodeExporter commented 8 years ago 
The name/value pair is acutally autoReconnect=true.

Original comment by hastapas...@gmail.com on 19 May 2011 at 3:44

GoogleCodeExporter commented 8 years ago 
Still getting the messages after setting autoReconnect=true.

Original comment by hastapas...@gmail.com on 23 May 2011 at 7:43

GoogleCodeExporter commented 8 years ago 
Just enabled the following properties in tomcat's context.xml:

logAbandoned="true" removeAbandoned="true" removeAbandonedTimeout="300"

Maybe by cleaning up abondoned threads, the problem will go away. This might be 
a messy way of fixing abandoned threads but I'm curious to see if it will have 
an effect.

Original comment by hastapas...@gmail.com on 23 May 2011 at 7:46

GoogleCodeExporter commented 8 years ago 
Still getting the error message. There are null pointer exceptions showing up 
in the console; need to resolve these.

Original comment by hastapas...@gmail.com on 25 May 2011 at 3:32

GoogleCodeExporter commented 8 years ago 
Log4j is finally configured properly with tomcat. I added some debug messages 
to mysqldatasource2.jsp which is where some of the null pointer exceptions are 
occurring.

Original comment by hastapas...@gmail.com on 1 Jun 2011 at 8:14

GoogleCodeExporter commented 8 years ago 
Added code to mysqldatasource2eh2.jsp to reissue the query if the exception 
occurs.

Original comment by hastapas...@gmail.com on 5 Jul 2011 at 1:27

GoogleCodeExporter commented 8 years ago 
It looks like this is associated with MultiTest.java. That is the only place 
where the mysqldatasource2.jsp datasource gets issued and I see that one 
hanging when I do a "show processlist;" in the mysql command line utility. I've 
disabled the pandora monitors and the MultiTest crontab for now.

Original comment by hastapas...@gmail.com on 25 Jul 2011 at 2:22

GoogleCodeExporter commented 8 years ago 
It now looks like the issues with MultiTest were separate and unrelated to the 
"The last packet" messages. All of the MultiTest monitoring was turned off 
overnight and I still received a "last packet" error message this morning.

Original comment by hastapas...@gmail.com on 25 Jul 2011 at 2:35

GoogleCodeExporter commented 8 years ago 
I have an elance contractor now working on this. I want to set up devdataload 
on the hpdesktop2 box so I can leave it running and try to reproduce the issue 
there.

By adding the autoReconnect parameter, it seems to reduce the error so that it 
only occurs once, but it doesn't prevent the error from occurring completely. 
I'm thinking about removing this parameter to make the error easier to 
reproduce.

Original comment by hastapas...@gmail.com on 29 Jul 2011 at 8:24

GoogleCodeExporter commented 8 years ago 
Elance contractor provided context.xml settings that will cause a connection in 
the pool to be tested before it is used. Testing these changes now.

Original comment by hastapas...@gmail.com on 2 Aug 2011 at 12:01

GoogleCodeExporter commented 8 years ago 
The problem appears to be fixed in test. Just need to move it into production.

Original comment by hastapas...@gmail.com on 5 Aug 2011 at 1:20

GoogleCodeExporter commented 8 years ago 
Moved changes into production. Have not seen this error since then. Closing 
Issue.

Original comment by hastapas...@gmail.com on 23 Sep 2011 at 7:53