Reputation: 468
I have encountered a strange "Invalid Packet Lenght" (that is how the error is spelled) error when I run an automated bulk test on some of my Java code and I hope that someone has either encountered this error before or can point me in the right direction.
I do not encounter this error when testing my code via JUnit unit tests or from the GUI. I only encounter this error on my automated bulk test. A little bit about my bulk test: for some inputs my code will run for a long time (that's to be expected), but in order to speed up the results to a more reasonable time frame I'm creating a new thread to run each individual test so that I can stop the test after some given maximum elapsed time.
Note that both the test and the actual code need to connect to the same database instance to load data. The actual code uses a single connection to read from the database (it is not multi-threaded). I'm still trying to figure out the best way for the test to connect to the database (hence this question).
My first thought was that I am doing something unfriendly in the way I close my test thread to quit the run early. I'm calling the deprecated
threadObject.stop();
method since my actual code is not multi-threaded an there is no "friendly" way to kill the thread built in. After a few (~2-3) stopped threads, my JDBC connection throws one "Invalid Packet Lenght" error followed by "Socket closed" exceptions for the rest of the tests.
I've tried all of these with the same results:
I have determined that of the two connections, "test" and "actual", the "test" connection is the one that throws the exception.
Configuration:
What am I doing wrong? Is there a different way I should handle my "test" connection? Do I need to re-architect my "actual" connection just to run a bulk test? What causes the "Invalid Packet Lenght" error?
Upvotes: 2
Views: 4621
Reputation: 10461
I don't really understand what are you trying to accomplish with your bulk test, so I will offer some general advice regarding threading and Connection
s that I know of:
Perhaps one of your threads is leaving a connection in invalid state. What happens to connection when thread is stopped? In general terms, you should have a place where you wait()
for an InterruptedException
instead of stopping the thread in mid-operation. A Connection
should be closed in a finally
block, regardless of whether an exception occurred or not.
If you want a timeout for a JDBC operation, use Statement.setQueryTimeout().
Consider using a connection pool, like C3P0. It's really easy to set up in code, have a look at this in particular. It will take care of most of the connection set-up/tear-down and provide your code with valid, ready-to-use connection.
Consider using Java's own java.util.concurrent package, rather than rolling out your own execution strategy. Have a look at Executors and ExecutorService classes - they provide means of executing a task in separate thread, and setting up a timeout.
Hope some of this helps.
Upvotes: 2