Why do you need to integrate them? Akka.net has some scheduling capability built-in.
@hhko there is no such integration plugin AFAIK. I've seen two on JVM side (eg: https://github.com/theatrus/akka-quartz) - it would be nice if someone consider making one on the .NET side too
any idea why F# api logException function doesn't let you log your own message with the exception?
just not implemented or by design?
@Horusiath @hhko just wanted to understand specific use case, and what the expectations from integrations are besides using .Tell inside an ExecuteJob.
@maxim-s great! :) would you like to set an issue for that?
i am creating it allready with .WithDeploy(Deploy.Local);
its working fine in the user path, but it should be optimaly in the temp path
If you really need it, once I've created an example that allowed to combine ask/reply pattern with linq
but seriously I don't see what you might need it for
i have an own inbox that implements IObservable so i can subscribe to it and send a request and getting the responses back
how to create the temp actor from ActorSystem? I am creating it currently with
var receiver = system.ActorOf(PNetObserverActor.Props(subject), name);
never saw IActorRefProvider
you probably never saw it because it should remain an implementation detail
You created an IActorRef like a router, i am using ActorBase for the receiver
yes, that's one of indicators pointing that having custom actors under temp path is bad for health
its a short lived actor that is created .WithDeploy(Deploy.Local) I think the normal inbox is created in the temp too or not?
@maxim-s if you complete it, please notify it for us.
Send specifies a message that should be delivered only to one subscriber in target topic. Actor choice is based on specified RoutingLogic, which is random by default. Additionally with localAffinity flag set we may define to prefer sending the messages to subscribers on the same node if possible i.e. for performance reasons.
isn't this incorrect?
the subscription topic isn't used at all
rather, it only allows you to send a message to an actor who has registered itself via
Put
and you can explicitly address that actor via
Send(actorPath, message, localAffinity: bool)
which honestly is 100000% less useful than being able to do what the documentation describes
being able to publish a message to a single subscriber for a topic
the way it works right now is basically an actor selection against a single member in a cluster, so long as they've registered
so what I'm trying to understand is: is the documentation wrong or is the implementation wrong?
heh @Aaronontheweb you know how to ask difficult question
wait a sec
from Scala docs:
The message will be delivered to one recipient with a matching path, if any such exists in the registry. If several entries match the path because it has been registered on several nodes the message will be sent via the supplied RoutingLogic (default random) to one destination.
so I think it is a mistake in our docs
because that would have been really useful
PublishToOne
great for scenarios where you don't want to know where the actor is
and you need at most one actor to handle it
Actors may also be subscribed to a named topic with an optional property (group). If subscribing with a group name, each message published to a topic with the (sendOneMessageToEachGroup) flag is delivered via the supplied RoutingLogic (default random) to one actor within each subscribing group. If all the subscribed actors have the same group name, then this works just like Send and all messages are delivered to one subscriber. If all the subscribed actors have different group names, then this works like normal Publish and all messages are broadcast to all subscribers.
btw. @Aaronontheweb not so much time has passed, and there is another benchmarking lib in .NET ;)
[Missing <summary> documentation for "T:Akka.Cluster.Tools.PublishSubscribe.Publish"]
c'mon man - need those XML-docs :p
I have no idea what those fields do
yeah I actually use Benchmark.NET inside NBench to verify its performance
has no assertion capabilities built into it and only measuresthroughpuit
but it does that really well
can also test perf across multiple JITers
:+1:
[Missing <summary> documentation for "T:Akka.Cluster.Tools.PublishSubscribe.Publish"]
Meh someone else ... @sean-gilliam ... will do it ;P
<3