View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001056 | SymmetricDS | Bug | public | 2013-02-22 02:37 | 2013-07-22 21:51 |
Reporter | chris.wright | Assigned To | chenson | ||
Priority | high | ||||
Status | closed | Resolution | fixed | ||
Product Version | 3.3.1 | ||||
Target Version | 3.5.0 | Fixed in Version | 3.5.0 | ||
Summary | 0001056: Sync on incoming batch causes ping-back when in common batch mode | ||||
Description | Data sometimes gets re-routed back to the source node when the following conditions are met: * You have sync_on_incoming batch enabled for more than one trigger using a shared channel * You are using the default router This only happens when the channel is in commons batch mode which re-uses batchIds within the same channelContext. (The issue is at /org/jumpmind/symmetric/service/impl/RouterService.java:568) | ||||
Steps To Reproduce | Setup: ROOT_NODE(ROOT_GROUP) / \ C1(CLIENT_GROUP) C2(CLIENT_GROUP) # Create two triggers on the root (tableA, tableB), both with sync_on_incoming_batch enabled sharing a common channel # Create a default router to route from ROOT_GROUP to CLIENT_GROUP # Insert data into tableA on C1 # Insert data into tableA on C2 # Route the data The data insertion from C2 actually gets routed back to C2 incorrectly | ||||
Additional Information | The test attached is an extra method for org.jumpmind.symmetric.service.impl.AbstractRouterServiceTest. | ||||
Tags | No tags attached. | ||||
|
|
|
Can you provide a specific test scenario? The channel should not be common if there is data being synchronized for the same table in both directions. Is the bug the fact that we made a channel common and it should not have been? Are the same tables that are syncing bi-bidirectionally on different channels? |
|
The error does seem to be that the channel is recognised as common batch mode but also seems like there could be other issues due to the cache across the channel context during routing since the target node_id could be wrong. Yes the data is synchronized up and down for the same tables in both directions (via different channels and triggers). The attached test code on the case should allow you to see the effects / configuration case that causes the ping-back but here is the test scenario as well: Specific test scenario: We have a few tables (Contacts, Orders) created on each client which is then synchronized up-to the root node (via a 'client_to_root-Orders' channel). We then have sync_on_incoming batch on triggers for these tables to allow the data to flow down to remaining clients (via a 'root_to_client-Orders' channel). The data created from client node A, syncs upto the root node then a batch gets created which ends up routing the data back to client NODE-A due to the re-use of the batch cached in the channel context map. |
|
I think this is fixed. Austin, can you verify? |
|
prepare for release |
Date Modified | Username | Field | Change |
---|---|---|---|
2013-02-22 02:37 | chris.wright | New Issue | |
2013-02-22 02:37 | chris.wright | File Added: PingBackTest.java | |
2013-02-23 02:49 | chenson | Note Added: 0000217 | |
2013-02-24 23:19 | chris.wright | Note Added: 0000219 | |
2013-06-08 15:08 | chenson | Note Added: 0000271 | |
2013-06-08 15:08 | chenson | Target Version | => 3.5.0 |
2013-06-08 15:08 | chenson | Assigned To | => abrougher |
2013-06-08 15:08 | chenson | Status | new => assigned |
2013-07-09 00:24 | chenson | Status | assigned => resolved |
2013-07-09 00:24 | chenson | Fixed in Version | => 3.5.0 |
2013-07-09 00:24 | chenson | Resolution | open => fixed |
2013-07-09 00:24 | chenson | Assigned To | abrougher => chenson |
2013-07-22 21:51 | chenson | Note Added: 0000312 | |
2013-07-22 21:51 | chenson | Status | resolved => closed |