View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002970||SymmetricDS||Bug||public||2017-01-25 05:57||2017-11-05 20:57|
|Target Version||Fixed in Version|
|Summary||0002970: db connection leaks after engine stop|
I have embedded Symmetric DS 3.7.33 into my webapp. I have Web UI which allows user to start and stop Symmetric DS Engine.
When user click on Stop button, I internally call below method on server side:
Which first stop() and then destroy() the engine.
I found that after destroy() called if I check then there are few database connections are not closed (connection for database associated with given engine).
Overall, even after calling destroy() on engine, there are database connection leak.
I was expecting that once I call destroy() method all the database connection should be closed.
Please suggest if there is any other cleaner way to stop/destroy engine so that database connection leak is not happened or fix database connection leak issue with stop/destroy of engine.
|Steps To Reproduce||1. start source engine for source database with stream.to.file.enabled=true|
2. start target engine for target database.
3. make sure there is active data copy going on, like keep huge initial load and on start of both engine data is continuously getting copied from source to target.
4. stop source engine and stop target engine.
5. try to delete target database.
For step 5, delete of target database is failing with error that there are active connections.
I have also analyzed the issue. The issue happens when there is continuous data copy happening between source and target engine. This issue generally easily reproduce for initial load with some good amount of data to be copied.
When I call ClientSymmetricEngine.destroy(), it internally call AbstractSymmetricEngine.stop() in which thread.interrupt() is called for processInfo.getThread().
It happens that ..
1. ClientSymmetricEngine.destroy() is called at first
2. AbstractSymmetricEngine.stop() will be call
3. thread.interrupt() will be called
4. destroy() will call ((BasicDataSource)dataSource).close()
5. thread will throw org.jumpmind.exception.IoException: This thread was interrupted
Here, thread which got interrupted at step 3 is push thread with thread name "tnt3_rt-0000-push-1".
So, it happens that the push thread got interrupted at step-3 and dataSource.close() called before the push thread actually complete and got interrupt. This somehow leads to connection leaks for source database.
*One way to Fix:*
In AbstractSymmetricEngine.stop() after interrupting the thread, we should wait to join the thread.