{"push_id":561808153,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"166c432bc0611288abf2e13ef8f184cfbb2c101a","before":"37f0504d391efd8b7d61403759fcc22a6dd3a093","commits":[{"sha":"166c432bc0611288abf2e13ef8f184cfbb2c101a","author":{"email":"8fc992100aff336363d341c5498f75ab4da389ae@brocade.com","name":"tpantelis"},"message":"Bug 2650: Fix ConcurrentModificationEx in TransactionProxy\n\nThere were a couple patches proposed by other folks. Gary's patch\nhttps://git.opendaylight.org/gerrit/#/c/14577/ to use a BlockingQueue\nwould work and is slightly simpler code but I prefer to avoid the unneeded synchronization\noverhead that BlockingQueue carries as we still need explicit\nsynchronization for atomic access to txOperationsOnComplete and\ntransactionContext.\n\nI implemented something similar to Robert's propopsal in\nhttps://git.opendaylight.org/gerrit/#/c/14565/ .\n\nI added a unit test that does a transaction put after an async read but\nunfortunately it didn't reproduce the issue due to the behavior of the\nakka dispatcher in the unit tests. The read future callback is batched\nby the dispatcher even when using the CallingThreadDispatcher so the\nsynchronous read callback isn't achieved. Somehow the threading behavior\nis different in the producton system. Regardless I kept the unit test\nanyway - better than not haviing it.\n\nChange-Id: I70f4e2507411c63cff99d03bf046c65e78a8138e\nSigned-off-by: tpantelis <tpanteli@brocade.com>","distinct":true,"url":"https://api.github.com/repos/mandeepdhami/controller/commits/166c432bc0611288abf2e13ef8f184cfbb2c101a"}]}