[akka-user] akka-cluster workarounds for not being able to re-join cluster without restart?
We're currently using akka for a variety of things, and are starting some experiments with akka-cluster, but we've hit one roadblock. >From the documentation on akka-cluster membership lifecycle (http://doc.akka.io/docs/akka/2.5.4/scala/common/cluster.html#membership-lifecycle) : the actor system must be restarted before it can join the cluster again. The way we do deploys is to bootup new instances and bring them into the load balancer and move old instances out of the load balancer. It seems logical then, that anything in the load balancer should be a participant in our akka-cluster, while anything out of the load balancer should leave. The problem comes for how we do a rollback: we would bring the old instances back into the load balancer, but now they can't be part of the akka-cluster anymore. Restarting the process might work for some of our applications, but it's not an elegant solution in general for us, as some applications might have long-running jobs that should finish before a restart. Has anyone used akka-cluster in this type of deployment style, and what did you come up with? Thanks! -- >> 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] compiler issues with routing dsl when trying to abstract REST operations
I'm working on a small layer powered by akka-http routing DSL to sort of enforce all the RESTful APIs have the same structure. Implementation should just have to define the URL the work on, then the create/read/update/delete/etc. My idea was to pass the PathMatcher into the constructor, and capture its type with an implicit for re-use later. I was able to get this to work if I was willing to define all routes using tuples, but when I tried to re-use the magic of ApplyConverter, I couldn't get the nice syntax of regular methods instead of tuples. Code with errors in comments is here: https://gist.github.com/chadselph/baa3204fed9977b96bd977dd85f6747e What do I need to do to convince the compiler these types are identical? (I've minimized the code quite a bit, so that's why it looks useless.) thanks for any tips! -- >> 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: Modeling simple TCP protocol that isn't always request/response in akka-stream
Thanks for the examples. I ended up just using ActorSink/ActorSubscriber and using akka-stream exclusively for the TCP layer (actors for the rest), but I may go back to the stream approach if I want to integrate stream backpressure into the protocol's backpressure. On Tuesday, July 14, 2015 at 9:43:39 PM UTC+3, Chad Retz wrote: I just had to do this and I found the AsyncStage which allows out-of-band messages to get added to the stream. It and the DetachedStage are not yet documented[0] but after reading enough other code and taking some guesses, I was able to get out-of-band messages into my IMAP server via an AsyncStage[1] so that it would work with IDLE[2]. Hopefully it helps. 0 - http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-RC4/scala/stream-customize.html#Using_DetachedStage 1 - https://github.com/cretz/scimap/blob/a8dd56f9c2988098e61d1e30c495ea9ed14944dd/src/main/scala/scimap/handler/ServerHandlerStage.scala 2 - https://github.com/cretz/scimap/blob/a8dd56f9c2988098e61d1e30c495ea9ed14944dd/src/it/scala/scimap/JavaMailSpec.scala#L114 On Wednesday, July 1, 2015 at 6:55:33 AM UTC-5, Chad Selph wrote: I tried something like this, where I had a PushPullStage that accepted a Source into its constructor. It seemed like the wrong approach, because it seemed like I was just reimplementing a common merge functionality. On Wednesday, July 1, 2015 at 3:58:49 AM UTC+3, Chad Retz wrote: Although I have not done this yet, I would assume you can do this with a PushPullStage that pushes in onPull. How the state gets there to know when to push in onPull is probably an implementation detail. On Monday, June 29, 2015 at 5:15:53 AM UTC-5, Chad Selph wrote: I'm currently rewriting a library I have that previously used akka IO pipelines. Reading through the examples of streaming IO with akka-stream and akka-http, I've only seen examples with request - response type protocols. Currently, I have a BidiFlow that serializes/deserializes between ByteStrings and case classes, but I only know how to make this work in one direction (client makes request, server replies to request). In this protocol, the server can also initiate requests to the client. How can I inject a message into the BidiFlow that isn't just a response to a client request? I understand at a high level the solution is probably to make a Graph with another Source pointing to my serializer, but I've had a tough time wrapping my head around the graph DSL. If someone could point me to an example of something similar, I'd very much appreciate it. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: Modeling simple TCP protocol that isn't always request/response in akka-stream
I tried something like this, where I had a PushPullStage that accepted a Source into its constructor. It seemed like the wrong approach, because it seemed like I was just reimplementing a common merge functionality. On Wednesday, July 1, 2015 at 3:58:49 AM UTC+3, Chad Retz wrote: Although I have not done this yet, I would assume you can do this with a PushPullStage that pushes in onPull. How the state gets there to know when to push in onPull is probably an implementation detail. On Monday, June 29, 2015 at 5:15:53 AM UTC-5, Chad Selph wrote: I'm currently rewriting a library I have that previously used akka IO pipelines. Reading through the examples of streaming IO with akka-stream and akka-http, I've only seen examples with request - response type protocols. Currently, I have a BidiFlow that serializes/deserializes between ByteStrings and case classes, but I only know how to make this work in one direction (client makes request, server replies to request). In this protocol, the server can also initiate requests to the client. How can I inject a message into the BidiFlow that isn't just a response to a client request? I understand at a high level the solution is probably to make a Graph with another Source pointing to my serializer, but I've had a tough time wrapping my head around the graph DSL. If someone could point me to an example of something similar, I'd very much appreciate it. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Modeling simple TCP protocol that isn't always request/response in akka-stream
I'm currently rewriting a library I have that previously used akka IO pipelines. Reading through the examples of streaming IO with akka-stream and akka-http, I've only seen examples with request - response type protocols. Currently, I have a BidiFlow that serializes/deserializes between ByteStrings and case classes, but I only know how to make this work in one direction (client makes request, server replies to request). In this protocol, the server can also initiate requests to the client. How can I inject a message into the BidiFlow that isn't just a response to a client request? I understand at a high level the solution is probably to make a Graph with another Source pointing to my serializer, but I've had a tough time wrapping my head around the graph DSL. If someone could point me to an example of something similar, I'd very much appreciate it. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: Propagation of error messages for Tcp Connect
Sorry to hi-jack this 2 month old thread; but I actually had the same
problem and having it in DEBUG log isn't quite enough for me.
Basically there's a feature of my app that could use the failure mode for
diagnostics: timeout in our use-case typically means someone forgot to
open their firewall where connection refused means we probably have the
wrong connection information. Ideally, this would get surfaced in my GUI,
instead of someone needing to ping/telnet/netcat on the terminal to
disambiguate these cases.
Not absolutely critical, but just thought I'd add some feedback in favor of
adding this to the ConnectionFailed case class.
On Tuesday, April 8, 2014 8:29:27 AM UTC-7, Andrew Charles wrote:
I'm building a simple load testing application that uses akka to connect
to a server via TCP. I am using the examples provided for connecting to a
TCP endpoint in the akka IO docs.
One thing I immediately run into is that while the system will tell you
that a connection attempt has failed, there is no way to access the reason
it failed. After looking at the source code for TcpOutgoingConnection, it
looks like it is simply output to the DEBUG level in akka and that's it.
Here is my code for handling a connection failure:
case CommandFailed(c: Connect) =
println(sConnect failed to $remote. Reason: ${c.failureMessage}. Will try
again in 30 seconds)
This simply tells me CommandFailed(Connect) without giving me a detailed
reason, such as connection refused.
Perhaps I'm missing something here, but is there a way to get to this
information so I can display it on the console without having to force akka
into DEBUG log mode?
Thanks for any assistance!
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
