How to execute the defer-callback before processing the next command?

[Anders Båtstrand]

Dear users

I find the semantics of "defer" confusing.

I thought defer was the same as persist, except the given message was not persisted. Now today, when a bug got me to read the doc again, it states that defer has the same semantics as persistAsync.

My first thought was that "defer" should be renamed "deferAsync", to communicate the relation to persistAsync. Both are async, but the point is that persist is executed before the next command is processed, while persistAsync is not.

Names aside, is there a function similar to defer, that is guaranteed to be executed before the next command is processed?

Best regrads,

Anders Båtstrand

[Patrik Nordwall]

Hi Anders,

On Wed, Feb 4, 2015 at 2:23 PM, Anders Båtstrand <ande...@gmail.com> wrote:

Dear users

I find the semantics of "defer" confusing.

I thought defer was the same as persist, except the given message was not persisted. Now today, when a bug got me to read the doc again, it states that defer has the same semantics as persistAsync.

My first thought was that "defer" should be renamed "deferAsync", to communicate the relation to persistAsync. Both are async, but the point is that persist is executed before the next command is processed, while persistAsync is not.

That might be a good point. Please create an issue.

 

Names aside, is there a function similar to defer, that is guaranteed to be executed before the next command is processed?

Isn't that the same thing as performing the thing immediately when the command is received? 

I would find it interesting to understand what you are trying to do and why.

As I see it, there are two approaches.

1) Use `persist`, then all incoming commands are stashed until the outstanding `persist` tasks are completed.

2) Use `persistAsync` and `defer` for *all* incoming commands that have an ordering dependency to outstanding `persistAsync` and other `defer` tasks. Other commands that don't have this ordering requirement can be processed immediately.

Regards,

Patrik

 

Best regrads,

Anders Båtstrand

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

--

Patrik Nordwall
Typesafe -  Reactive apps on the JVM
Twitter: @patriknw

[Anders Båtstrand]

Done: https://github.com/akka/akka/issues/16797

The reason I am missing the "defer" that executes before the next message is processed, is because I am re-using the callbacks.

Callbacks in Java are so verbose that I create re-usable components of simple tasks like apply-this-message-to-the-state-object.

My problem was this:

I have a parent actor, which forwards the message to a child actor based on some ID. In case the ID is unknown, it persists a "create-child"-event. After that callback executed, the actor is created. In a "defer"-callback, I then forwards the message to the child actor.

If the ID is known, the parent forwards directly.

The problem was message ordering. Since the "defer" was sometimes executed AFTER the next message was forwarded, the messages arrived out-of-order.

In my case I solved it by creating yet another re-usable callback, that created a new actor AND forwarded the message to it.

Best regards,

Anders

[Patrik Nordwall]

On Mon, Feb 9, 2015 at 1:30 PM, Anders Båtstrand <ande...@gmail.com> wrote:

Done: https://github.com/akka/akka/issues/16797

The reason I am missing the "defer" that executes before the next message is processed, is because I am re-using the callbacks.

Callbacks in Java are so verbose that I create re-usable components of simple tasks like apply-this-message-to-the-state-object.

public void <A> runCallback(A event, Procedure<A> handler) {

  handler.apply(event);

}

:) ?

 

My problem was this:

I have a parent actor, which forwards the message to a child actor based on some ID. In case the ID is unknown, it persists a "create-child"-event. After that callback executed, the actor is created. In a "defer"-callback, I then forwards the message to the child actor.

If the ID is known, the parent forwards directly.

The problem was message ordering. Since the "defer" was sometimes executed AFTER the next message was forwarded, the messages arrived out-of-order.

In my case I solved it by creating yet another re-usable callback, that created a new actor AND forwarded the message to it.

Best regards,

Anders

onsdag 4. februar 2015 14.23.23 UTC+1 skrev Anders Båtstrand følgende:

Dear users

I find the semantics of "defer" confusing.

I thought defer was the same as persist, except the given message was not persisted. Now today, when a bug got me to read the doc again, it states that defer has the same semantics as persistAsync.

My first thought was that "defer" should be renamed "deferAsync", to communicate the relation to persistAsync. Both are async, but the point is that persist is executed before the next command is processed, while persistAsync is not.

Names aside, is there a function similar to defer, that is guaranteed to be executed before the next command is processed?

Best regrads,

Anders Båtstrand

--

>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[Anders Båtstrand]

If you add an inline implementation of the Procedure (without lambdas,
I am stuck with Java 7), it gets verbose, after my taste... :-)

Anders

> You received this message because you are subscribed to a topic in the

> Google Groups "Akka User List" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/OHCRAkYbAZ4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[Patrik Nordwall]

On Mon, Feb 9, 2015 at 2:50 PM, Anders Båtstrand <ande...@gmail.com> wrote:

If you add an inline implementation of the Procedure (without lambdas,
I am stuck with Java 7), it gets verbose, after my taste... :-)

I was half serious. My point is that you should be able to add such a thing yourself and there should not be a need for an additional method in UntypedPersistentActor. Did I misunderstood something?

/Patrik