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.
