View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004207||SymmetricDS||Bug||public||2019-12-17 09:23||2019-12-17 09:23|
|Summary||0004207: Reload-node fails, error writing batch into staging|
|Description||Version of Sybase running: Adaptive Server Enterprise/16.0 SP03|
Version of MySQL running: 8.0.13
I was using SymmetricDS 3.9.14 and decided to upgrade it to the latest version 3.11.2 but when I try to issue the reload-node command
/symadmin --engine sybase-001 reload-node mysql-002
I see this error message appear on my log file:
2019-12-16 15:13:20,464 ERROR [mysql-002] [SimpleStagingDataWriter] [mysql-002-pull-default-2] Failed to write batch into staging from sybase:001:001. java.net.SocketTimeoutException: Read timed out
2019-12-16 15:13:30,378 INFO [sybase-001] [ConcurrentConnectionManager] [qtp1931444790-18] Node '002' Channel 'default' requested a /sync/sybase-001/pull connection, but was rejected because it already has one
2019-12-16 15:13:30,380 INFO [mysql-002] [PullService] [mysql-002-pull-default-3] Remote node sybase-:001:001 at http://localhost:31415/sync/sybase-001 was busy
Seems like reading from the sym_outgoing keeps timing out for some reason? Whenever SymmetricDS service is running, I cannot seem to run a Read SQL command onto any of the sym_tables they all appear to be locked. When I checked to see number of opened connections on the database, I do notice that SymmetricDS appears to be opening up a lot more connections than it previously did (when I was running version 3.9.14).
According to my database some of those connections are on "lock sleep" which refers to process waiting for locks to be released. I have no other processes running that uses those sym_tables, just SymmetricDS. A number of those connections are being blocked by process id 212, and that 212 belongs to SymmetricDS which is appearently just "AWAITING COMMAND". I tried killing the process, but then same thing happens again and the rest of the connections are waiting on another connection (I assume its the same process, which just opens a new connection) to release the locks.
I do see these INFO message appear below as well, not sure if these messages are just a sympton from the error that occured before. But neither of these messages were appearing when I was running 3.9.14 version.
I never had issues running the reload-node command on 3.9.14.
|Tags||No tags attached.|