[akka-user][deprecated] Akka HTTP client per-request timeouts
Simple question: How do you set akka.http.client.idle-timeout on a per-request basis? Thanks, -- Alan Burlison -- -- * ** New discussion forum: https://discuss.akka.io/ replacing akka-user google-group soon. ** This group will soon be put into read-only mode, and replaced by discuss.akka.io ** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced * 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user][deprecated] Akka HTTP for microservice orchestration?
On 13/04/18 12:28, Marc Schlegel wrote: Thanks for your confirmation. I thought that I read somewhere that Akka Http was only intended for internal communication within actor-systems and it should not be used directly...but obviously I was mistaken. I don't believe so, I've used it to implement a fully-blown REST endpoint for an application. -- Alan Burlison -- -- * ** New discussion forum: https://discuss.akka.io/ replacing akka-user google-group soon. ** This group will soon be put into read-only mode, and replaced by discuss.akka.io ** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced * 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user][deprecated] Akka HTTP for microservice orchestration?
On 13/04/18 11:16, Marc Schlegel wrote:
I would like to know if Akka Http is suitable to implement a small
orchestration layer.
The idea is to send events from the microservice to the orchestration layer
(Akka with Akka Http). I think Akka is a nice fit for orchestration but I
am not sure if Akka Http is the best solution to work with external systems.
Note: the events are implemented by Google Protocolbuffers because my
demo-projects implements the services in several languages (Go, Java, Rust)
and by using protobuf I can generate consistent DTOs. I've first looked
into Alpakka but it seems this has a different focus and currently no
official support for protobuf messages.
I've prototyped something that sounds a little similar to this and it
works well. I have a controller actor running on one node that maintains
a list of pending work. Worker actors are started on other nodes and
connect to the controller actor to request work which they then process.
The worker actors are just thin wrappers around instances of a large,
legacy C++ application which is in effect a batch process. The worker
nodes create a worker actor for each instance of the legacy app, plus
there is a shared localhost-only Akka HTTP server actor to provide a
protobuf endpoint for the C++ app instances on the worker node to talk
to. The C++ app has been modified to use libcurl & protobuf to connect
to the localhost HTTP server to request work details and provide
completion information which is 'proxied' back by the worker actors to
the controller actor on the controller node.
All the external communication is done with protobuf, both between the
akka actors on the master and worker nodes and between the worker actors
and the legacy C++ app, via the localhost HTTP actor. I've used akka
remoting for the cross-node control rather than akka cluster as if the
controller node dies there is nothing further that can be done anyway
and the worker actors just kill any running C++ app instances and exit.
Workers can be added dynamically and will be issued pending work and if
they die the controller will reschedule the work they were doing to
another worker.
This all works nicely and protobuf integrates well into Akka HTTP, with
the addition of a tiny amount of glue code to to the protobuf
marshalling for akka HTTP - see
https://github.com/scalapb/ScalaPB/issues/247 for the details. With that
in place, the routing logic for processing looks similar to this
outline, where JobFinishedMsg is a protobuf message:
path("job_finished") {
post {
entity(as[JobFinishedMsg])(msg => {
log.debug("received message {}", msg.id)
???
}
}
}
--
Alan Burlison
--
--
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user
google-group soon.
** This group will soon be put into read-only mode, and replaced by
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user][deprecated] Does it fit to CRDT ?
On 06/04/18 16:55, Patrik Nordwall wrote: Interesting question, could you move it to our new forum at https://discuss.akka.io/ Interesting to see people being pushed across onto the forum, bearing in mind that the earlier question that was asked about the functionality of Discourse's email support hasn't yet been answered... -- Alan Burlison -- -- * ** New discussion forum: https://discuss.akka.io/ replacing akka-user google-group soon. ** This group will soon be put into read-only mode, and replaced by discuss.akka.io ** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced * 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user][deprecated] Re: [akka-user] Announcing discuss.akka.io!
On 17/03/18 00:10, Justin du coeur wrote: As a result, I'm on the fence about getting involved with the new Akka and Play forums. I may go for it -- if the volume remains at the level of the mailing lists, it won't be too bad. But I'd be a lot less reluctant (possibly eager, even) if Discourse would fix the damned mailing list mode to respect the other settings. I'm surprised and disappointed that they haven't prioritized this... I think you don't have to look any further than Jeff Atwood's opinion of email and the people that use it to figure why it's still so broken despite all the requests over the years: https://blog.codinghorror.com/is-email-efail/ I don't know if they have fixed it, but it always used to be the case that you couldn't start new "topics" via email and you had to log in to the Discourse BUI in order to do so, so the email functionality was basically useless and you were forced to use the BUI. -- Alan Burlison -- -- * ** New discussion forum: https://discuss.akka.io/ replacing akka-user google-group soon. ** This group will soon be put into read-only mode, and replaced by discuss.akka.io ** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced * 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user][deprecated] Re: [akka-user] Announcing discuss.akka.io!
On 16/03/18 21:56, Patrik Nordwall wrote: You can setup email notifications as described in https://discuss.lightbend.com/t/how-to-use-the-discuss-forum-as-a-mailing-list/61 If I'm understanding the warning at the bottom of that page, you'll get emails for *all* categories in Discourse, not just Akka, is that correct? As I read it, the advice on that page is "Don't use the mailing list functionality" so I'm a bit surprised to see it being recommended here. -- Alan Burlison -- -- * ** New discussion forum: https://discuss.akka.io/ replacing akka-user google-group soon. ** This group will soon be put into read-only mode, and replaced by discuss.akka.io ** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced * 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user][deprecated] Re: [akka-user] Announcing discuss.akka.io!
On 16/03/18 11:17, Johan Andrén wrote: Sorry to hear that you dislike Discuss so much you won't be coming along there Alan. I've tried to use it and thereby over time come to like it, but it's vile and I won't use it unless I personally have a specific question that I need an answer for - I certainly won't be following the discussions the way I do on the email list. I've learned a lot about Akka by simply reading the email list traffic but I won't use Discuss for that - sorry. What we have found is that the lack of searching and categories and easy navigation on the mailing list made users, especially newcomers, ask the same questions over and over again. We in the core Akka team spend quite some time moderating and answering questions here and we want a tool where we (and others in the community ofc) can help as many users as possible with minimum effort. We think that the categories and tags etc. in discuss will help us do that. We also hope this will help reduce some of the noise in the Gitter channels. I think the 'unsearchable email archives' is a convenient myth and that newbies will ask the same questions over and over anyway, irrespective of where they ask them. As for categories and tags - that relies on people actually using them correctly, and you have no way of ensuring that the wider community does. I've been on your end of this situation myself and we provided forums but in general technical people hated them and wouldn't use them, so they died. And the Discuss developers have already said they think email lists are an abomination and won't improve Discuss's support for them so the half-hearted and useless support for them that's there is not going to get better either. It will probably reduce your workload but not for the reason you are hoping for - if the volume of interaction plummets then sure yes, your problem will have gone :-/ In addition to that we also see synergies in bringing the Lagom and Play communities closer, this may be a bigger gain for those projects as they are to some extent built on top of Akka but it also brings benefits to the Akka community in growing it, hopefully leading to more people being able to help out and answer questions, that may previously have been lurking in the other two project mailing lists only. I think you are going to be disappointed - if people don't contribute to email lists they are even less likely to do so for forums because it takes so much more time to use a clunky web UI to do so. I don't think this will change your mind, but felt that the picture you painted was a bit unfair and I wanted to clarify that this was a move driven by us engineers. It won't, and as I said I don't expect you'll change your collective decision either because you are way too far down the line to do so. However I think it's a huge misstep - I've seen no traffic on the mailing list demanding you close it down and replace it with Discuss (https://groups.google.com/forum/#!searchin/akka-user/discuss$20%7Csort:date - oh look, a searchable archive!) but you've done so anyway. The lack of discussion (pun intended) doesn't exactly send a positive message to your community. -- Alan Burlison -- -- * ** New discussion forum: https://discuss.akka.io/ replacing akka-user google-group soon. ** This group will soon be put into read-only mode, and replaced by discuss.akka.io ** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced * 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user][deprecated] Re: [akka-user] Announcing discuss.akka.io!
On 13/03/18 13:58, Konrad 'ktoso' Malawski wrote: We took this decision after much thought, debate and considering the various up and down sides of handling it very seriously. We know that a mailing list work-flow is very precious for people used to working with them (plenty of us including), however in order to grow the community as a whole, and also help making the discussions on such forum more searchable and accessible, we decided that this move will be beneficial for everyone involved. If you enjoy working with mailing-lists, and would like to continue to do so with the new forums, please have a look at the hints in the Discuss Meta <https://discuss.lightbend.com/c/meta> topics, where we prepared hints on how to set up the notifications to work as-if a mailing list <https://discuss.lightbend.com/t/how-to-use-the-discuss-forum-as-a-mailing-list/61> Which says: Warning about the “mailing list mode” While Discourse offers a so-called “mailing list mode” that you can enable in your email settings in your preferences this mode is “all in”, and will deliver you emails for all categories in this forum. If your tagging and filtering skills are good, you may indeed want to try the mailing list mode and set up filters in your email client fine tuned such as you would normally. If you find a setup that works well for you, please do share it so others may also benefit from your findings. Since this forum is shared between various tech, you most likely will find this style of interaction too noisy. We instead recommend tuning the notification settings, with combination of watching categories2 for an optimal user experience. In other words, despite what's said in the announcement there is no useable emailing mode in Discourse. This must be the 4th or 5th mailing list that I've been on that's been replaced by Discourse, and I've learned not to argue against it because switching to Discourse seems to accompanied by be some sort of religious conviction about how much better it is, which it is futile to argue against. What I will observe is that in the other cases I've seen the switch made the usefulness of the forum plummets because the people with experience and who provide much of the benefit simply don't make the transition to Discourse as it requires visiting yet another website and trawling through a clunky web interface to see if there's anything interesting and they simply don't have the time or patience to do that. As a result the conversation rapidly degenerates to really basic "How do I get X to work" questions that would be better off on Stack Overflow. Looking at the https://discuss.lightbend.com site it's clear that Lightbend have made a corporate-level decision to abandon mailing lists and switch to Discourse, presumably because the PHBs think Facebookising the interactions between Lightbend and their community looks prettier. That's a shame, as I certainly won't be using it. -- Alan Burlison -- -- * ** New discussion forum: https://discuss.akka.io/ replacing akka-user google-group soon. ** This group will soon be put into read-only mode, and replaced by discuss.akka.io ** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced * 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Getting the HTTP server's bound port seems to be impossible?
On 07/03/18 01:11, Konrad “ktoso” Malawski wrote:
The difference is in the binding call you can do, there’s a few styles, yet
each gives back a binding, which contains an address:
val bindingFuture = Http().bindAndHandle(routes, interface =
"0.0.0.0", port = 8080)
bindingFuture.foreach { binding ⇒
println(s"Server online at ${binding.localAddress}")
}
Ahah, that's what I was looking for, thanks - I wasn't clear how to go
from the value returned from bindAndHandle to the bind port - I'd
assumed doing something like the above would block on the future. Adding
that to the docs would be useful...
On a related note, I found a very helpful code snippet which shows how
to provide an Akka-HTTP marshaller to go from/to protobuf in the routing
DSL. As protobuf is commonly used with Akka it would be useful if the
code in the bug report could be added to the Akka docks as a marshalling
example.
https://github.com/scalapb/ScalaPB/issues/247
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
[akka-user] Getting the HTTP server's bound port seems to be impossible?
The Akka HTTP documentation [1] says: "The Http.ServerBinding also provides a way to get a hold of the actual local address of the bound socket, which is useful for example when binding to port zero (and thus letting the OS pick an available port)." The scenario is I'm using a localhost http service which needs to be on a system-assigned localhost port to communicate with subprocesses and I need to find out which port the server is bound to. Despite what the documentation says I can find no way of doing this before starting to accept incoming connections, and no way of doing it using the high-level routing DSL. [1] https://doc.akka.io/docs/akka-http/current/server-side/low-level-api.html#starting-and-stopping -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Artery remoting seems to be endian-dependent
On 01/03/18 10:56, Konrad “ktoso” Malawski wrote: Ping in one place is enough, reopened :-) Ta, first reply wasn't to the email I intended it to be ;-) -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Artery remoting seems to be endian-dependent
On 01/03/18 10:44, Konrad “ktoso” Malawski wrote: Thanks, I’ll close the one I had opened then Umm, no - there are two separate issues here, the alignment bug in the FlightRecorder (24639) AND the bug in Aeron (24636). Can you reopen 24636 please? -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Artery remoting seems to be endian-dependent
On 01/03/18 10:44, Konrad “ktoso” Malawski wrote: Thanks, I’ll close the one I had opened then Ok, sorry - I didn't realise you'd already opened one :-) -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Artery remoting seems to be endian-dependent
Submitted as https://github.com/akka/akka/issues/24639 -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Artery remoting seems to be endian-dependent
On 01/03/18 01:24, Konrad “ktoso” Malawski wrote: Thanks again, hope the TCP one will be fine for you for now in any case? Yes, in fact it's probably a better choice anyway as the message rate is low. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Artery remoting seems to be endian-dependent
On 01/03/18 01:37, Konrad “ktoso” Malawski wrote: Here’s the ticket: https://github.com/akka/akka/issues/24636 I did not find your github handle, please comment or sub the issue if you want to track it there. Done, thanks :-) -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Artery remoting seems to be endian-dependent
On 27/02/18 09:43, Konrad “ktoso” Malawski wrote: Thanks Alan, please do report back here or as a ticket on github.com/akka/akka :) Thanks for helping harden artery! OK, here's the story. With artery.transport = tcp, the app works, with it set to aeron-udp it doesn't. Even with debugging enabled, there is very little information output because the failure happens very early on: [INFO] [02/28/2018 18:18:20.218] [main] [akka.remote.artery.aeron.ArteryAeronUdpTransport(akka://Remoting)] Started embedded media driver in directory [/var/tmp/aeron-alanbur-Remoting-01f9e630-bc42-441c-a90b-ab0300afaa7c] [DEBUG] [02/28/2018 18:18:20.256] [Remoting-akka.actor.default-dispatcher-6] [akka://Remoting/system] now supervising Actor[akka://Remoting/system/StreamSupervisor-0#1924858877] [DEBUG] [02/28/2018 18:18:20.257] [Remoting-akka.remote.default-remote-dispatcher-7] [akka://Remoting/system/StreamSupervisor-0] started (akka.stream.impl.StreamSupervisor@4485c04a) [DEBUG] [02/28/2018 18:18:20.257] [Remoting-akka.actor.default-dispatcher-6] [akka://Remoting/system] now supervising Actor[akka://Remoting/system/StreamSupervisor-1#-1116171559] [DEBUG] [02/28/2018 18:18:20.257] [Remoting-akka.remote.default-remote-dispatcher-7] [akka://Remoting/system/StreamSupervisor-1] started (akka.stream.impl.StreamSupervisor@3bb60524) Failed to parse config file No response from MediaDriver within (ns):200 [DEBUG] [02/28/2018 18:18:40.357] [Remoting-akka.actor.default-dispatcher-3] [akka://Remoting/user] stopped Most likely cause is endian and/or alignment bugs in the code that accesses the shared memory segment between the Aeron client code and the Media Driver: https://github.com/real-logic/aeron/wiki/Media-Driver-Operation "The mediadriver and the API/stack communicate via a set of shared memory buffers." https://github.com/real-logic/aeron/wiki/Protocol-Specification "Byte ordering of fields of length 16-bits and larger use Little Endian. This is for pure efficiency on performance sensitive platforms." Looking at the Aeron source there are lots of mentions of endianness in there, but also things like this: // TODO: need to byte order to LITTLE_ENDIAN which suggests that the code isn't properly endian-independent yet. My suspicion therefore is that the bug is in Aeron rather than Artery, so I'd appreciate some guidance on how to progress the issue. Thanks, -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Artery remoting seems to be endian-dependent
On 27/02/18 09:43, Konrad “ktoso” Malawski wrote:
please do report back here or as a ticket on github.com/akka/akka :)
Thanks for helping harden artery!
OK, debugging has actually uncovered another bug in the flight recorder.
I enabled the debug options you suggested and some others that seemed
useful, including:
akka.remote.artery.advanced.flight-recorder.enabled = on
With that option set and Aeron UDP enabled, here's what happens:
--
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGBUS (0xa) at pc=0x7b978e30, pid=16182, tid=0x0002
#
# JRE version: Java(TM) SE Runtime Environment (8.0_141-b15) (build
1.8.0_141-b15)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.141-b15 mixed mode
solaris-sparc compressed oops)
# Problematic frame:
# V [libjvm.so+0xd78e30] Unsafe_SetLong+0x168
#
# Core dump written. Default location: /tmp/demo/core or core.16182
--
and:
--
siginfo: si_signo: 10 (SIGBUS), si_code: 1 (BUS_ADRALN), si_addr:
0x7db10004
Stack: [0x7f1f,0x7f2f], sp=0x7f2ee310,
free space=1016k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
V [libjvm.so+0xd78e30] Unsafe_SetLong+0x168
j sun.misc.Unsafe.putLong(Ljava/lang/Object;JJ)V+863513888
j sun.misc.Unsafe.putLong(Ljava/lang/Object;JJ)V+0
j org.agrona.concurrent.MappedResizeableBuffer.putLong(JJ)V+24
j akka.remote.artery.FlightRecorder.init()V+28
j
akka.remote.artery.FlightRecorder.(Ljava/nio/channels/FileChannel;)V+228
j
akka.remote.artery.ArteryTransport.initializeFlightRecorder()Lscala/Option;+72
j
akka.remote.artery.ArteryTransport.(Lakka/actor/ExtendedActorSystem;Lakka/remote/RemoteActorRefProvider;)V+35
j
akka.remote.artery.aeron.ArteryAeronUdpTransport.(Lakka/actor/ExtendedActorSystem;Lakka/remote/RemoteActorRefProvider;)V+3
j
akka.remote.RemoteActorRefProvider.init(Lakka/actor/ActorSystemImpl;)V+205
j akka.actor.ActorSystemImpl.liftedTree2$1()Lakka/actor/ActorSystemImpl;+15
j
akka.actor.ActorSystemImpl._start$lzycompute()Lakka/actor/ActorSystemImpl;+13
j akka.actor.ActorSystemImpl._start()Lakka/actor/ActorSystemImpl;+8
j akka.actor.ActorSystemImpl.start()Lakka/actor/ActorSystemImpl;+1
j
akka.actor.ActorSystem$.apply(Ljava/lang/String;Lakka/actor/setup/ActorSystemSetup;)Lakka/actor/ActorSystem;+88
j
akka.actor.ActorSystem$.apply(Ljava/lang/String;Lscala/Option;Lscala/Option;Lscala/Option;)Lakka/actor/ActorSystem;+34
j
akka.actor.ActorSystem$.apply(Ljava/lang/String;Lcom/typesafe/config/Config;)Lakka/actor/ActorSystem;+15
j com.oracle.labs.remoting.Main$.main([Ljava/lang/String;)V+244
j com.oracle.labs.remoting.Main.main([Ljava/lang/String;)V+4
v ~StubRoutines::call_stub
V [libjvm.so+0x743ae4] void
JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x744
V [libjvm.so+0x7dc94c] jni_CallStaticVoidMethod+0x7a8
C [libjli.so+0x7404] JavaMain+0x7e4
C [libc.so.1+0x1e1c58] _lwp_start+0x8
--
This is a straightforward alignment bug, the faulting address is 4-byte
aligned instead of 8-byte aligned. I believe the culprit is this, from
FlightRecorder.init():
--
private def init(): Unit = {
globalSection.putInt(0, MagicString)
globalSection.putLong(StartTimeStampOffset, System.currentTimeMillis())
}
--
so that's a 4-byte value followed immediately by an 8-byte value -
misaligned access - bang. The fix is either to add padding or to
increase MagicString to be a 64-bit value. However the same Int/Long
pattern occurs elsewhere in the code so it will all need fixing, and
that's going to need changes in the buffer format and result in a binary
incompatibility - perhaps requiring a change in the MagicString value?
I can log a bug for this, is https://github.com/akka/akka/issues the
right place?
I'll disable flight recorder and continue debugging the underlying
Artery issue, my current suspicion is it is related to the communication
mechanism used with the Aeron Media Driver.
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Artery remoting seems to be endian-dependent
On 27/02/18 06:32, Konrad “ktoso” Malawski wrote: I’d expect some failures to be logged if your guess is correct, nothing in the logs? There's a message about the connect to the other node timing out, but no other detail - hence the question :-) Thanks for reporting, it could be a bug somewhere. I'll try with the debug options you suggest and see if it sheds any more light - thanks for the pointers. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Artery remoting seems to be endian-dependent
I'm running an Akka remoting 'hello world' app using Artery remoting, it works fine on both Linux and Solaris x86 but doesn't work at all on Solaris SPARC, my best guess is that either Artery or Aeron contains some endian-dependent code. I'll log a bug but I'd like to confirm where the problem lies first - are there any HOWTOs of how to debug Artery? Thanks, -- Alan Burlison -- -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] allow-java-serialization = off breaks remoting
On 21/02/18 19:14, Patrik Nordwall wrote: Search for serialization-bindings in reference.conf, which you find here: https://doc.akka.io/docs/akka/current/general/configuration.html#listing-of-the-reference-configuration Thanks, that's very helpful - I had looked in there before but hadn't picked up that there are multiple serialization-bindings in there. Serailization of Props and its parameters are only needed for the remote deployment feature and that is something that we in general don't encourage (so much anymore). akka.actor.serialize-creators = on and akka.actor.serialize-messages = on are testing facilities that are a bit too blunt in practice, since there are typically many messages and Props that are only intended to be used locally and doesn't have to be serializable. Even though Akka actors have location transparency as one of its core traits you typically design your system with local and possibly remote actors in mind. Yes, that makes sense, thanks for the explanation. That said, if you anyway want to use these testing tools anyway you have to provide serializers for everything or mark things with NoSerializationVerificationNeeded. That's interesting I didn't realise you could tag things to exclude, thanks. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] allow-java-serialization = off breaks remoting
On 21/02/18 15:52, Konrad “ktoso” Malawski wrote:
You’re attempting to send a function.
remote ! Identify <<< Identify here is wrong
Note that it is a case class, that takes a parameter:
final case class Identify(messageId: Any)
remote ! Identify(“hello”)
should work just fine.
Ahah, my assessment of my stupidity was spot on, thanks ;-)
I had also tried:
remote ! Identify(remote)
but that didn't work either, following your hint:
remote ! Identity(remote.toSerializationFormat)
also works. Is there a list anywhere of what Akka/Scala types have
default protobuf serializers?
On a related note, I enabled "akka.actor.serialize-creators" but that
triggered:
[WARN] [SECURITY][02/21/2018 18:01:29.021] [main]
[DisabledJavaSerializer(akka://RITA)] Outgoing message attempted to use
Java Serialization even though `akka.actor.allow-java-serialization =
off` was set! Message type was: [class java.lang.Class]
which isn't exactly helpful in identifying the error. I suspect it's
cause by the companion object Props creator pattern that's recommended
in the docs, e.g.
object Controller {
def props = Props(new Controller)
}
If I use the
system.actorOf(Props(classOf[MyActor], arg1, arg2))
alternative I get a slightly different error:
[WARN] [SECURITY][02/21/2018 18:16:18.205] [main]
[DisabledJavaSerializer(akka://RITA)] Outgoing message attempted to use Java
Serialization even though `akka.actor.allow-java-serialization = off` was set!
Message type was: [class akka.actor.ActorSelection$$anon$1]
Doesn't this mean that "akka.actor.serialize-creators" is pretty much
useless in practice?
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
[akka-user] allow-java-serialization = off breaks remoting
I'm using protobuf serialization for my application messages and as recommended in the docs I also have "allow-java-serialization = false": https://doc.akka.io/docs/akka/2.5/serialization.html#enable-additional-bindings "A few types in Akka are, for backwards-compatibility reasons, still serialized by using Java serializer by default. You can switch them to using protocol buffers instead by adding the following bindings or set akka.actor.allow-java-serialization=off, which will make them serialized using protocol buffers instead." However if I do the following to get a remote ActorRef: -- val remote: ActorSelection ... : remote ! Identify -- I get the following fatal failure: [WARN] [SECURITY][02/21/2018 15:44:45.815] [RITA-akka.remote.default-remote-dispatcher-8] [DisabledJavaSerializer(akka://RITA)] Outgoing message attempted to use Java Serialization even though `akka.actor.allow-java-serialization = off` was set! Message type was: [class akka.actor.ActorSelection$$anon$1] [ERROR] [02/21/2018 15:44:45.818] [RITA-akka.remote.default-remote-dispatcher-8] [Encoder(akka://RITA)] Failed to serialize message [akka.actor.Identify]. (akka.serialization.DisabledJavaSerializer$JavaSerializationException: Attempted to serialize message using Java serialization while `akka.actor.allow-java-serialization` was disabled. Check WARNING logs for more details.) I'm clearly missing something obvious because what is documented simply isn't working for me, but I can't figure out what. Thanks, -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Futures, Promises and Actors
On 21/02/18 04:15, Konrad “ktoso” Malawski wrote: Hi Alan, the reason is basically that a Future represents some computation that is “running” (same as a Thread), so serializing it does not make much sense. (Yes, there’s trickery and magic we could do, but we avoid such magic tricks). Rather, use the `future pipeTo someActor` pattern to deal with futures and actors, as documened here: https://doc.akka.io/docs/akka/2.5/futures.html#use-with-actors OK, makes sense - thanks for the explanation :-) -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Futures, Promises and Actors
I was browsing through "Effective Akka" and I noticed the following somewhat cryptic warning: -- Warning Futures should never be passed between actors because you cannot serialize a thread. -- along with a bit above it about why Actor-to-Actor completion can't be signalled using a Promise/Future: "You cannot return a future value from a promise - they cannot be sent to an actor, which may or may not be remote." Why? Is this an implementation detail perhaps? Thanks, -- Alan Burlison -- -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: Akka Http how to add charset utf-8 to the content-type header
On 05/05/17 18:42, Alex Cozzi wrote:
funny, I was looking into this yesterday!
I am by no means an expert, but I think that what it is happening is the
following:
application/json implies UTF-8: if you look at the MediaType class from
akka http you se the declaration:
I believe you are correct, http://www.ietf.org/rfc/rfc4627.txt says:
3. Encoding
JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.
so an explicit MIME type isn't required if the content is UTF-8 - but
other JSON frameworks do often seem to include the UTF-8 charset.
As far as I know there's no "proper" way of forcing the addition of the
charset to the application/json content type in Akka-HTTP but it is
possible to hack around it:
val ct = ContentType(MediaType.custom("application/json",
false).asInstanceOf[MediaType.WithOpenCharset], HttpCharset.custom("utf-8"))
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] experiences with serialization: json vs protobuf vs avro vs kryo...
On 01/05/2017 17:15, Justin du coeur wrote: My general impression is that protobuf is the well-established route, and the one that most people are using I wrote a wrapper around Akka-Spray to save JSON in flat files. It is fairly primitive but has the (for my use case) big advantage that I can examine and manipulate the persisted Actor data using other tools, which is extremely useful during development. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Handling spray.json.DeserializationException in akka-http route
On 25/04/2017 19:16, Andras Szerdahelyi wrote: This looks excessively complex, given how the existing exception handling should ( in my opinion ) take care of this. I already had the customised JSON error response mechanism in place so the only new bit was converting the Spray exceptions into those. Plus I couldn't see any way of getting the name of the field that was being deserialised just using the Akka-HTTP exception handling mechanism. But yes, starting from scratch it is probably a bit daunting. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Handling spray.json.DeserializationException in akka-http route
On 25/04/2017 00:13, Andras Szerdahelyi wrote:
I have a need to encode exception messages in to a specific JSON format in
my http responses. I was wondering how I could catch a
DeserializationException in my route or outside of it or encode the
DeserializationException.
Here's how I did it so that it integrasted into my existing REST service
error handling:
Wrapped the deserialization operation in a try block:
def getParam[T: JsonReader](params: MMap[String, JsValue], key:
String, delete: Boolean = true): T = {
val value = params.get(key) match {
case Some(v) => try {
v.convertTo[T]
} catch {
case de: DeserializationException => throw
deserializationToRESTException(de, key)
}
case None => throw RESTException(ERR_MISSING_ARG(key))
}
if (delete) params -= key
value
}
val restErrorRE: Regex = """^Expected (\w+) as \w+, but got (.+)$""".r
def deserializationToRESTException(de: DeserializationException, key:
String) = {
val msg = de.msg match {
case restErrorRE(t, v) => s"expected $key to be $t but got $v"
case _ => s"invalid value for $key"
}
RESTException(ERR_INVALID_ARG(msg), de)
}
Then I wrapped all the individual deserialization calls in a try block:
try {
:
val name = getParam[String](fields, "name")
val uid = getParam[Int](fields, "uid")
:
} catch {
case re: RESTException => complete(re.toResponse)
final case class RESTException(error: RESTError, cause: Throwable =
null) extends Exception(error.toString, cause) {
def toResponse: HttpResponse = error.toResponse
}
final case class ERR_INVALID_ARG(det: String = null)
extends RESTErrorWithDetail(400, "invalid input argument", det)
RESTErrorWithDetail just maps the error code and message onto a normal
HttpResponse containing the HTTP status code and a JSON formatted error
message:
override def toResponse: HttpResponse = {
if (detail != null) {
HttpResponse(status = code, entity =
HttpEntity(MediaTypes.`application/json`,
"""{ "fault": { "code": %d, "name": %s, "message": %s }
}""".format(
code, name.toJson, s"$msg ($detail)".toJson)))
} else {
super.toResponse
}
}
That way the JSON deserialization errors are handled as normal
completions rather than using a specific Akka-HTTP exception handler.
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka 2.5.0 Released
> Eviction warnings will be inevitable, as Akka Http is still going to depend > on 2.4.x. However since 2.5.x is binary backwards compatible with 2.4.x, the > 2.5.0 can be used instead of 2.4.17. OK, thanks. > Also please update streams dependency to 2.5.0 so old version can be > evicted. That's what I was missing, without an explicit dependency on streams 2.5.0 I was getting the following error: Detected java.lang.NoSuchMethodError error, which MAY be caused by incompatible Akka versions on the classpath. Please note that a given Akka version MUST be the same across all modules of Akka that you are using, e.g. if you use akka-actor [2.5.0 (resolved from current classpath)] all other core Akka modules MUST be of the same version. External projects like Alpakka, Persistence plugins or Akka HTTP etc. have their own version numbers - please make sure you're using a compatible set of libraries. Uncaught error from thread [ZFSSA-akka.actor.default-dispatcher-7] shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for ActorSystem[ZFSSA] java.lang.NoSuchMethodError: akka.actor.ActorCell.addFunctionRef(Lscala/Function2;)Lakka/actor/FunctionRef; at akka.stream.stage.GraphStageLogic$StageActor.(GraphStage.scala:142) at akka.stream.stage.GraphStageLogic.getStageActor(GraphStage.scala:929) ... Thanks for your help :-) -- Alan Burlison -- -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka 2.5.0 thread pool changes
On 14/04/2017 10:13, Martynas Mickevičius wrote: JDK FJP changed spinning behaviour which changed performance characteristics for the case when there are lots of messages in flight. More info: https://github.com/akka/akka/pull/22560 Thanks. Has this been reported upstream to the JDK developers? The closest match I've been able to find is https://bugs.openjdk.java.net/browse/JDK-8141566 but I'm not certain it is the same issue. Are the benchmarks used in 22560 available from somewhere? Thanks, -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Akka 2.5.0 thread pool changes
I noticed this from the 2.5.0 release notes: - Fix performance regression for Scala 2.12, due to change in scheduling fairness of the JDK8 ForkJoinPool implementation Is there a bugid for this? What is the change in the JDK ForkJoinPool that caused the problem? Thanks, -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka 2.5.0 Released
On 13/04/17 11:41, Martynas Mickevičius wrote:
we—the Akka committers—are proud to be able to announce the availability of
Akka 2.5.0.
I've updated my dependencies to 2.5.0:
libraryDependencies ++= Seq(
"com.typesafe.akka" %% "akka-actor" % "2.5.0",
"com.typesafe.akka" %% "akka-persistence" % "2.5.0",
"com.typesafe.akka" %% "akka-persistence-tck" % "2.5.0" % "test",
"com.typesafe.akka" %% "akka-http" % "10.0.5",
"com.typesafe.akka" %% "akka-http-spray-json" % "10.0.5",
"io.spray" %% "spray-json" % "1.3.3"
)
But I'm getting build errors:
[warn] There may be incompatibilities among your library dependencies.
[warn] Here are some of the libraries that were evicted:
[warn] * com.typesafe.akka:akka-actor_2.12:2.4.17 -> 2.5.0
[warn] Run 'evicted' to see detailed eviction warnings
[info] Compiling 46 Scala sources to
/home/alanbur/blueline/sim/target/scala-2.12/classes...
[success] Total time: 20 s, completed 13-Apr-2017 22:23:35
evicted
[info] Updating {file:/home/alanbur/blueline/sim/}sim...
[info] Resolving jline#jline;2.14.1 ...
[info] Done updating.
[warn] There may be incompatibilities among your library dependencies.
[warn] Here are some of the libraries that were evicted:
[warn] * com.typesafe.akka:akka-actor_2.12:2.4.17 -> 2.5.0 (caller:
com.typesafe.akka:akka-parsing_2.12:10.0.5, default:sim_2.12:1.0,
com.typesafe.akka:akka-stream_2.12:2.4.17 (),
com.typesafe.akka:akka-persistence_2.12:2.5.0)
[info] Here are other libraries that were evicted:
[info] * com.typesafe:config:1.2.0 -> 1.3.1 (caller:
com.typesafe.akka:akka-actor_2.12:2.5.0,
com.typesafe:ssl-config-core_2.12:0.2.1)
I've not seen this before, how do I fix it?
Thanks,
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: Slowing down Akka HTTP responses
On 29/03/2017 16:38, Rafał Krzewski wrote:
How about something like:
complete {
Source.single(yourResponse).via(Flow.delay(delayDuration)).to(Sink.head).run()
}
I'm shooting from the hip here, you may need to use the type of your
response as parameter somewhere in the middle.
The idea is that Sink.head[T] materializes into a Future[T] so the response
will be completed asynchronously when delay duration elapses.
That's not an approach that occurred to me as I haven't played with
streams - thanks, I'll investigate.
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka HTTP/JSON: Rejecting requests with unknown fields
On 29/03/2017 12:13, Konrad Malawski wrote: In principle sure, though not on anyones roadmap nowadays. You could contribute such a thing or find a json parser whihc has such failure mode - I'm unaware of any parser which has such failure mode though. I can't think of any way of doing it that doesn't require reflection to enumerate the fields in the case class that the JSON is being unmarshalled in to. And although I've used Spray/JSON quite a bit I have no idea how the case class/tuple marshalling/unmarshalling stuff works. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka HTTP/JSON: Rejecting requests with unknown fields
On 28/03/2017 22:51, Konrad Malawski wrote: Your unmarshaller (you did not say what you're using), should be configured to blow up then. The default Akka/HTTP one, namely Spray/JSON. The spray-json one can not do that. That's unfortunate :-( Is it possible in principle to extend it to reject unrecognised fields, or is it a case of having to switch to a different framework? I'm also using Spray/JSON to implement Akka persistence and I don't want to have 2 JSOn frameworks in the same app, so switching to another JSON framework would not be trivial. Thanks, -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Akka HTTP/JSON: Rejecting requests with unknown fields
I'm using Akka's HTTP/JSON support to unmarshall JSON to case clasess using the standard "entity" and "as" mechanism. It works fine but if I supply JSON fields that don't have any corresponding case class fields they are silently ignored whereas I need the request to be rejected. I can't find any obvious way of doing this, is there one? Thanks, -- Alan Burlison -- -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Slowing down Akka HTTP responses
I'm working on a simulation using Akka HTTP where the HTTP responses from the real system can have significant delays that I need to replicate. Doing this the simple way by blocking on a sleep would obviously not be a good choice so I'm wondering on how to do this? One idea is to use the Akka Scheduler (http://doc.akka.io/docs/akka/current/scala/scheduler.html) to send a message back to the HTTP actor after a delay containing the response to send back to the client, but I'm wondering if there's a smarter way to do this? Thanks, -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: Akka HTTP path matching fundamentally broken? Surely not?
On 20 March 2017 at 15:57, 'Johannes Rudolph' via Akka User List wrote: > The only place where it would matter is if you complete a route from a place > where not the whole path is expected to be matched, i.e. there's still > something left in `ctx.unmatchedPath`. Is that what you are doing? Yes, you are correct, I've played around with it some more and it's only an issue if there is a trailing end to the path that includes the last matched segment as a prefix and you don't add a pathEndOrSingleSlash. However I think there is still the confusing "foofoo/bar" case that I mentioned in another mail when matched against "foo" and "bar". The "seg" PathMatcher conditional I posted earlier seems to work fine and is "fail fast" which makes dealing with deep hierarchies a bit easier, and possibly faster in the error case although I haven't tested that. I think it would be a simple addition to make to the PathMatcher DSL but that's not my call :-) -- Alan Burlison -- -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: Akka HTTP path matching fundamentally broken? Surely not?
> I don't think a directive is the right way to do this, it needs to be
> added to the existing PathMatcher DSL so it can be used with the path
> and pathPrefix directives, and I'm not sure of how to do that.
This seems to work:
def seg(segment: String) =
new PathMatcher[Unit] {
def apply(path: Path) = if (path.head == segment)
Matched(path.tail, ()) else Unmatched
}
Then you can say:
pathPrefix(seg("someseg"))
If that gets a nod of approval from the Akka HTTP folks I'll figure
out to log a RFE.
--
Alan Burlison
--
--
>>>>>>>>>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: Akka HTTP path matching fundamentally broken? Surely not?
On 18 March 2017 at 01:16, Daniel Stoner wrote: > I guess you have to remember that Akka-HTTP originates from Spray - and so > those choices were likely already made. (I'm sure there is a fully plausible > performance threading reason that is beyond me too hehe). Yes, I suspect it is too late to change the behaviour, no matter how odd it seems to be - although I haven't seen any comment from the Akka HTTP people yet. > Implementing a custom directive is easy! I don't think a directive is the right way to do this, it needs to be added to the existing PathMatcher DSL so it can be used with the path and pathPrefix directives, and I'm not sure of how to do that. -- Alan Burlison -- -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: Akka HTTP path matching fundamentally broken? Surely not?
On 17/03/2017 21:25, Daniel Stoner wrote:
What I wanted to do - was nest paths inside of each other thinking:
path("v1") {
path("orders") {whatever}
path("customers") {whatever}
}
Yes, exactly so.
In practice it appears that it works more as though each nested path does
not operate on the remaining unmatched path - but actually the whole url.
In a sense the above code is saying match paths that both look like: START
- /v1/ - END AND START - /orders/ - END. Obviously an impossible situation.
I believe that's why you need to use "~" or concat, so the alternatives
are tried in order.
So what we do is simply enumerate the paths we want to match for (rather
than nest them) and use PathMatcher DSL to enable us to avoid any real
overhead to the code for this. In the end it's just as readable (If not a
little bit more so since your enumerating explicitly your matching
possibilities rather than nesting them).
The problem is I have hundreds of paths to match, listing each
individual path in full in a linear fashion is just unworkable, I need
to use a tree.
One practices we found that worked - do the splitting by HTTP method
(GET/POST/PUT) down at the lowest level. Often you have a URL like
/v1/orders that accepts GET, PUT and POST and then you can nest all 3
options under one path matcher.
Yes, that's what I've done.
I really believe the current behaviour is the wrong choice, although
I've found hints in the documentation that it is deliberate - I have no
idea why it was considered to be a good design, if indeed it was.
I'm trying to figure out how to write my own implementation of
Segment("foo") to allow complete matching of a path segment, but it's
not easy as the DSL implementation is pretty "dense" code.
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: Akka HTTP path matching fundamentally broken? Surely not?
> I actually think it might be a bug - I'm in the middle of trying to figure
> out exactly where
PathMatcher.scala, line 145:
def apply[L: Tuple](prefix: Path, extractions: L): PathMatcher[L] =
if (prefix.isEmpty) provide(extractions)
else new PathMatcher[L] {
def apply(path: Path) =
if (path startsWith prefix) Matched(path dropChars
prefix.charCount, extractions)(ev)
else Unmatched
}
I believe "startsWith" should be "==", otherwise it is matching the
prefix of a segment which is in turn the prefix of a path, not a
segment which is a prefix of the path.
>From looking at the examples of how the pathPrefix directive is used,
it commonly takes a series of path matchers with "/" separators, where
segments that need to be matched with no extractions or conditionals
are represented by strings. However strings currently do *not* match
entire path segments, they match *prefixes* of path segments and there
appears to be no way to do exact matching of fixed path segments other
than the regexp hack I outlined in my previous email. You could I
suppose say that the current behaviour is as intended, in which case
I'd suggest it is surprising and unintuitive - if I put a literal
"foo" I expect it to match "foo" and not "foobar". It's even more
surprising because there is a mechanism (REs) that's explicitly for
matching "foobar", "foobaz" and extracting the variable part of the
segment, which you'd almost certainly want to do anyway for subsequent
routing logic.
If I have a match against "foo" followed by a slash, followed by "bar"
and I provide it with a path of "foofoo/bar" and try and synthesise a
useful error message from the failure with extractUnmatchedPath I get
a string "foo/bar", which is confusingly close to the real path of
"/foo/bar". I can imagine the WTF? complaints from users that will
cause...
Even if this *is* working as intended and won't be fixed (which I
personally believe would be a bad choice), would it be possible to add
a matcher DSL item that specifically matched a complete path segment?
There's already 'Segment', could that be extended to take a segment to
fully match against, e.g. 'Segment("foo")' ?
--
Alan Burlison
--
--
>>>>>>>>>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: Akka HTTP path matching fundamentally broken? Surely not?
On 17/03/2017 12:12, Akka Team wrote: Did you read the docs about the various path directives and how they differ? http://doc.akka.io/docs/akka-http/10.0.4/scala/http/routing-dsl/directives/path-directives/index.html Yes, over and over, because as I said I was sure I must be missing something. I actually think it might be a bug - I'm in the middle of trying to figure out exactly where but it looks like the URI handling under the DSL splits the URI into segments and then matches the routing directives against it in turn. In the case of a string it looks like it is comparing the string to the path segment with startsWith instead of equals, so it is checking if string is a _prefix_ of the next segment rather than the _entirety_ of the next path segment. If someone wanted to match the next segment against a string prefix then they could use a RE, e.g. "foo(.*)".r would match "foobar", "foobaz" etc and extract "bar" and "baz". Currently a string of "foo" will *also* match "foobar", "foobaz" but won't extract the "bar" or "baz" suffix, which seems almost certainly not what you'd want. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: Akka HTTP path matching fundamentally broken? Surely not?
pathPrefix("root") {
I can bodge around this with:
pathPrefix("^root$".r)
but that's unspeakably vile.
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
[akka-user] Akka HTTP path matching fundamentally broken? Surely not?
I'm sure I must be missing something here because I can't believe path
matching in Akka HTTP could be broken in the way it seems to be, because
it would be unusable for anything other than toy applications if it was:
I'm composing route handing from a top-level handler and sub-handlers
like this:
pathPrefix("root") {
concat(
pathPrefix("service1") { service1.route },
pathPrefix("service2") { service2.route }
)
}
where service1.route etc returns the sub-route for the associated
sub-tree. That works fine with a path of say "/root/service1", but it
*also* matches "/rootnotroot/service1", because pathPrefix() just
matches any arbitrary string prefix and not a full path segment. And if
I use path() instead of pathPrefix() it tries to match the entire
remaining path. What I'm looking for is something along the lines of
segment() where that fully matches just the next path segment and leaves
the remaining path to be matched by inner routes, but there doesn't seem
to be such a thing.
What am I missing?
Thanks,
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: AKKA HTTP: Is this a valid use of Route.seal?
On 15/03/2017 16:26, 'Johannes Rudolph' via Akka User List wrote: yes, that's a valid use case. The route tree is usually traversed completely until a Route matches. But if you know that the search can be cut short, then `seal` is definitely a good solution. That's exactly the case here - once the request authentication has succeeded (multiple forms are provided) then there's no point backtracking into it as any subsequent errors are path, parameter, data etc problems. Another solution would be to use only `handleRejections` which would have the advantage that only rejections are handled and exceptions will still bubble up and run through the exception handlers you have defined further up in your route. I started by using an implicit rejection handler but had to switch to an explicit handleRejections directive for some reason I don't understand. I moved the implicit handler into a base class of the classes that are providing the route segments and since then it's not being picked up, even though the docs for implicit resolution say that base classes are in the search path. I haven't figured out what the problem is, but as an explicit handler is clearer anyway, I'm tempted to just move on. I'm writing an emulation of multiple instances of an existing REST service, for testing purposes. It's rather neat to see 1000 Akka-based REST services running inside a single JVM :-) At the moment it's just at the "hello world" stage so memory & CPU will increase but I have no reason to believe I won't be able to support many hundreds of emulated services from a single JVM, and there's Akka clustering for beyond that. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: AKKA HTTP: Is this a valid use of Route.seal?
Anyone have any suggestions? Thanks!
On 07/03/17 22:32, Alan Burlison wrote:
I have an Akka HTTP route for a REST API that first checks the base path,
then checks the user authentication is valid, adds some custom headers and
extracts the base URI before processing the sub-routes. However if the URL
doesn't match any of the sub-routes, request processing "rolls back" to the
authentication step and I get an incorrect message about authentication
failing.
I've wrapped the sub-route processing in Route.seal and that
means that I now get a "Not Found" for nonexistent paths, as
required. However the documentation says that Route.seal shouldn't
really be needed for application code. Is this a valid use of
Route.seal, or is there a better way to prevent route processing from
"rolling back" past a specified point?
def route: Route = {
pathPrefix("rest" / "v1") {
// If the request authenticates successfully, add the custom headers to the
response
// and extract the base URI we were called with.
(combinedAuth & respondWithHeaders(versionHeaders) & baseUri ) { (sess,
baseUri) => {
// Process valid sub-routes, seal the route so we don't roll back past
this point.
Route.seal(concat(
pathEndOrSingleSlash { topRoute(sess, baseUri) },
pathPrefix("users") { userRoute(sess, baseUri) }
))}
}
}
}
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] PersistentActor and BackoffSupervisor problen
On 08/03/17 15:07, Akka Team wrote: What it says is, do not use this factory method for persistent actors but instead the Backoff.onStop factory method, not that the back off supervisor cannot be used with persistent actors. Ahah, that makes sense - thanks for the clarification. Perhaps the docs (I mean http://doc.akka.io/docs/akka/current/scala/persistence.html rather than the scaladocs) could be tweaked slightly to make the distinction clear? -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] PersistentActor and BackoffSupervisor problen
On 08/03/17 14:45, Richard Rodseth wrote: I think they are referring to child actors. i.e. it's OK for actor A to have a backoff supervisor (A can be persistent or not), but if it has a child which is a persistent actor then the caveats apply. Hmm, perhaps - but it doesn't read that way to me. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] PersistentActor and BackoffSupervisor problen
On 08/03/17 14:03, Alan Burlison wrote: That's not in the docs, it's just a source code comment - I'd have thought it was important enough a restriction to be in the scaladocs? Also, if BackoffSupervisor shouldn't be used with PersistentActors, what is the correct way of dealing with IO failures in persistent actors? Plus it directly contradicts this: http://doc.akka.io/docs/akka/current/scala/persistence.html#Failures "It is better to stop the actor and after a back-off timeout start it again. The akka.pattern.BackoffSupervisor actor is provided to support such restarts." ??? -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] PersistentActor and BackoffSupervisor problen
I have a number of persistent actors that write to disk files that may potentially be NFS files, so IO failure are possible. I was going to wrap the PersistentActors in BackoffSupervisors to deal with any IO errors, but I noticed this in the BackoffSupervisor source: * '''*** * This supervisor should not be used with `Akka Persistence` child actors. * `Akka Persistence` actors shutdown unconditionally on `persistFailure()`s rather * than throw an exception on a failure like normal actors. * [[#onStop]] should be used instead for cases where the child actor * terminates itself as a failure signal instead of the normal behavior of throwing an exception. * ***''' That's not in the docs, it's just a source code comment - I'd have thought it was important anough a restriction to be in the scaladocs? Also, if BackoffSupervisor shouldn't be used with PersistentActors, what is the correct way of dealing with IO failures in persistent actors? -- Alan Burlison -- -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] AKKA HTTP: Is this a valid use of Route.seal?
I have an Akka HTTP route for a REST API that first checks the base path,
then checks the user authentication is valid, adds some custom headers and
extracts the base URI before processing the sub-routes. However if the URL
doesn't match any of the sub-routes, request processing "rolls back" to the
authentication step and I get an incorrect message about authentication
failing.
I've wrapped the sub-route processing in Route.seal and that means that
I now get a "Not Found"
for nonexistent paths,
as required
. However the documentation says that Route.seal
shouldn't really be needed for application code. Is this a valid use of
Route.seal, or is there a better way to prevent route processing from
"rolling back" past a specified point?
def route: Route = {
pathPrefix("rest" / "v1") {
// If the request authenticates successfully, add the custom headers to
the response
// and extract the base URI we were called with.
(combinedAuth & respondWithHeaders(versionHeaders) & baseUri ) { (sess,
baseUri) => {
// Process valid sub-routes, seal the route so we don't roll back past
this point.
Route.seal(concat(
pathEndOrSingleSlash { topRoute(sess, baseUri) },
pathPrefix("users") { userRoute(sess, baseUri) }
))}
}
}
}
--
Alan Burlison
--
--
>>>>>>>>>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] newbie question about await inside actors code
On 21/02/2017 13:11, Justin du coeur wrote: Yeah, understood. It's useful to keep in mind that Akka *is* a moderately low-level toolkit; most of us who use it heavily are clear on that. The great thing about Akka is that it doesn't lie to you about where the hard problems are (as opposed to many frameworks that basically brush things under the rug), but it means you do have to wrestle with them. Exactly so, I'd much rather have things that way around than be trapped inside a framework from which there was no escape when it didn't meet your requirements in a particular area. And as you say, there are layers on top of Akka which add higher-level functionality if you need it. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] newbie question about await inside actors code
On 21/02/2017 12:57, Justin du coeur wrote: As I understand it, you want your parent to "wait" until it has collected all the info from the children before it moves on to doing something else. (Forgive me if I'm misunderstanding your use case -- it isn't spelled out in great detail above.) It's not my use case or indeed my problem, I was just trying to follow along with the discussion from the original post and understand the advice that was being given in response to it :-) The Akka-idiomatic way to do this is for the parent to do something like: -- Send out the jobs to the children -- become() into a different receive processor -- In this new processor, everything *other* than the responses from the children get stash()ed -- that is, you save them away for later -- Once you have accumulated all of the child responses (or timed out -- it is often adviseable to have a timeout scheduled), send out the aggregated response. Then unstash() everything that's been stored up, and become() back to your original state. Essentially, instead of waiting/blocking, you shunt everything else aside (queueing it, essentially) until you're ready to handle it. The effect is largely the same, but without tying up threads. Ooh, that's neat - I like that. Is there a collection/book of such approaches anywhere? I've looked at a couple of books on Safari but I don't recollect seeing that one explained anywhere - although I may have just missed it. I really like the "toolbox" approach of Akka but it can be a bit daunting to be given a box of spanners and then be expected to go build a car ;-) -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] newbie question about await inside actors code
On 21/02/2017 12:20, Viktor Klang wrote: Perhaps it was implicit but I assumed that the question was how to not process any new information until the response had been received, otherwise you're just use pipeTo and be done with it? Ah, got you - thanks for the clarification. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] newbie question about await inside actors code
On 20/02/2017 21:27, Rafał Krzewski wrote: As far as I know, the only situation when blocking in actor code is justifiable is interacting with legacy code that just blocks the calling thread and offers no way around it, like JDBC does. Of course one should use a dedicated dispatcher then, to avoid starving regular actors of resources. I have a related design question. I've written a Persistence Journal implementation that stores JSON in flat files, one file per persistent actor. Each journal file is managed by a dedicated actor which performs the actual file IO. The AsyncWriteJournal actor's asyncWriteMessages method returns a Future[immutable.Seq[Try[Unit]]] where the Future denotes the success/failure of the IO operations. I've implemented that by performing the JSON serialization of each message in the AsyncWriteJournal actor and then passing the resulting JSON to the per-file IO actor, building up a list of the futures for each write operation. I then use Future.sequence to transform the list of individual IO futures into a single future to return from asyncWriteMessages. All the IO actors share a dedicated dispatcher. Is that the best approach? I could possibly avoid the need for separate IO actors and issue the IOs from the asyncWriteMessages method - but then I assume it would block. What isn't clear to me is what happens to the Future returned by AsyncWriteJournal.asyncWriteMessages, is it waited for by the AsyncWriteJournal implementation or is it the PersistentActor that issues the original persistence operation that waits? As far as I can tell there's only one AsyncWriteJournal actor per actor system so I'm assuming that avoiding blocking in it is important, particularly if the Future that your AsyncWriteJournal implementation returns from asyncWriteMessages is for a blocking operation. I did also wonder about delegating the JSON serialization to a separate actor rather than doing it in the AsyncWriteJournal actor (I'm using spray for the serialization) and then using pipeTo to pass the JSON to the IO actor , but the performance I'm getting from the Persistence TCK benchmark is more than adequate for my needs - ~62k records/second, so I didn't bother, plus I noticed that other existing Persistent Journal implementations do serialization in the same way. Thanks, -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] newbie question about await inside actors code
On 21/02/2017 12:12, Viktor Klang wrote: http://doc.akka.io/docs/akka/2.4/scala/actors.html#Stash Ahah! I'd seen stash in the docs and not really come up with an case (other than become/become) where it would be useful, and then forgotten about it. I'm still not clear how it would help in this scenario though? Thanks, -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] newbie question about await inside actors code
On 20/02/2017 21:27, Rafał Krzewski wrote: Why use await, when pipeTo pattern provides clean, non-blocking integration between Futures and Actors? As far as I know, the only situation when blocking in actor code is justifiable is interacting with legacy code that just blocks the calling thread and offers no way around it, like JDBC does. Of course one should use a dedicated dispatcher then, to avoid starving regular actors of resources. I used it at one point when I was reading a numeric value from an actor that I then used in a calculation before passing the value back to the source actor in a subsequent message. I got rid of the need to use await by just pushing the calculation down into the actor. The takeway I got from that was that if you find yourself using await you probably need to think again about your design. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] newbie question about await inside actors code
On 20/02/2017 12:01, Viktor Klang wrote: No. I'd recommend to use stashing, makes the cost explicit. Could you expand on what you mean by "stashing"? -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] newbie question about await inside actors code
> This is not a solution because it creates one new thread for every blocker. In general I agree, but if the code has already aggregated all the futures into a single one, as seems to be suggested in an earlier email, wouldn't it be an option - albeit not an ideal one? -- Alan Burlison -- -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] newbie question about await inside actors code
On 20 February 2017 at 07:24, Roland Kuhn wrote:
> There are two solutions: the pipeTo pattern, or not using Futures at all and
> collecting the responses within a dedicated ephemeral actor.
What about the "blocking { ... }" construct?
http://www.cakesolutions.net/teamblogs/demystifying-the-blocking-construct-in-scala-futures
Probably best avoided if at all possible, though.
--
Alan Burlison
--
--
>>>>>>>>>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
[akka-user] Akka persistence plugin performance
I've put together a persistence plugin that uses spray-json and flat files, the motivation being that I'm writing a simulation and using JSON flat files it makes it easy to post-process the persistence logs. I've used the simple TCK JournalPerfSpec benchmark class and discarded the first 25% of the results to allow for warmup. The numbers I'm getting are: PersistAsync - ~62k records/second Persist - ~25k records/second Recover - ~73k records/second That's more than adequate for my needs but I'm wondering how that stacks up against other persistence options - the HW I'm using is nothing special, 2Ghz i5 laptop, laptop HDD for storage. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] ANNOUNCE: Akka 2.4.17 Security Patch Released
On 11/02/2017 19:43, Konrad Malawski wrote: If sbt runs fine I'd say the dependencies are good, perhaps your IDEA setup did not refresh the dependencies correctly? That's what it looks like, what's odd is it pulled the rest of the dependencies down correctly. Ah well, probably difficult to replicate... -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] ANNOUNCE: Akka 2.4.17 Security Patch Released
On 11/02/17 19:26, Konrad Malawski wrote:
This is very weird. We'll investigate.
I got the failure using using IDEA, if I run by hand it seems to work:
> clean
[success] Total time: 0 s, completed 11-Feb-2017 19:38:09
> compile
[info] Updating {file:/home/alanbur/blueline/persistence/}persistence...
[info] Resolving jline#jline;2.14.1 ...
[info] downloading
https://repo1.maven.org/maven2/com/typesafe/akka/akka-stream_2.12/2.4.16/akka-stream_2.12-2.4.16.jar
...
[info] [SUCCESSFUL ]
com.typesafe.akka#akka-stream_2.12;2.4.16!akka-stream_2.12.jar (1214ms)
[info] Done updating.
[info] Compiling 10 Scala sources to
/home/alanbur/blueline/persistence/target/scala-2.12/classes...
[warn] there was one deprecation warning (since 2.11.0); re-run with
-deprecation for details
[warn] one warning found
[success] Total time: 15 s, completed 11-Feb-2017 19:38:32
And if I rerun again in IDEA then the error is gone and the application
runs fine, so it seems like there was a problem with the akka-stream
dependency
Most odd.
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] ANNOUNCE: Akka 2.4.17 Security Patch Released
On 11/02/17 18:40, Konrad Malawski wrote: Could you post your dependencies? Build.sbt file or the dependency graph would be good. libraryDependencies ++= Seq( "com.typesafe.akka" %% "akka-actor" % "2.4.17", "com.typesafe.akka" %% "akka-persistence" % "2.4.17", "com.typesafe.akka" %% "akka-http" % "10.0.3", "io.spray" %% "spray-json" % "1.3.3", "org.iq80.leveldb" % "leveldb" % "0.7", "org.fusesource.leveldbjni" % "leveldbjni-all" % "1.8", "com.typesafe.akka" %% "akka-persistence-tck" % "2.4.17" % "test" ) I don't know how to get the dependency graph, if it's needed let me know what to do. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] ANNOUNCE: Akka 2.4.17 Security Patch Released
On 10/02/17 16:47, Patrik Nordwall wrote:
This is to announce the immediate availability of a security patch release,
addressing a potential security issue with Java deserialization. An
attacker that can connect to an ActorSystem exposed via Akka Remote over
TCP can gain remote code execution capabilities in the context of the JVM
process that runs the ActorSystem if:
I've upgraded to 2.4.17 but I now get a startup error from Akka-http:
Exception in thread "main"
com.typesafe.config.ConfigException$UnresolvedSubstitution:
reference.conf @
jar:file:/home/alanbur/blueline/repo/cache/com.typesafe.akka/akka-http_2.12/jars/akka-http_2.12-10.0.3.jar!/reference.conf:
42: Could not resolve substitution to a value:
${akka.stream.blocking-io-dispatcher}
at
com.typesafe.config.impl.ConfigReference.resolveSubstitutions(ConfigReference.java:108)
at
com.typesafe.config.impl.ResolveContext.realResolve(ResolveContext.java:179)
at
com.typesafe.config.impl.ResolveContext.resolve(ResolveContext.java:142)
at
com.typesafe.config.impl.SimpleConfigObject$ResolveModifier.modifyChildMayThrow(SimpleConfigObject.java:379)
at
com.typesafe.config.impl.SimpleConfigObject.modifyMayThrow(SimpleConfigObject.java:312)
at
com.typesafe.config.impl.SimpleConfigObject.resolveSubstitutions(SimpleConfigObject.java:398)
at
com.typesafe.config.impl.ResolveContext.realResolve(ResolveContext.java:179)
at
com.typesafe.config.impl.ResolveContext.resolve(ResolveContext.java:142)
at
com.typesafe.config.impl.SimpleConfigObject$ResolveModifier.modifyChildMayThrow(SimpleConfigObject.java:379)
at
com.typesafe.config.impl.SimpleConfigObject.modifyMayThrow(SimpleConfigObject.java:312)
at
com.typesafe.config.impl.SimpleConfigObject.resolveSubstitutions(SimpleConfigObject.java:398)
at
com.typesafe.config.impl.ResolveContext.realResolve(ResolveContext.java:179)
at
com.typesafe.config.impl.ResolveContext.resolve(ResolveContext.java:142)
at
com.typesafe.config.impl.SimpleConfigObject$ResolveModifier.modifyChildMayThrow(SimpleConfigObject.java:379)
at
com.typesafe.config.impl.SimpleConfigObject.modifyMayThrow(SimpleConfigObject.java:312)
at
com.typesafe.config.impl.SimpleConfigObject.resolveSubstitutions(SimpleConfigObject.java:398)
at
com.typesafe.config.impl.ResolveContext.realResolve(ResolveContext.java:179)
at
com.typesafe.config.impl.ResolveContext.resolve(ResolveContext.java:142)
at
com.typesafe.config.impl.SimpleConfigObject$ResolveModifier.modifyChildMayThrow(SimpleConfigObject.java:379)
at
com.typesafe.config.impl.SimpleConfigObject.modifyMayThrow(SimpleConfigObject.java:312)
at
com.typesafe.config.impl.SimpleConfigObject.resolveSubstitutions(SimpleConfigObject.java:398)
at
com.typesafe.config.impl.ResolveContext.realResolve(ResolveContext.java:179)
at
com.typesafe.config.impl.ResolveContext.resolve(ResolveContext.java:142)
at
com.typesafe.config.impl.ResolveContext.resolve(ResolveContext.java:231)
at
com.typesafe.config.impl.SimpleConfig.resolveWith(SimpleConfig.java:74)
at com.typesafe.config.impl.SimpleConfig.resolve(SimpleConfig.java:64)
at com.typesafe.config.impl.SimpleConfig.resolve(SimpleConfig.java:59)
at com.typesafe.config.impl.SimpleConfig.resolve(SimpleConfig.java:37)
at com.typesafe.config.impl.ConfigImpl$1.call(ConfigImpl.java:374)
at com.typesafe.config.impl.ConfigImpl$1.call(ConfigImpl.java:367)
at
com.typesafe.config.impl.ConfigImpl$LoaderCache.getOrElseUpdate(ConfigImpl.java:65)
at
com.typesafe.config.impl.ConfigImpl.computeCachedConfig(ConfigImpl.java:92)
at
com.typesafe.config.impl.ConfigImpl.defaultReference(ConfigImpl.java:367)
at
com.typesafe.config.ConfigFactory.defaultReference(ConfigFactory.java:413)
at com.typesafe.config.ConfigFactory.load(ConfigFactory.java:212)
at com.typesafe.config.ConfigFactory.load(ConfigFactory.java:181)
at com.typesafe.config.ConfigFactory$1.call(ConfigFactory.java:305)
at com.typesafe.config.ConfigFactory$1.call(ConfigFactory.java:302)
at
com.typesafe.config.impl.ConfigImpl$LoaderCache.getOrElseUpdate(ConfigImpl.java:65)
at
com.typesafe.config.impl.ConfigImpl.computeCachedConfig(ConfigImpl.java:92)
at com.typesafe.config.ConfigFactory.load(ConfigFactory.java:302)
at akka.actor.ActorSystem$.$anonfun$apply$4(ActorSystem.scala:242)
at scala.Option.getOrElse(Option.scala:121)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:242)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:288)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:233)
--
Alan Burlison
--
--
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 un
Re: [akka-user] Class cast exceptions in actors that return Future[Unit]
On 01/02/2017 10:19, Viktor Klang wrote: Try(block).fold(Status.Success(_), Status.Failure(_)) Neat, I wasn't aware of that - it appeared in 2.12: https://issues.scala-lang.org/browse/SI-8336 Ta :-) -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Class cast exceptions in actors that return Future[Unit]
On 01/02/17 09:06, Viktor Klang wrote:
You're welcome. A reminder that the actual error messages are very
important to include. :)
Yes, I consider my wrist to be slapped ;-) Thanks again!
If there is no method in the java/scaladoc then you'll need to convert
manually.
If there is I haven't been able to spot it.
And if you need a shorthand, it should be a one-liner def. ;)
Well, nearly ;-) I just copied the "Try {???}" implementation but made
it return Akka Status values rather those used by Try - I don't need any
operations other than to return the Akka success types.
def actorTry[T](f: => T): akka.actor.Status.Status = {
try {
akka.actor.Status.Success(f)
} catch {
case NonFatal(e) => akka.actor.Status.Failure(e)
}
}
then in the receive method:
case Read(from, to, reader) => sender ! actorTry { read(from, to, reader) }
IIRC akka.actor.Status.Success was created aeons ago,
scala.util.Success was added with scala.util.Try, so they have
separate origins. (just like java.util.List and
scala.collection.immutable.List)
Ah, the curse of history :-) Sounds completely plausible - thanks.
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Is there a standard way of referencing external objects inside of custom serializers?
There's another wrinkle with the current Serialization API. It assumes
that serialization is always from/to binary. If you are using pure-JSON
and storing it in (say) a flat file you most likely want to serialize
the payload, then "wrap" that inside an outer JSON object containing the
serialization metadata needed by the persistence framework. e.g.:
{
"payload": {
"field1": "My serialized"
"field2": "object"
"field3": "goes here"
},
"serializerId": 100,
"tags": [],
"writerUuid": "215d6565-77b6-4355-ab84-9a89bebc1b52",
"sequenceNr": 148,
"serializerManifest": "MyPersistentObject",
"eventManifest": "",
"persistenceId": "MyPersistentActor-one"
}
What you get back from an Akka SerializerWithStringManifest is a Byte[],
which you need somehow to embed within the wrapper JSON. In the case of
Spray JSON, as far as I know the only way to do this would be to parse
the Byte[] back into a JSON parse tree again (!) and then wrap that.
I've worked around this by stubbing out the toBinary/fromBinary
functions in the SerializerWithStringManifest implementation and adding
toJSON/fromJSON methods instead. Then in the journal implementation,
when I do the serializer lookup I check it's of the expected serializer
type and call the toJSON/fromJSON methods.
That means the JSON serializer and journal implementation must be a
matching pair, which kind of sucks but at least it looks fairly "normal"
as far as the application.conf contents go. The other alternative would
be to just do away with a separate serializer class altogether and do
the JSON serialization directly inside the journal.
That might be one way of doing what you want - don't use the Akka
mechanism for configuring & looking up the serializer, just do it
explicitly inside the journal implementation?
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Class cast exceptions in actors that return Future[Unit]
Ahah! I think you may of nailed it... Thanks!
Indeed you did nail it - "thanks" doesn't come close as I'd looked at
this for so long that I'd gone completely snow-blind ;-)
Is there a convenient shorthand way of mapping between a
scala.util.Success and an akka.actor.Status.Success, or should I just do
it with a match expression? What I'm doing is wrapping the IO functions
that could fail in a "Try { ??? }" and returning the result to the
calling actor.
Is there a reason why there's both scala.util.Success and an
akka.actor.Status.Success?
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Class cast exceptions in actors that return Future[Unit]
On 31/01/17 23:34, Viktor Klang wrote: I think the problem is that your responding with a scala.util.Success rather than a akka.actor.Status.Success. Ahah! I think you may of nailed it... Thanks! -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Class cast exceptions in actors that return Future[Unit]
On 31/01/17 22:18, Viktor Klang wrote: The answer will be in the stack traces. What I got was: java.lang.ClassCastException: Cannot cast scala.util.Success to scala.runtime.BoxedUnit which didn't give me much of a clue, however it was clear that asInstanceOf wasn't the right approach and when I looked at the mapTo implementation it was going to throw an exception as well, which is why I settled on the map alternative - but that didn't feel quite right either, hence the question. Thanks for the confirmation that's the right approach. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Class cast exceptions in actors that return Future[Unit]
On 31/01/2017 21:36, Viktor Klang wrote: What'd be the alternative? Not sure really, don't know if there's any way of preserving a Future[Unit] rather than converting it to a Future[Any]. As I said, it just seemed a bit clunky, and not obvious immediately obvious as to how to solve the issue. Perhaps just a note in the docs about how to handle Future[Unit]? -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Class cast exceptions in actors that return Future[Unit]
On 31/01/2017 20:32, Akka Team wrote: You have a Future[Something], and a Something is an Any (everything is) but it is not Unit (only Unit is), so you can not just cast it, you must replace it with an actual Unit, which is what .map(_ => ()) does. OK, thanks for confirming that I haven't missed anything obvious. However that's a bit clunky - the method in the actor returns a Future[Unit], by the time it gets back to the "ask"ing Actor is has been converted to a Future[Any] and then you have to map it back to a Future[Unit] again. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Class cast exceptions in actors that return Future[Unit]
I'm writing an Akka persistence journal that saves data in JSON format. I've done that as normal, by subclassing AsyncWriteJournal and implementing the necessary methods. The actual file IO is done by sub-Actors, one per output file where each persistent actor has its own JSON file. The read/write methods on the IO Actor which return a value via 'ask' return a Future[Any] as per normal. However the asyncXXX methods in AsyncWriteJournal return Future[Unit], so the Future[Any] returned from the IO Actor needs to be converted to a Future[Unit]. I've tried a couple of ways of doing that: 1) Casting the return value with ".asInstanceOf[Future[Unit]]". This generates a ClassCast exception: 2) Applying ".mapTo[Unit]" to the return value. This generates a ClassCast exception: 3) Applying ".map(_ => ())" to the return value. This works, but sort of smells a bit. Is there a cleaner way of doing this? -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka persistence: can you use it as the main storage system for you application's data?
On 30/01/17 18:00, José González Gómez wrote: - You can't have access to data as you may have in a SQL or NoSQL database, so it seems to be hard to diagnose corrupt data or relationships among that data. Am I missing anything here? Not that I know of, which is why I'm hacking together a journal implementation that stores in text files using spray JSON to marshall/unmarshal the data. It won't be distributed, it may lose data if the JVM crashes and it won't be particularly fast, but it will allow you to manipulate the journals using tools like jq. My use case is for debugging and for a simulation application, where the journal files will be post-processed outside of the simulation. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Persistence plugin getting AtomicWrites with duplicate sequenceNr
On 27/01/17 11:36, Konrad Malawski wrote: Not "ever", but "at the same time". This is exactly the single writer principle. Otherwise you would have to check the entire cluster before each write making sure that there wasn't a conflicting write ;) there's quite some theory behind this. As I mentioned, CRDTs take the oppsosite stance. That's not really the problem domain I'm considering for my use of persistent actors. I'm prototyping a stateful simulation using Akka, where there are multiple instances of the same stateful entity type, which I want to implement as persistent actors, each with an unique ID. Initially this won't be distributed, just single node. Please read about cluster sharding. It accomplishes this without having to bother users with the details. I have and as a result I think I've figured out my misunderstanding. I believe what I need to do in my test is make sure that each instance of the persistent actor has an unique persistenceId, as per the demo code on the sharding page. That's used by the JSON journal implementation to generate an unique file for each persistence stream, and the sequence numbers are then unique as they are managed per-file. As I said I was sure I was missing something obvious, I just couldn't see what - thanks for pointing me in the right direction :-) -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Persistence plugin getting AtomicWrites with duplicate sequenceNr
On 27/01/17 10:59, Konrad Malawski wrote: So the uniequeness is to be guarnateed on persistentId. The writerUID exists for noticing that things are going wrong / have gone wrong and restoring from such failures. It is wrong to write tests that have 2 writers and expect a consistent output "just so", unless your journal will implement some logic that would resolve those conflicts. OK, thanks for the explanation. What I'm doing in the test is creating a second instance of a persistent actor. Are you saying that persistent actor classes can only ever have one instance? If so that seems very restrictive. If not, how do you create multiple instances of persistent actors without having duplicate persistence IDs? // Hope this helps, typed in a rush on an airplane It does, thank you - as I said I thought I was missing something obvious :-) -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Persistence plugin getting AtomicWrites with duplicate sequenceNr
I'm attempting to write a persistence plugin that saves in JSON format into flat files. I've got the basic write side working but I'm seeing records in the JSON file with duplicate sequenceNr values (PersistentRepr.sequenceNr). My test harness is creating two instances of the same PersistentActor which are then writing records. What seems to happen is that both actor instances are generating calls to AsyncWriteJournal.asyncReadHighestSequenceNr using the same persistenceId - unsurprisingly both actors then get the same value back from AsyncWriteJournal.asyncReadHighestSequenceNr and then use that as the sequenceNr for the records they persist via the persistence plugin. The records in the file that share the same persistence ID do however have different writerUuid values. What is, in effect, the primary key for persistence records? Is it just (sequenceNr) - in which case there is a problem - or is it (sequenceNr, writerUuid)? And if so, why doesn't AsyncWriteJournal.asyncReplayMessages take writerUuid as a parameter? I suspect I'm missing something blindingly obvious here, but for the life of me I can't see how this is supposed to work. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka Cassandra Persistence: multiple manifests?
On 18/01/2017 19:32, Patrik Nordwall wrote: The event's serialization manifest is stored in "ser_manifest" and the PersistentRepr.manifest is stored in "event_manifest". I can see the confusion :) and I guess the naming went bad in one of many refactorings. Can't change column names now. It's no big deal ;-) The two manifests have different purposes. "ser_manifest" together with "ser_id" is used for the serialization of the event (payload). Yep, that's what I'd figured out. PersistentRepr.manifest is used by the event adapters (in akka-persistence). Ahah, that's the bit I was missing - where they were used. Thanks :-) https://github.com/akka/akka/blob/v2.4.16/akka-persistence/src/main/scala/akka/persistence/journal/EventAdapter.scala#L39 -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Akka Cassandra Persistence: multiple manifests?
I've been looking at the implementation of Cassandra persistence, there appears to be two manifests that get persisted to Cassandra, one related to the PersistentRepr and one related to the serializer that's being used. https://github.com/akka/akka-persistence-cassandra/blob/master/src/main/scala/akka/persistence/cassandra/journal/CassandraJournal.scala#L392 Why is is the PersistentRepr one saved? I don't seem to be able to find it being used anywhere. Thanks, -- Alan Burlison -- -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Persisting entirely in JSON
On 17/01/2017 06:49, Patrik Nordwall wrote: Or I could just save the required fields as an outer JSON 'wrapper' over the application event that's been serialized, perhaps? Yes, that sounds good for Json. Thanks, good to know I'm not completely off base :-) That doesn't seem to be possible - findSerializerFor can't be passed the payload as PersistentRepr.payload returns an Any, e.g. // p is a PersistentRepr val bytes = ser.findSerializerFor(p.payload).toBinary(p.payload) does not compile as findSerializerFor expects an AnyRef. You can safely cast it to AnyRef, .asInstanceOf[AnyRef] I think you can use ser.serialize(event).get If you need manifest and such, here is an example: https://github.com/akka/akka-persistence-cassandra/blob/master/src/main/scala/akka/persistence/cassandra/journal/CassandraJournal.scala#L380 That's very useful, the manifest part in particular - just what I was looking for as an example, thanks. I did wonder why payload is an Any rather than an AnyRef - casting was my first thought but it kinda smells... I did look at EventAdapter but it looked like you still needed to feed that through a Journal implementation, which is what I'm struggling with here. Yes, but then the EventAdapter would be responsible for creating the JSON and the journal would not user serialization. Not saying that it's needed or better in your case. I think I can just do it in the AsyncWriteJournal implementation in my case, as what I want is simple. One further question - I see mention in the docs and source of tags, I don't think it's something I'll need, at least not initially. I assume it's OK to just leave it all unimplemented? Thanks again for the help and pointers, -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Persisting entirely in JSON
On 16/01/17 21:22, Patrik Nordwall wrote: You should not serialize PersistentRepr, unless you are using a key-value store that can only store one single value per key. It's a flat file so the concept of columns only exists insofar as I define it - which is why I was intending to serialize to JSON. Isn't PersistentRepr saved inside the datastore? If so, how is it normally serialized, eg in the LevelDB datastore? Instead, grab the meta data fields from PersistentRepr and save them in separate columns. Or I could just save the required fields as an outer JSON 'wrapper' over the application event that's been serialized, perhaps? Grab the payload, serialize it, and save its bytes (the json) in a separate column. That doesn't seem to be possible - findSerializerFor can't be passed the payload as PersistentRepr.payload returns an Any, e.g. // p is a PersistentRepr val bytes = ser.findSerializerFor(p.payload).toBinary(p.payload) does not compile as findSerializerFor expects an AnyRef. It's also possible to not use a serializer (bytes) at all and instead use an EventAdapter to transform the domain events to json representation (e.g. I would imagine this would be efficient for MongoDB and crating BSON instead of using bytes). I did look at EventAdapter but it looked like you still needed to feed that through a Journal implementation, which is what I'm struggling with here. The docs really don't give you much help on how to write a AsyncWriteJournal - they tell you about the API but I haven't been able to find any information about how you hook it up with the serializer, for example. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Persisting entirely in JSON
On 16/01/17 20:45, Konrad Malawski wrote: Pick a Journal which does this, simple. Akka has absolutely no control over how a given Akka Persistence Journal Plugin decides to persist things. Research the available journals and which allows to save things like this. I have, I've been unable to find one. You did not mention which datastore you're using, which is very very relevant to this question. Flat file, JSON content. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Persisting entirely in JSON
I'm trying to write a persistence journal plugin (AsyncWriteJournal)
that saves entirely in JSON. I've created a serializer that serializes
to JSON and hooked that up along with my custom journal plugin, and
whilst the objects I'm saving are being persisted as JSON, the
PersistentRepr that wraps them isn't. Here's what I have:
def asyncWriteMessages(messages: immutable.Seq[AtomicWrite]):
Future[immutable.Seq[Try[Unit]]] = {
val ser = SerializationExtension(context.system)
for (m <- messages; p <- m.payload) {
val bytes = ser.findSerializerFor(p).toBinary(p)
// XXX Real thing would write to persistent storage here
println(new String(bytes))
}
Future.successful(Nil)
}
How do I get the *entire* payload that's stored in the journal saves
in JSON via my custom serializer?
Thanks,
--
Alan Burlison
--
--
>>>>>>>>>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: Simple flatfile + JSON persistence plugin?
On 12/01/2017 19:07, Rafał Krzewski wrote: Of course all this is moot if said tool already exist, and you are now trying to tweak Akka to produce event log in suitable format :) That's the use case - JSON text files containing a sequence of events are the desired output. Being able to use the same file format for both Akka persistence and the external analysis tools would be a bonus, plus not having to set up a RDBMS, or any other external data store for that matter, is important - ideally I'd just be able to distribute a single JAR file containing the simulator. I could embed Apache Derby and use that for persistence, but that's still really overkill. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Simple flatfile + JSON persistence plugin?
I have some fairly non-standard requirements for a persistence plugin for a long-running lo-event-rate simulation - I can assume a shared filesystem, the event rates will be low (10/sec max) and I'd like to use the persistence files with external tools to analyse the event stream from outside of the emulation. I'm considering using JSON in flatfiles as the format, by writing my own persistence plugins. I haven't been able to find such a plugin, does anyone know of one, and if not are there any caveats I should particularly be aware of, other than the usual atomicity/asynchronous ones? Thanks, -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka-HTTP: accessing the path in a rejection handler
> I added this to the docs in case it wasn't obvious at first sight: > https://github.com/akka/akka-http/pull/744 Works a treat, thank you :-) -- Alan Burlison -- -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Akka-HTTP: accessing the path in a rejection handler
I have a rejection handler that handles non-existent paths via handleNotFound. However I can't seem to find an obvious way of accessing the path in question so it can be displayed/logged by the handler. Is there a way? -- Alan Burlison -- -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka Artery
On 07/01/2017 16:31, Patrik Nordwall wrote: That is for the c++ client as far as I know, and that is not used by Akka. Ah, good to hear, thank you for the clarification :-) -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka Artery
On 07/01/2017 12:54, Patrik Nordwall wrote: In what environment have you seen that Aeron does not work? It works on Windows. It's Java, no native. I haven't used Aeron myself, it was a general observation about JNI-based packages on non-x86 architectures, e.g. SPARC. What made me think that Aeron had a JNI dependency was the mention of C++ and CMake. If that's just an optional requirement, great :-) -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka Artery
On 06/01/2017 10:15, Konrad Malawski wrote: You may also want to track our blog, as we're publishing things about Artery internals there: http://blog.akka.io/artery/2016/12/02/streams-in-artery http://blog.akka.io/artery/2016/12/05/aeron-in-artery I notice you are using Aeron as part of the implementation. Will that be mandatory, or optional? In my experience (Hadoop, Spark), platform-dependent binary dependencies such as Aeron are problematic for platforms other that Linux/x86 because multiple, often difficult to fix endian and alignment issues. It appears the main focus of Aeron is performance. There are other cases where the focus is on cross-platform rather than performance, a pure-Java is going to be preferable in those cases. -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Code in Akka-HTTP documentation doesn't seem to compile
Gah, yes, clicked on the wrong goddam doc link, sorry for the noise,
time to go to bed I think...
The continual "{}" nesting in the Scala DSL get's messy pretty quickly...
--
Alan Burlison
--
--
>>>>>>>>>> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
[akka-user] Code in Akka-HTTP documentation doesn't seem to compile
From
http://doc.akka.io/docs/akka-http/current/java/http/routing-dsl/directives/respond-with-directives/respondWithHeader.html
final Route route = path("foo", () ->
respondWithHeader(RawHeader.create("Funky-Muppet", "gonzo"), () ->
complete("beep")));
That doesn't look like valid syntax and there's no create() method on
RawHeader as far as I can tell, but even with that cleaned up:
val route = path("foo", () ->
respondWithHeader(RawHeader("Funky-Muppet", "gonzo"), () ->
complete("beep")));
too many arguments (2) for method path: (pm:
akka.http.scaladsl.server.PathMatcher[L])akka.http.scaladsl.server.Directive[L]
val route1 = path("foo", () ->
The "() ->" idiom that I've also seen elsewhere in the documentation
doesn't seem to work?
If I want to chain together respondWithHeader() and complete(), what's
the correct idiom?
Thanks,
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] How to call a Future-based test from a Route?
On 02/01/17 21:12, Konrad Malawski wrote:
How about sharing in a blog or docs about how to go about building such?
I think that'd be very interesting to people who're faced similar questions
as you were just a few days ago :)
Here's what I ended up with:
def authBasicHttp: Directive1[Login] = {
authenticateBasicAsync(null, {
case cp @ Credentials.Provided(user) =>
Future(Users.userPassword(user).flatMap { p => if (cp.verify(p))
Some(Login(user)) else None })
case _ => Future.successful(None)
})
}
def authXHeader: Directive1[Login] = {
(headerValueByName("X-Auth-User") &
headerValueByName("X-Auth-Key")).tflatMap { up =>
onComplete(Future { Users.validUser(up._1, up._2) }).flatMap {
case Success(Some(l)) => provide(l)
case Success(None) => reject(AuthRejection("invalid credentials"))
case Failure(e) => reject(AuthRejection("internal error"))> }
}
}
def authXSession: Directive1[Login] = {
headerValueByName("X-Auth-Session").flatMap { s =>
onComplete(Future { Users.validSession(s) }).flatMap {
case Success(Some(l)) => provide(l)
case Success(None) => reject(AuthRejection("invalid credentials"))
case Failure(e) => reject(AuthRejection("internal error"))
}
}
}
def combinedAuth = authBasicHttp | authXHeader | authXSession
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] How to call a Future-based test from a Route?
On 02/01/17 21:12, Konrad Malawski wrote: How about sharing in a blog or docs about how to go about building such? I think that'd be very interesting to people who're faced similar questions as you were just a few days ago :) Sure, I'll write something up when I have it polished up :-) -- Alan Burlison -- -- 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] How to call a Future-based test from a Route?
On 02/01/17 12:50, 'Johannes Rudolph' via Akka User List wrote:
Yes, right, I forgot that `flatMap` is only defined for Directive1. So, it
needs to be
headerValueByName("X-Auth-Key").tflatMap { case (user, pass) =>
instead.
def xAuth: Directive1[Session] =
(headerValueByName("X-Auth-User") &
headerValueByName("X-Auth-Key")).tflatMap { up =>
onComplete(authenticateUserPass(up._1, up._2)).flatMap {
case Success(s) => provide(s)
case Failure(ex) => reject()
}
}
seems to be what is required.
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] How to call a Future-based test from a Route?
On 02/01/17 11:51, 'Johannes Rudolph' via Akka User List wrote:
here are a few steps to get there:
[snip]
HTH,
It does indeed, thank you :-)
One question:
headerValueByName("X-Auth-Key")).flatMap { (user, pass) =>
// <- user flatMap for custom directives
doesn't compile as the resulting value of type Directive[(String,
String)] doesn't have a flatMap. Do you mean tFlatMap?
--
Alan Burlison
--
--
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] How to call a Future-based test from a Route?
> Have you seen the complete list of directives? > There's many directives with "Async" that means that they work on Futures. I've seen the async authorization directives but none of them fit the header mechanism I'm trying to emulate. authenticateOrRejectWithChallenge() seems to come closest but on failure I don't want a challenge response, just a rejection. I see onComplete() takes a future which looks closer to what I want but how you'd combine an authenticateBasicAsync with two other Future-based custom authentication mechanisms so that you get a single result or a rejection is completely unclear to me. I must say that I'm finding the high level Akka-HTTP API rather difficult to use, for simple cases it all looks so easy but as soon as you step outside of that it immediately gets incredibly complicated :-/ -- Alan Burlison -- -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
