Eventually, it's a little touchy since I did replayed some tests all day long in order to notice again the issue (with SDN) for hours; without managing to reproduce it :( If it happens again, I will make a very deep analysis before arguing "it's the fault of SDN" ;)
My thought is that in some rare cases, my Neo4j instance doesn't process the "command" of committing the transaction (tx.success()) quickly enough. That would explain why the next "events retrieval" loop (starting just 1 second after the instruction of the commit command) still get the same event. Indeed, I would easily imagine that the retrieval of 1 "NEW" indexed Event (done by the next loop) might take less than 10ms, so just about 1 sec and 10ms after the neo4j instance starts to process the transaction commit. Therefore, retrieval might happen BEFORE the transaction commit finished its job. Just my 2 cents ;) Michael On Tuesday, August 12, 2014 12:53:28 PM UTC+2, Michael Azerhad wrote: > > I forgot to point out that I'm using the REST mode, more relevant to a > potential async behaviour.., just for the info. > > On Tuesday, August 12, 2014 12:48:08 PM UTC+2, Michael Azerhad wrote: >> >> I didn't try without SDN .. >> I'm reading the actual code of SDN to detect something that could be >> linked but I'm only seeing pure synchronous call. >> Will try now to make it without SDN at all :) >> >> Is it really "absurd" to think of an async behaviour of transaction >> commit? Or is it quite possible? >> >> >> On Tuesday, August 12, 2014 12:39:01 PM UTC+2, Michael Hunger wrote: >>> >>> Would you be able to reproduce it without SDN, just plain neo and >>> ExecutionEngine? >>> >>> Sent from mobile device >>> >>> Am 12.08.2014 um 12:36 schrieb Michael Azerhad <[email protected]>: >>> >>> Hi, >>> >>> I'm using SDN 3.1.2 with Neo4j 2.1.2. >>> >>> I have this (simple) Akka code (a worker actor retrieving new events in >>> a kind of loop to consume them): >>> >>> def receive = { >>> case RetrieveNewEvents => >>> val tx = graphDatabaseService.beginTx() //starts transaction >>> try { >>> val newEvents = eventRepository.findNewEvents( >>> EventBatchSizeProperty) //involving @Query("MATCH (e:Event:New) RETURN >>> e ORDER BY e.occurredOn LIMIT {0}") >>> newEvents.foreach { >>> event => { >>> log.info("sending event: " + event.id + " to eventStream") >>> context.system.eventStream.publish(event) // sent event >>> to consumers - no importance for the issue >>> log.info("event sent to actors to be consumed !") >>> eventRepository.flagAsConsumed(event.id) // involving >>> @Query("MATCH (e:Event {_id: {0}}) REMOVE e:New SET e:Consumed return e") >>> log.info("event: " + event.id + " flagged as consumed !") >>> } >>> } >>> tx.success() // commit the transaction >>> } >>> catch { >>> case e: Throwable => log.info(e.getMessage) >>> } >>> finally { >>> tx.close() //close the transation >>> system.scheduler.scheduleOnce(EventListenerScheduleProperty >>> seconds, self, RetrieveNewEvents) // loop again by sending a >>> RetrieveNewEvents after 1 second >>> } >>> } >>> >>> I noticed that for some events, I retrieved them more that once (written >>> in my logs)... as if the transaction was not commited, meaning that the >>> label was not set to CONSUMED yet. >>> Obviously, if was not set to CONSUMED before the next loop, it would be >>> retrieve again since still viewed as NEW. >>> >>> My question is: >>> >>> May it possible that tx.success() or tx.close() works...asynchronously?! >>> It seems absurd but it sounds to be the only explanation I guess for >>> retrieving more than once the same event. >>> I tried to update the duration from 1 second to 3 seconds, and now the >>> whole works without this issue. >>> >>> Is there an apparent issue in my code that I may ignore? Why timing is >>> important here? >>> >>> Thanks a lot, >>> >>> Michael >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Neo4j" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
