Equivalent of a "return" within react{}?
Locked
Equivalent of a "return" within react{}?
 
|
Is there an equivalent of a "return" within react{} to skip the rest of the code processing for the current message? I tried 'reply' and sender.send, but to no avail.
I have created a default actor to process 2 message types in a Grails service. A controller invokes this service and the service api builds a message and sends it to the actor. During message processing, if i hit some error conditions, I want to stop processing further and return. When I hit an error as shown below, the actor falls through and executes the rest of the closure in react without returning. Surely I am missing something very basic!! My code is something like: class MyActor extends DefaultActor { void act() { loop { react { msg-> switch (msg.type) { case MyMsgType.TYPE1: // do stuff if (error) return // do more stuff // this gets executed (as shown by logs) even when i hit error earlier } // switch } // react } // loop } // act } class MyService { def grailsApplication def cfg MyActor someActor @PostConstruct def initActors() { someActor = new MyActor() someActor.start() } def processRegistration(Object userInfo) { /* * Send a message to the MyActor to continue further processing * asynchronously and return the main thread back to the * Controller */ def msg = new RegMsg(type:MyMsgType.TYPE1, msgObject:userInfo) someActor << msg log.debug("Delegated registerUser to Actor") return Status.REG_SUCCESS } } |
Re: Equivalent of a "return" within react{}?
|
|
After searching through other threads, I guess that is is recommended that I use dataflow task for my purpose (more lightweight etc). I tried to change my code to a dataflow task, where I have a 'return' on certain conditions (I did not use a dataflow variable as I do not want to really return any value) and I see the same behavior -- the code after a return gets executed each time. Does this have to do with the fact that the main grails thread which invoked this 'task' method is not waiting on this task to complete?
|
|
Administrator
|
I probably misunderstand your problem. If I'm reading your issue correctly, it seems you have code in principle similar to this: task { println 10 if (true) return
println 20 } or this: react { println 10 if (true) return println 20 } and you're getting both 10 and 20 in the output. This would be very strange if it happened, so I probably need more explanation. Vaclav On Thu, Jul 25, 2013 at 5:33 PM, reddevil08 <[hidden email]> wrote: After searching through other threads, I guess that is is recommended that I E-mail: [hidden email] Blog: http://www.jroller.com/vaclav Linkedin page: http://www.linkedin.com/in/vaclavpech |
Re: Equivalent of a "return" within react{}?
|
|
In reply to this post by reddevil08
After a lot of hair pulling, I figured out the problem.
I had a : MyDomainObj.withTransaction { // do something if (obj.x != ) return // continue to do more stuff } within the actor/dataflow task. Turns out that 'return' has no effect under the 'withTransaction' closure. I had to use 'status.setRollbackOnly()' to roll back the transaction and skip processing the rest of the code. Sorry for the alarm bells, I'm a groovy/grails/gpars newbie and I'm tripping over some wires as I learn stuff in this world. Kudos to writing a great library and some great documentation/examples. One feedback I'd like to provide is that since gpars seems to be used in Grails quite a bit, it would be helpful if you could add an example in the user guide for a Grails based use case. I looked up other blogs and sites for examples on how to use gpars within a grails service to enable concurrent processing. Thanks again! |
Re: Equivalent of a "return" within react{}?
|
|
I think there's still some misunderstanding here: in Groovy, when a return statement is reached in a closure, execution of the current closure ends. The only exception is when the return statement is within a try block with a corresponding finally block, in which case the finally block will be executed before the closure exits. Also, another way to exit a withTransaction block (or @Transactional) method in Grails is to throw a checked exception. This will cause the transaction to be rolled back without having to call setRollbackOnly(). Note that throwing an unchecked exception won't roll back the transaction, due to the way Spring works. Cheers, On 26 Jul 2013 02:34, "reddevil08" <[hidden email]> wrote:
After a lot of hair pulling, I figured out the problem. |
«
Return to GPars - user mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |