[akka-user] Re: combining Akka Persistence with Akka Scheduling

[Arkadiusz Burdach]

I've just created https://github.com/TouK/pscheduler which mixes Akka 
scheduler with slick jdbc persistence. It was rather made for tasks 
scheduled rarely but might be helpful.

Cheers,
Arek

W dniu poniedziałek, 23 marca 2015 19:12:22 UTC+1 użytkownik Ashley Aitken 
napisał:
>
>
> May I please ask if there has been any progress on this by anyone?  We 
> need durable timeouts for sagas in CQRS.
>
> Thanks,
> Ashley. 
>

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Reliable http request-response communication

[Arkadiusz Burdach]

 

Hi,


I want to share with you my little project: 
https://github.com/arkadius/reliable-http-client.

It's a http client that passes communication via AMQP queues to akka http 
super pool. This solution connected with ReliableFSM gives ability that 
you'll never loose your response from http service.


I know that the akka way is to send messages one way. But sometimes our 
applications need to communicate with systems that doesn't understand how 
to do this and it was the inspiration of this idea.


I'm looking forward for your opinion about this project.


Cheers,

Arek

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Simple, local, garbage collected actors

[Arkadiusz Burdach]

W dniu wtorek, 27 stycznia 2015 15:36:05 UTC+1 użytkownik rkuhn napisał:
>
> Hi Arkadiusz,
>
> 27 jan 2015 kl. 15:21 skrev Arkadiusz Burdach  >:
>
> Hi Konrad,
> Thanks for reply. More inlined.
>
> W dniu wtorek, 27 stycznia 2015 11:01:58 UTC+1 użytkownik Konrad Malawski 
> napisał:
>>
>> Please do not ever rely on java finalization – ever.
>>
>> For one thing, it's unreliable – no-one guarantees that these will ever 
>> be called. [60] 
>> <https://github.com/arkadius/akka-simple/blob/master/src/main/scala/akka/actor/simple/SimpleActor.scala#L60>
>> Also, just by having a finalizer defined you put a way larger burden on 
>> the collector as it has to track those in a similar way it does with 
>> java.lang.ref.* references (putting in reference queues etc instead of just 
>> reclaiming space).
>>
> It's true. In fact this finalize behaviour was only a hint for Actor. I 
> could provide other way to clenup internal actors for example repeated job 
> checking if SimpleActor was released. And also it is in't a core thing for 
> this implementation to cleanup an internal Actor. Core memory part will be 
> declared in SimpleActors which will be normally cleaned up by jvm.
>
>
> No matter how you implement this, it will always involve either 
> WeakReference or finalizers, both of which are the devil. There is no other 
> way—if there were then we’d already implemented this :-)
>

I'm not a specialist in usage of WeakReferences. In a simple cases it looks 
like they are usable (I've done performance tests). There are plans to 
remove them from JRE? If they are bad at all maybe we should create a 
ticket to remove them? According to second part of your answer it does mean 
that all realizable and usable features are already implemented? So mabye 
we should close possibility to create an enhancements in request tracker? 
;-)

Even if garbage collection won't work in all situations, you always could 
use PoisonPill which would be forwared to internal actor.

You should never block in your Actors when working with Akka. Remember the 
>> "never block" mantra :-)
>> Calling Await inside actor code is a big "no-no" – this will cause your 
>> entire application (everyone on that dispatcher) to suffer for it. [36] 
>> <https://github.com/arkadius/akka-simple/blob/master/src/main/scala/akka/actor/simple/SimpleActor.scala#L36>
>> Please refer to the documentation about actor systems 
>> <http://doc.akka.io/docs/akka/snapshot/general/actor-systems.html#actor-best-practices>
>>  
>> to read more about this.
>>
> Yes, I know this. Shortcut for Await was only added for purpose of quicker 
> Actor tests and it is minor think. I know that the best is to keep your 
> code as much async as it possible. But I think that it could be helpful to 
> just check how Actor will reply on request without using additional tools 
> like Await.
>
>  
>
>> In general I would not recommend wrapping Akka in such way and simply 
>> embracing the asynchronous nature of it.
>> You'll get better performance and fully-embracing these concepts instead 
>> of hiding it here and there will get you to cleaner code by the end of the 
>> day too.
>>
> Ok, but what do you think about shortcut for creating Actors by new 
> operator with auto-gc? I don't think about it as a subistitution but just 
> like a nice addition :-) I think that in many cases people use akka actors 
> for small applications that will be never used in cluster. For this simple 
> use case it is a little inconvenience to declare ActorSystem, provide 
> specialized ExecutionContext depend on situation, and keep thinking if 
> actors memory was released.
> I know background of all this things but tools should be selected depend 
> on situation :-)
>
>
> Auto-GC comes at too big a cost, but the main reason I would recommend 
> against this approach is that supervision is neglected: by only being able 
> to create top-level actors most of the advantages of the Actor model are 
> removed.
>
> If you are after a smaller syntax footprint you might want to check out 
> the ActorDSL 
> <https://github.com/akka/akka/blob/v2.3.9/akka-actor/src/main/scala/akka/actor/ActorDSL.scala>
>  which 
> uses an implicit ActorRefFactory for creation. It has been provided for 
> quickly sketching actor programs in the Scala REPL.
>
>
I've checked it out. It is nice syntax for some constructions. But as far 
as I know it has only a factories - you can't declare a new class, extend 
it and than new instances wouldn't be an Actors.

Thank you for feedback,
Arek

-- 
>>>>>

Re: [akka-user] Simple, local, garbage collected actors

[Arkadiusz Burdach]

Hi Konrad,
Thanks for reply. More inlined.

W dniu wtorek, 27 stycznia 2015 11:01:58 UTC+1 użytkownik Konrad Malawski 
napisał:
>
> Please do not ever rely on java finalization – ever.
>
> For one thing, it's unreliable – no-one guarantees that these will ever be 
> called. [60] 
> 
> Also, just by having a finalizer defined you put a way larger burden on 
> the collector as it has to track those in a similar way it does with 
> java.lang.ref.* references (putting in reference queues etc instead of just 
> reclaiming space).
>
It's true. In fact this finalize behaviour was only a hint for Actor. I 
could provide other way to clenup internal actors for example repeated job 
checking if SimpleActor was released. And also it is in't a core thing for 
this implementation to cleanup an internal Actor. Core memory part will be 
declared in SimpleActors which will be normally cleaned up by jvm.

 

> You should never block in your Actors when working with Akka. Remember the 
> "never block" mantra :-)
> Calling Await inside actor code is a big "no-no" – this will cause your 
> entire application (everyone on that dispatcher) to suffer for it. [36] 
> 
> Please refer to the documentation about actor systems 
> 
>  
> to read more about this.
>
Yes, I know this. Shortcut for Await was only added for purpose of quicker 
Actor tests and it is minor think. I know that the best is to keep your 
code as much async as it possible. But I think that it could be helpful to 
just check how Actor will reply on request without using additional tools 
like Await.

 

> In general I would not recommend wrapping Akka in such way and simply 
> embracing the asynchronous nature of it.
> You'll get better performance and fully-embracing these concepts instead 
> of hiding it here and there will get you to cleaner code by the end of the 
> day too.
>
Ok, but what do you think about shortcut for creating Actors by new 
operator with auto-gc? I don't think about it as a subistitution but just 
like a nice addition :-) I think that in many cases people use akka actors 
for small applications that will be never used in cluster. For this simple 
use case it is a little inconvenience to declare ActorSystem, provide 
specialized ExecutionContext depend on situation, and keep thinking if 
actors memory was released.
I know background of all this things but tools should be selected depend on 
situation :-)

Cheers,
Arek

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Simple, local, garbage collected actors

[Arkadiusz Burdach]

Hi all.

What do you think about an idea of module providing possibility to create 
actor by *new* operator eg.

val actor = new SimpleActor {
  override def receive: Receive = {
case _ => sender() ! "OK"
  }
}


Those actors would be garbage collected so there will be no need to send 
PoisonPIll them.

I've prepared proof of concept: https://github.com/arkadius/akka-simple

It will be usefull? Or maybe there is already other way to use this kind of 
syntax of actors?

Arek

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.