View Issue Details

IDProjectCategoryView StatusLast Update
0001056SymmetricDSBugpublic2013-07-22 17:51
Reporterchris.wrightAssigned Tochenson 
Status closedResolutionfixed 
Product Version3.3.1 
Target Version3.5.0Fixed in Version3.5.0 
Summary0001056: Sync on incoming batch causes ping-back when in common batch mode
DescriptionData 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/
Steps To ReproduceSetup:
          / \

# 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 InformationThe test attached is an extra method for org.jumpmind.symmetric.service.impl.AbstractRouterServiceTest.
TagsNo tags attached.



2013-02-21 21:37

reporter (2,634 bytes)


2013-02-22 21:49

administrator   ~0000217

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?


2013-02-24 18:19

reporter   ~0000219

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.


2013-06-08 11:08

administrator   ~0000271

I think this is fixed. Austin, can you verify?


2013-07-22 17:51

administrator   ~0000312

prepare for release

Issue History

Date Modified Username Field Change
2013-02-21 21:37 chris.wright New Issue
2013-02-21 21:37 chris.wright File Added:
2013-02-22 21:49 chenson Note Added: 0000217
2013-02-24 18:19 chris.wright Note Added: 0000219
2013-06-08 11:08 chenson Note Added: 0000271
2013-06-08 11:08 chenson Target Version => 3.5.0
2013-06-08 11:08 chenson Assigned To => abrougher
2013-06-08 11:08 chenson Status new => assigned
2013-07-08 20:24 chenson Status assigned => resolved
2013-07-08 20:24 chenson Fixed in Version => 3.5.0
2013-07-08 20:24 chenson Resolution open => fixed
2013-07-08 20:24 chenson Assigned To abrougher => chenson
2013-07-22 17:51 chenson Note Added: 0000312
2013-07-22 17:51 chenson Status resolved => closed