I think there are a few things that should be treated separately:
* How to organize bigger route structures?
* How to implement some parts of the route structure as actors?
As Roland wrote before, a Route is just an alias for a function
`RequestContext => Future[RouteResult]`. This gives you utmost flexibility
to structure and implement your routes in every asynchronous way.
Implementing server behavior in terms of the DLS's `Route` enables you to
compose your handling logic in a flexible and scalable way while
centralizing error and failure logic (as rejection and exception handlers).
The routing DSL provides a composable way to specify route logic. For a
bigger service, it might become a challenge how to organize different
routes into different files. You can put everything in one file if that's
what you like but it's not the recommended way. As a Route can be just a
value we don't force you into a specific kind of dependency injection logic
or architecture. It's possible to pass context around, use implicits, the
cake pattern or any other kind of dependency injection library or
architecture. In this way, Akka HTTP gives you layers to work with but it's
not a framework that forces you how to structure your application. We know
that this leaves some challenges to the user and we know that giving more
guidance in the documentation would be helpful (and we are planning to
provide more examples and tutorials on those topic in the future).
Using (request) actors to implement parts of the route tree is a technique
which is orthogonal to the code structure question. Repeating the important
piece: a Route is just an alias for a function `RequestContext =>
Future[RouteResult]`. That means that you can put in every function which
implements this type at every point in the route structures. If your route
processing is stateful and should be implemented in an actor that's
completely fine. The most general way to implement that in a route is by
using
def handleByActor(actor: ActorRef): Route = ctx => (actor ?
ctx).mapTo[RouteResult]
and handle that request in the actor.
However, it might be, that the original point of extracting code into an
actor isn't as strong a case any more as it was for spray as routes are now
just returning a Future. If you organize all asynchronous data collection
into methods returning a Future[XYZ], then you can package all validation
and processing into directives. After that's done you can express
everything in a route without the need for any actors.
One point with the route structure seems to be that it requires closing
over the extracting variables to be concise, if you have this kind of route
tree
pathPrefix("user" / Segment) { user =>
session { session =>
parameters('a, 'b, 'c) { (a, b, c) =>
userRoute(user, session, a, b, c)
}
}
}
and you want to implement the innermost route somewhere else. Then you have
to pass all these information explicitly to the inner route. That can be
cumbersome if the context you have extracted from is big. However, in most
cases the information is still layered in some ways, so it can make sense
to package up intermediate information into case class instances or to
factor out things differently. Another pattern could be to provide the
outer routes or parts of it as another directive so that it can be reused
in different parts. We recommend to use routes and directives as they tend
to be composable and reusable. If you put code into actors it can be harder
to reuse as actor code often relies on particular messages and asynchronous
protocols to work correctly.
Johannes
On Sunday, April 9, 2017 at 1:25:36 PM UTC+2, Dominik Dorn wrote:
>
> what a coincidence that I just stumbled upon this thread. I've created a
> feature request for "actor per request" a few days back in the
> playframework.
> https://github.com/playframework/playframework/issues/7183
>
> While I was thinking in terms of Play, maybe this is really best suited in
> the akka-http layer.
> I also liked the approach lightbend took in "lagom".. there they (it least
> it looks like they do) transparently convert "service calls" into
> actors, input datatypes&route information into a "Request" message and are
> just waiting for a "Response" message to send back to
> the user, e.g. like in
>
> https://www.lagomframework.com/documentation/1.3.x/scala/api/index.html#com.lightbend.lagom.scaladsl.api.ServiceCall
>
> https://www.lagomframework.com/documentation/1.3.x/scala/api/index.html#com.lightbend.lagom.scaladsl.api.transport.RequestHeader
>
> https://www.lagomframework.com/documentation/1.3.x/scala/api/index.html#com.lightbend.lagom.scaladsl.api.transport.ResponseHeader
>
> the code posted above
> case HttpRequest(POST, Uri.Path("/hello"), _, _, _) =>
> invokeActor(classOf[HelloActor], requestId, request)
> already looks a lot like what I was thinking of.
>
>
>
>
> On Sun, Apr 9, 2017 at 2:34 AM, Richard Rodseth <[email protected]>
> wrote:
>
>> DSL.
>> Route contains:
>>
>> onSuccess(requestHandler ? RequestHandler.AskForStatus) { ... }
>>
>> On Sat, Apr 8, 2017 at 2:31 PM, kraythe <[email protected]> wrote:
>>
>>> And you accomplish this with the low level or DSL api.
>>>
>>> On Saturday, April 8, 2017 at 12:56:26 AM UTC-5, rrodseth wrote:
>>>>
>>>> I use per-request actors. The only ask() is in the route, and is sent
>>>> to a RequestHandler actor. The RequestHandler creates a per-request actor
>>>> with the sender as a Props/Constructor parameter ("requestor"), and sends
>>>> it a "Run" message.
>>>>
>>>> The per-request actor can coordinate with as many actors as it needs
>>>> to. It can use "self" as a "replyTo" property of messages it sends out
>>>> (tell). It sends the final result back to its "requestor" and stops itself.
>>>>
>>>> With Spray I didn't need the outermost ask(), but I think it's fine
>>>> having one at the outermost layer.
>>>>
>>>> On Fri, Apr 7, 2017 at 9:45 PM, kraythe <[email protected]> wrote:
>>>>
>>>>> A very interesting read and I appreciate you showing examples. What I
>>>>> do wonder about there is what the situation is when the server has to do
>>>>> more than simply return information from a database or other similar web
>>>>> rest-ui simple examples. For example, I have processes that require
>>>>> aggregating data from several actors to complete the process. Now I could
>>>>> do these in a series of ASKs but then that would feel like a complete
>>>>> anti-pattern to me. I would rather model the system as an entirely one
>>>>> way
>>>>> calling pattern where the only future is in the final completion of the
>>>>> route. So here is the challenge:
>>>>>
>>>>> You have a route called /customerInfo which finds the search
>>>>> parameters out of the JSON body that is passed to the api. Then it has to
>>>>> invoke calls to two ProductManagerActor and InventoryManagerActor.
>>>>> These actors will send back responses which might result in the task
>>>>> being
>>>>> done but will be much more likely to require calling actor
>>>>> ShippingStatusActor
>>>>> several times to ask for different pieces of data. Once you have
>>>>> collected all of the data then finally you can assemble the JSON
>>>>> response.
>>>>> Yes. I could model this imperatively with futures and using the ask
>>>>> pattern
>>>>> inside the route but then I am massively constrained resources and I have
>>>>> never found that to be scalable under load. Indeed I try to avoid futures
>>>>> as much as I can because of these difficulties. I would prefer instead to
>>>>> have an actor handle the request, recieving messages from the three
>>>>> actors
>>>>> and then when it has assembled all of the data it would generate a
>>>>> response
>>>>> or if there is a timeout or exception it would generate other responses.
>>>>>
>>>>> Now using the route DSL I wonder how you would manage this process
>>>>> within your route files. At some point you have to jump off the DSL and
>>>>> offload the task to an actor. For example you can decode the parameters
>>>>> and
>>>>> the body and so on using the route but then you have to start the process
>>>>> of collecting this massive amount of data to send back and then you are
>>>>> off
>>>>> the route and your options are now limited as to how you can respond. You
>>>>> cant simply say inside the DataCollectionActor to invoke the bad
>>>>> request response, through the DSL. you now have to use the low level API
>>>>> to
>>>>> signal a response.
>>>>>
>>>>> I would be curious how you could handle this use case with the DSL.
>>>>>
>>>>> -- Robert
>>>>>
>>>>>
>>>>> On Tuesday, April 4, 2017 at 2:38:52 AM UTC-5, Daniel Stoner wrote:
>>>>>>
>>>>>> Hi Kraythe,
>>>>>>
>>>>>> Perhaps it helps to see a real world example that we've been working
>>>>>> on - with a good number of routes involved.
>>>>>>
>>>>>> This is from our AkkaHttpServer class. It's job is to inject all the
>>>>>> routes (ordersV2, searchv3, searchTerms, persistence) which consist of
>>>>>> around 6 actual endpoints per injected class - into the right point in
>>>>>> the
>>>>>> hierarchy (Below the oAuth2 authenticator and any request/response
>>>>>> loggers
>>>>>> and whatnot that you may need).
>>>>>>
>>>>>> We define index.html and healthcheck route in this class since they
>>>>>> are one liners that live above oAuth2 security otherwise we would also
>>>>>> inject them independently.
>>>>>>
>>>>>> Route indexRoute = get(() -> route(pathSingleSlash(() ->
>>>>>> getFromResource("web/index.html"))));
>>>>>> Route healthCheck = get(() -> path(PATH_HEALTH_CHECK, () ->
>>>>>> extractRequestContext(healthCheckHandler::handle)));
>>>>>>
>>>>>> Route apis = route(
>>>>>> indexRoute,
>>>>>> healthCheck,
>>>>>> oauth2Authentication(
>>>>>> accessTokenVerifier,
>>>>>> route(
>>>>>> ordersV2,
>>>>>> searchV3,
>>>>>> searchTerms,
>>>>>> persistence
>>>>>> )
>>>>>> )
>>>>>> );
>>>>>>
>>>>>> return logRequestResult(
>>>>>> this::requestMethodAsInfo,
>>>>>> this::rejectionsAsInfo,
>>>>>> () -> handleExceptions(
>>>>>> exceptionHandlerLogAndReturnInternalError(),
>>>>>> () -> handleRejections(
>>>>>>
>>>>>> rejectionHandlerLogAndReturnNotFound(),
>>>>>> () -> apis
>>>>>> )
>>>>>> )
>>>>>> );
>>>>>>
>>>>>> Note the *handleExceptions *and *handleRejections* methods.
>>>>>> Basically if your in the depths of a route (the bit supposed to handle
>>>>>> the
>>>>>> request) you have 3 options.
>>>>>>
>>>>>> 1) Handle the request and reply with a HttpResponse.
>>>>>> return
>>>>>> HttpResponse.create().withStatus(StatusCodes.CREATED).addHeader(
>>>>>> RawHeader.create(HttpHeaders.LOCATION, location)
>>>>>> )
>>>>>> 2) Reject the request with an explicit Rejection
>>>>>> return reject(Rejections.authorizationFailed());
>>>>>> 3) Throw an exception directly
>>>>>> throw new MyCustomException("Something went dodgy here!")
>>>>>>
>>>>>> Now how you transpose those rejections or exceptions into a
>>>>>> HttpResponse is up to your generic rejection or exception handler right
>>>>>> at
>>>>>> the very top of your routes. I've included our 'ErrorHandlingDirectives'
>>>>>> class which we simply extend (Instead of extending AllDirectives)
>>>>>> wherever
>>>>>> we need this:
>>>>>>
>>>>>> public class ErrorHandlingDirectives extends AllDirectives {
>>>>>>
>>>>>> private static final Logger LOG =
>>>>>> LoggerFactory.getLogger(ErrorHandlingDirectives.class);
>>>>>>
>>>>>> public LogEntry requestMethodAsInfo(HttpRequest request,
>>>>>> HttpResponse response) {
>>>>>> String headers = toCensoredHeaderJson(request.getHeaders());
>>>>>>
>>>>>> return LogEntry.create(
>>>>>> "Server has received a request\n"
>>>>>> + request.method().name() + " " +
>>>>>> request.getUri().toString() + "\n"
>>>>>> + headers + "\n"
>>>>>> + "Server responded with a response\n"
>>>>>> + response.status() + "\n"
>>>>>> + "Content-Type: " +
>>>>>> response.entity().getContentType().toString() + "\n"
>>>>>> + "Content-Length: " +
>>>>>> response.entity().getContentLengthOption().orElse(-1),
>>>>>> InfoLevel());
>>>>>> }
>>>>>>
>>>>>> public LogEntry rejectionsAsInfo(HttpRequest request,
>>>>>> List<Rejection> rejections) {
>>>>>> String headers = toCensoredHeaderJson(request.getHeaders());
>>>>>>
>>>>>> return LogEntry.create(
>>>>>> "Server has received a request\n"
>>>>>> + request.method().name() + " " +
>>>>>> request.getUri().toString() + "\n"
>>>>>> + headers + "\n"
>>>>>> + "Server responded with a rejection\n"
>>>>>> +
>>>>>> rejections.stream().map(Rejection::toString).collect(Collectors.joining("\n")),
>>>>>> InfoLevel());
>>>>>> }
>>>>>>
>>>>>> public ExceptionHandler
>>>>>> exceptionHandlerLogAndReturnInternalError() {
>>>>>> return ExceptionHandler
>>>>>> .newBuilder()
>>>>>> .matchAny(throwable -> extractRequest(request -> {
>>>>>> LOG.warn("Error on route: " +
>>>>>> request.method().value() + " " + request.getUri().toString() + " " +
>>>>>> throwable.getMessage(), throwable);
>>>>>> return
>>>>>> complete(StatusCodes.INTERNAL_SERVER_ERROR);
>>>>>> })
>>>>>> ).build();
>>>>>> }
>>>>>>
>>>>>> public String toCensoredHeaderJson(Iterable<HttpHeader> headers) {
>>>>>> return StreamSupport
>>>>>> .stream(headers.spliterator(), false)
>>>>>> .map(header -> {
>>>>>> if (header instanceof Authorization) {
>>>>>> return header.name() + ": CENSORED";
>>>>>> }
>>>>>> return header.name() + ": " + header.value();
>>>>>> })
>>>>>> .collect(Collectors.joining("\n"));
>>>>>> }
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>> So - yes you 'can' write 1 big file with a bazillion routes in it -
>>>>>> or you can do what most developers do eventually once things are working
>>>>>> and split it down into lots of individual classes with their own
>>>>>> hierarchy.
>>>>>> Have some general rules for your approach (such as if someone throws a
>>>>>> BeanVerifiyException you return a particular type of HTTP status code)
>>>>>> and
>>>>>> you'll soon be enjoying things again :)
>>>>>>
>>>>>> As a general rule - whenever we reach the part of our route where we
>>>>>> actually plan to handle a request we generally spawn an actor to do the
>>>>>> job. For me it's good that the Actor speaks in terms of messages and
>>>>>> failed
>>>>>> futures - and doesn't have to worry about 'Oh no I better not throw an
>>>>>> exception because I really need to return a HttpResponse of
>>>>>> INTERNAL_SERVER_ERROR'. This job can be done in your generic handlers :)
>>>>>>
>>>>>> On Monday, 3 April 2017 02:09:32 UTC+1, kraythe wrote:
>>>>>>>
>>>>>>> I was really excited about akka-http as I would be able to unburden
>>>>>>> my code from the baggage of play and handle my server side as a pure
>>>>>>> akka
>>>>>>> actors app but unless I am much mistaken something is dreadfully amiss
>>>>>>> with
>>>>>>> the implementation.
>>>>>>>
>>>>>>> One of the main core features is the actor paradigm and the
>>>>>>> integration of a rich actor system. However, the preferred approach to
>>>>>>> akka-http seems to be a throwback to one file programming. The main
>>>>>>> reason
>>>>>>> it seems this way is the DSL. Take this example from a tutorial:
>>>>>>>
>>>>>>> path("bank" / IntNumber) { id =>
>>>>>>> get {
>>>>>>> complete {
>>>>>>> getById(id).map{result =>
>>>>>>> if(result.isDefined)
>>>>>>> HttpResponse(entity =write(result.get))
>>>>>>> else
>>>>>>> HttpResponse(entity ="This bank does not exist")
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> }
>>>>>>> }
>>>>>>> }~
>>>>>>> path("bank" / "update") {
>>>>>>> post {
>>>>>>> entity(as[String]) { bankJson =>
>>>>>>> complete {
>>>>>>> val bank =parse(bankJson).extract[Bank]
>>>>>>> update(bank).map{result => HttpResponse(entity ="Bank
>>>>>>> has been updated successfully")}
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> Simple enough right? Too me I see the start of an anti-pattern but
>>>>>>> lets look further. It gets worse though, quickly, as shown in the
>>>>>>> akka-http documentation here
>>>>>>> <http://doc.akka.io/docs/akka-http/10.0.0/scala/http/routing-dsl/index.html#longer-example>.
>>>>>>>
>>>>>>> Still not bothered? The problem is that these examples are shallow and
>>>>>>> not
>>>>>>> rooted in the real world. In the bank application above would be
>>>>>>> hundreds
>>>>>>> of endpoints and each endpoint would have to validate data send by the
>>>>>>> user, check to see whether that data correct against the database and a
>>>>>>> dozen other things that would alter the nature of the return type to a
>>>>>>> bad
>>>>>>> request or internal error. The banking app would also have to log the
>>>>>>> problems so forensics can be done on malicious users. Just taking one
>>>>>>> route
>>>>>>> "deposit" would be several hundred lines of code INSIDE the route.
>>>>>>> However,
>>>>>>> it seems that there is no way to break off the route, offload it to
>>>>>>> another
>>>>>>> component (such as a Per Request Actor) and then continue the DSL where
>>>>>>> you
>>>>>>> left off. I had the chance to see for an app in another company that
>>>>>>> was
>>>>>>> asking my advice and their route is 12k lines long and at one point
>>>>>>> nested
>>>>>>> 30 levels deep.
>>>>>>>
>>>>>>> Now I know what you might say, "But Robert, you can break up the
>>>>>>> route into multiple files" which is true but something has to manually
>>>>>>> concatenate all of those routes together and they cant be done off of
>>>>>>> the
>>>>>>> main route. once you are in the routes DSL you are stuck there. Sure,
>>>>>>> you
>>>>>>> can call an actor with a future to do a completion but that actor
>>>>>>> itself
>>>>>>> might return data that requires a different kind of completion based
>>>>>>> upon
>>>>>>> certain criteria such as whether the user has had their account
>>>>>>> suspended.
>>>>>>> So if your completions are diverse, how do you break up the route?
>>>>>>>
>>>>>>> Now if someone has answers to these issues I would love to hear them
>>>>>>> but after researching I found that basically PRA's are deprecated in
>>>>>>> favor
>>>>>>> of a "convenient" DSL that entraps the user. For my purposes I opted to
>>>>>>> go
>>>>>>> with the low level API and factor off the route dispatching to a
>>>>>>> routing
>>>>>>> actor (yes, I know this is what the materializer does) and then just
>>>>>>> pull
>>>>>>> out route data the old fashioned way. My router, does path checking
>>>>>>> and
>>>>>>> then dispatches to another actor to handle that specific request and
>>>>>>> then
>>>>>>> sends the HttpResponse entity back to the sender which completes the
>>>>>>> ask
>>>>>>> and the route. My startup looks like this:
>>>>>>>
>>>>>>> val serverSource: Source[Http.IncomingConnection, Future[Http.
>>>>>>> ServerBinding]] =
>>>>>>> Http().bind(interface = "localhost", port = 8080)
>>>>>>> log.info("Server online at http://localhost:8080";)
>>>>>>> val bindingFuture: Future[Http.ServerBinding] =
>>>>>>> serverSource.to(Sink.foreach { connection => // foreach
>>>>>>> materializes the source
>>>>>>> import akka.pattern.ask
>>>>>>> println("Accepted new connection from " + connection.
>>>>>>> remoteAddress)
>>>>>>> connection.handleWithAsyncHandler(request => (httpRouter ?
>>>>>>> request).mapTo[HttpResponse], parallelism = 4)
>>>>>>> }).run()
>>>>>>>
>>>>>>>
>>>>>>> A snippet of the router looks like this.
>>>>>>>
>>>>>>> class HttpRequestRouter extends Actor {
>>>>>>> protected val log = Logging(context.system, this)
>>>>>>>
>>>>>>>
>>>>>>> override def receive: Receive = {
>>>>>>> case request: HttpRequest =>
>>>>>>> val requestId = UUID.randomUUID()
>>>>>>> request match {
>>>>>>> case HttpRequest(GET, Uri.Path("/"), _, _, _) =>
>>>>>>> notFound(requestId, request) // todo Implement this
>>>>>>> case HttpRequest(POST, Uri.Path("/hello"), _, _, _) =>
>>>>>>> invokeActor(classOf[HelloActor], requestId, request)
>>>>>>> case HttpRequest(GET, Uri.Path("/users"), _, _, _) =>
>>>>>>> invokeActor(classOf[ListUsersActor], requestId, request)
>>>>>>> case HttpRequest(GET, Uri.Path("/addUser"), _, _, _) =>
>>>>>>> invokeActor(classOf[AddUserActor], requestId, request)
>>>>>>> case uri =>
>>>>>>> notFound(requestId, request)
>>>>>>> }
>>>>>>> case msg => log.warning("Received unknown message: {}", msg)
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> private def invokeActor(actorType: Class[_], requestId: UUID,
>>>>>>> request: HttpRequest) = {
>>>>>>> context.actorOf(Props(actorType, sender(), requestId, request),
>>>>>>> requestId.toString)
>>>>>>> }}
>>>>>>>
>>>>>>> This allows me to fork off PRAs as needed but it kind of stinks in
>>>>>>> one way because there are a lot of tools in the DSL for unpacking
>>>>>>> entities
>>>>>>> and so on that I cant use, or rather if there is a way I and neither I
>>>>>>> nor
>>>>>>> anyone within the reach of google has figured it out.
>>>>>>>
>>>>>>> So what am I missing? Do people really love this monstrous DSL even
>>>>>>> though in a 100 endpoint system the thing will be gargantuan? Is there
>>>>>>> a
>>>>>>> means to fork off at any point in the DSL and then "reboot the stream"?
>>>>>>> It
>>>>>>> would be nice if some of the DSL tools could be invoked arbitrarily
>>>>>>> inside
>>>>>>> the PRAs on the request object like.
>>>>>>> class OrderPRA(replyTo: ActorRef, requestId: UUID, request:
>>>>>>> HttpRequest) {
>>>>>>>
>>>>>>> // ... code
>>>>>>> sender.tell(withRequest(request) {
>>>>>>> entity(as[Order]) { order =>
>>>>>>> complete {
>>>>>>> // ... write order to DB
>>>>>>> "Order received"
>>>>>>> }
>>>>>>> }
>>>>>>> }), self)
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> Opinions? Thoughts?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>> >>>>>>>>>> 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 [email protected].
>>>>> To post to this group, send email to [email protected].
>>>>> Visit this group at https://groups.google.com/group/akka-user.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>> --
>>> >>>>>>>>>> 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 [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> >>>>>>>>>> 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 [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Dominik Dorn
> http://dominikdorn.com
> http://twitter.com/domdorn
>
> Skripten, Mitschriften, Lernunterlagen, etc. findest Du auf
> http://www.studyguru.eu !
>
--
>>>>>>>>>> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
