Re: [akka-user] Getting strange error 2.4-Snapshot with stream+http 1.0-M2
Hi,
Streams is compiled against Akka 2.3.x which is not guaranteed to be binary
compatible with 2.4. I expect that the above code to work with Akka 2.3.x.
(if not, then this is a bug)
-Endre
On Wed, Jan 7, 2015 at 4:40 AM, tigerfoot gzol...@gmail.com wrote:
Hello,
I've got this code:
def httpGet( uri:String )(implicit s:ActorSystem) = {
implicit val materializer = FlowMaterializer()
var r:HttpResponse = null
val req = HttpRequest(HttpMethods.GET, Uri(uri))
val host:String = req.uri.authority.host.toString
val port:Int = req.uri.effectivePort
val httpClient = Http().outgoingConnection(host,port).flow
val consumer = Sink.foreach[HttpResponse] { resp ⇒ r = resp }
*val finishFuture = Source.single(req).via(httpClient).runWith(consumer)*
*// -- GOES BOOM HERE*
Await.result(finishFuture, Duration(3 seconds))
// unpack result
(r.status.intValue,
Await.result(r.entity.toStrict(FiniteDuration(3,seconds)), Duration(3
seconds) )
.data
.utf8String)
}
This works pretty well--for a while. When run in a long-running process,
eventually it dies with the exception below.
Any idea what's cause it?
Thanks for any ideas,
Greg
Uncaught error from thread [overlord-akka.actor.default-dispatcher-143]
shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for
ActorSystem[overlord]
java.lang.NoSuchMethodError:
akka.pattern.AskableActorRef$.$qmark$extension(Lakka/actor/ActorRef;Ljava/lang/Object;Lakka/util/Timeout;)Lscala/concurrent/Future;
at
akka.stream.impl.ActorBasedFlowMaterializer.actorOf(ActorBasedFlowMaterializer.scala:471)
at
akka.stream.impl.ActorBasedFlowMaterializer.actorOf(ActorBasedFlowMaterializer.scala:458)
at
akka.stream.impl.ActorBasedFlowMaterializer.materializeJunction(ActorBasedFlowMaterializer.scala:506)
at
akka.stream.scaladsl.FlowGraph$$anonfun$6$$anonfun$apply$8.apply(FlowGraph.scala:1248)
at
akka.stream.scaladsl.FlowGraph$$anonfun$6$$anonfun$apply$8.apply(FlowGraph.scala:1212)
at
akka.stream.impl.DirectedGraphBuilder.edgePredecessorBFSfoldLeft(DirectedGraphBuilder.scala:240)
at akka.stream.scaladsl.FlowGraph$$anonfun$6.apply(FlowGraph.scala:1212)
at akka.stream.scaladsl.FlowGraph$$anonfun$6.apply(FlowGraph.scala:1209)
at
scala.collection.TraversableOnce$$anonfun$foldLeft$1.apply(TraversableOnce.scala:144)
at
scala.collection.TraversableOnce$$anonfun$foldLeft$1.apply(TraversableOnce.scala:144)
at scala.collection.Iterator$class.foreach(Iterator.scala:727)
at scala.collection.AbstractIterator.foreach(Iterator.scala:1157)
at scala.collection.IterableLike$class.foreach(IterableLike.scala:72)
at scala.collection.AbstractIterable.foreach(Iterable.scala:54)
at
scala.collection.TraversableOnce$class.foldLeft(TraversableOnce.scala:144)
at scala.collection.AbstractTraversable.foldLeft(Traversable.scala:105)
at akka.stream.scaladsl.FlowGraph.runGraph(FlowGraph.scala:1209)
at akka.stream.scaladsl.FlowGraph.run(FlowGraph.scala:1184)
at akka.stream.scaladsl.Source$class.runWith(Source.scala:38)
at akka.stream.scaladsl.GraphSource.runWith(GraphFlow.scala:128)
*at com.rs.overlord.Util$.httpGet(Util.scala:29) -- HIGHLIGHTED LINE IN
ABOVE CODE*
at
com.rs.overlord.OverlordActor$$anonfun$receive$1$$anonfun$applyOrElse$1$$anonfun$apply$1.apply$mcV$sp(OverlordActor.scala:32)
at
com.rs.overlord.OverlordActor$$anonfun$receive$1$$anonfun$applyOrElse$1$$anonfun$apply$1.apply(OverlordActor.scala:30)
at
com.rs.overlord.OverlordActor$$anonfun$receive$1$$anonfun$applyOrElse$1$$anonfun$apply$1.apply(OverlordActor.scala:30)
at scala.util.Try$.apply(Try.scala:161)
at
com.rs.overlord.OverlordActor$$anonfun$receive$1$$anonfun$applyOrElse$1.apply(OverlordActor.scala:30)
at
com.rs.overlord.OverlordActor$$anonfun$receive$1$$anonfun$applyOrElse$1.apply(OverlordActor.scala:29)
at scala.collection.immutable.HashMap$HashMap1.foreach(HashMap.scala:224)
at
scala.collection.immutable.HashMap$HashTrieMap.foreach(HashMap.scala:403)
at
scala.collection.immutable.HashMap$HashTrieMap.foreach(HashMap.scala:403)
at
com.rs.overlord.OverlordActor$$anonfun$receive$1.applyOrElse(OverlordActor.scala:29)
at akka.actor.Actor$class.aroundReceive(Actor.scala:465)
at com.rs.overlord.OverlordActor.aroundReceive(OverlordActor.scala:24)
at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)
at akka.actor.ActorCell.invoke(ActorCell.scala:487)
at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)2015-01-06
22:33:46.970 ERROR [overlord-akka.actor.default-dispatcher-156] Uncaught
error from thread [over
--
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] Re: Akka Cluster Project - Monolithic JAR or JARs per service?
*Awesome*. This is exactly the answer I was looking for, Ryan! I need to read and re-read your post a couple more times for it to sink in, but this seems like a great starting point. A blog article on this topic would really be appreciated, though! :- ) I'm of the opinion that while Typesafe has done an absolutely brilliant job at documenting the technology from a developer's point of view, documentation on the ops/production side of things really is a little lacking. I'm super glad that business like Conspire are giving back to the community like this - your 5 part blog series has been absolutely invaluable to us. Thanks again, Ryan, Kane On Wednesday, 7 January 2015 02:39:57 UTC+11, Ryan Tanner wrote: We're also deploying an Akka cluster on CoreOS with Docker. We deploy the same fat JAR for every node (in fact, the exact same docker image) and then change their behavior by setting the role via environment variables. In our case, each role has a bootstrap class which sets up whatever role-specific actors might be needed (but *not* the worker actors) as well as the actors needed on every node. Cluster-aware routers running on our supervisor node are responsible for actually creating the worker actors as needed. We still split each role into sub-projects in our SBT project. We then have an SBT project within that called node which aggregates all of the service-specific sub-projects into a single JAR and builds the Docker image using sbt-docker. This way, we can iterate quickly on code within a specific service and keep our compile/test times down. That node project also houses our multi-JVM end-to-end tests. Then, opposite that, is our commons project which every other project depends on. The service projects explicitly do *not* depend on each other, only commons. This keeps us from getting them too coupled. Since our service isn't directly user-facing, we don't bother trying to upgrade a single service at a time, we just restart the whole thing and let it pull down the new Docker image if needed. Most of this is written up on our blog: http://blog.conspire.com/post/64130417462/akka-at-conspire-part-1-how-we-built-our-backend-on I've been meaning to write about our transition from Chef/Vagrant to CoreOS/Docker but I haven't found the time yet. Hopefully within the next few weeks (which, of course, I said a month ago). On Sunday, January 4, 2015 6:42:21 PM UTC-7, Kane Rogers wrote: Hi, hAkkers! We're in the process of moving our distributed Akka service from the dark ages of remoting and manual management of IPs (shudder) into the wonderful new world of Akka Cluster. Currently, our project is split up something like this: - spray-frontend - worker-1 - worker-2 - worker-3 Where the spray-frontend forwards messages to the different worker, depending on the type of job. In our current environment, each of these projects are deployed as individual fat JARs using sbt-assembly, and deployed onto individual nodes. In our planned environment, we'll be deploying these fat JARs into docker containers and allow CoreOS to take care of distributing the nodes. We're toying with things like roles, ClusterPoolRouter and ClusterGroupRouter to take care of distributing work amongst the correct node - but nothing is set in stone yet. This then begs the question - how should these nodes be deployed? I can see a couple of possibilities: - Docker container with fat JAR per project (eg. spray-frontend container, worker-1 container etc. etc). - Docker container with fat JAR containing all projects (eg. one container containing code for spray-frontend AND worker-1 etc.). Role is then set via environment variable, or a different main class is fired off on startup. Exploring the different options, one limitation that I can see is that ClusterPoolRouter requires the class of the actor that's going to be remotely deployed to the cluster to be *present on the class path of the router. *That is, if our front-ends are to create a worker on a remote machine to handle a request, the class for that router must be in the JAR on the front-end machine. *Please correct me if I'm mistaken here.* The advantage we've found in splitting the project up into these different sub-projects is tests are a lot quicker, code is smaller, etc. etc. Upgrades are also then made easier, as only certain machines have to be upgraded/restarted if a component of the service is improved/fixed. We also have a shared project between the different services that contains the dialect (eg. the different case classes for message sent between services). This was a best practice that we read about when we first went down the Akka path a couple of years ago, but things may have changed since then! Any suggestions, past experience, pointers to articles to read, activator templates or even just
[akka-user] calling code that uses jsr166y
Hi I'm going to be calling some Java multi-threaded code that is currently using JSR166Y (due to backward compatibility requirements with some legacy java 6 code). My Java developer wants to know if he should do a branch to use java7 (or 8) compatible fork join pool instead The intention is I call this from within an actor and possibly from within multiple actors (i.e. simultaneously). So I could have 2 or 3 actors each calling this code (a fairly long lived dynamic program at up to 500ms) which itself is using fork join to parallel process with a fairly low number of threads. Is there a recommendation of best practice here? Tim -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] calling code that uses jsr166y
Hi Tim, is it using ForkJoinTask/RecursiveTask directly? On Wed, Jan 7, 2015 at 12:23 PM, Tim Pigden tim.pig...@optrak.com wrote: Hi I'm going to be calling some Java multi-threaded code that is currently using JSR166Y (due to backward compatibility requirements with some legacy java 6 code). My Java developer wants to know if he should do a branch to use java7 (or 8) compatible fork join pool instead The intention is I call this from within an actor and possibly from within multiple actors (i.e. simultaneously). So I could have 2 or 3 actors each calling this code (a fairly long lived dynamic program at up to 500ms) which itself is using fork join to parallel process with a fairly low number of threads. Is there a recommendation of best practice here? Tim -- 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. -- Cheers, √ -- 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] akka.actor.ActorNotFound In Spark Streaming on Mesos (using ssc.actorStream)
Hi all, I have an actorNotFound problem on Spark 1.2.0 on mesos0.21.0 The full problem is described here: http://apache-spark-user-list.1001560.n3.nabble.com/akka-actor-ActorNotFound-In-Spark-Streaming-on-Mesos-using-ssc-actorStream-tt21014.html To sum up: In local mode path is akka://sparkDriver/user/Supervisor0/helloer And working fine On mesos path is akka://sparkExecutor/user/Supervisor0/helloer Exception in thread main akka.actor.ActorNotFound: Actor not found for: ActorSelection[Anchor(akka://sparkDriver/), Path(/user/Supervisor0/helloer)] Any ideas how to get some useful information on my actor systems (host/port)? Anyone knows about the akka configuration of Spark? Any other ideas? -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] calling code that uses jsr166y
Hi Viktor, Ok sorry - I'm not an expert in these matters - apologies for the vagueness. I'll do some homework and make him read the docs. Dispatcher looks a good place to start. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] calling code that uses jsr166y
hi - yes On 7 January 2015 at 11:32, Viktor Klang viktor.kl...@gmail.com wrote: Hi Tim, is it using ForkJoinTask/RecursiveTask directly? On Wed, Jan 7, 2015 at 12:23 PM, Tim Pigden tim.pig...@optrak.com wrote: Hi I'm going to be calling some Java multi-threaded code that is currently using JSR166Y (due to backward compatibility requirements with some legacy java 6 code). My Java developer wants to know if he should do a branch to use java7 (or 8) compatible fork join pool instead The intention is I call this from within an actor and possibly from within multiple actors (i.e. simultaneously). So I could have 2 or 3 actors each calling this code (a fairly long lived dynamic program at up to 500ms) which itself is using fork join to parallel process with a fairly low number of threads. Is there a recommendation of best practice here? Tim -- 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. -- Cheers, √ -- 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 a topic in the Google Groups Akka User List group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/D4eu8JUq2Lk/unsubscribe. To unsubscribe from this group and all its topics, 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. -- Tim Pigden Optrak Distribution Software Limited +44 (0)1992 517100 http://www.linkedin.com/in/timpigden http://optrak.com Optrak Distribution Software Ltd is a limited company registered in England and Wales. Company Registration No. 2327613 Registered Offices: Suite 6,The Maltings, Hoe Lane, Ware, SG12 9LR England This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Optrak Distribution Software Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] calling code that uses jsr166y
Hmmm, I've reread your question a couple of times and I am not sure what you are asking, is there something more specific your wonder? (I don't know what goals you have) On Wed, Jan 7, 2015 at 12:40 PM, Tim Pigden tim.pig...@optrak.com wrote: hi - yes On 7 January 2015 at 11:32, Viktor Klang viktor.kl...@gmail.com wrote: Hi Tim, is it using ForkJoinTask/RecursiveTask directly? On Wed, Jan 7, 2015 at 12:23 PM, Tim Pigden tim.pig...@optrak.com wrote: Hi I'm going to be calling some Java multi-threaded code that is currently using JSR166Y (due to backward compatibility requirements with some legacy java 6 code). My Java developer wants to know if he should do a branch to use java7 (or 8) compatible fork join pool instead The intention is I call this from within an actor and possibly from within multiple actors (i.e. simultaneously). So I could have 2 or 3 actors each calling this code (a fairly long lived dynamic program at up to 500ms) which itself is using fork join to parallel process with a fairly low number of threads. Is there a recommendation of best practice here? Tim -- 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. -- Cheers, √ -- 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 a topic in the Google Groups Akka User List group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/D4eu8JUq2Lk/unsubscribe. To unsubscribe from this group and all its topics, 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. -- Tim Pigden Optrak Distribution Software Limited +44 (0)1992 517100 http://www.linkedin.com/in/timpigden http://optrak.com Optrak Distribution Software Ltd is a limited company registered in England and Wales. Company Registration No. 2327613 Registered Offices: Suite 6,The Maltings, Hoe Lane, Ware, SG12 9LR England This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Optrak Distribution Software Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. -- 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. -- Cheers, √ -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] calling code that uses jsr166y
Hi Tim, Akka fork-join-executor-based dispatchers uses Scala's embedded jsr166 version of FJ. I don't think it lets you work with FJT though. On Wed, Jan 7, 2015 at 1:16 PM, Tim Pigden tim.pig...@optrak.com wrote: Hi Viktor, Ok sorry - I'm not an expert in these matters - apologies for the vagueness. I'll do some homework and make him read the docs. Dispatcher looks a good place to start. -- 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. -- Cheers, √ -- 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] Deficiencies in actor testability?
The issue of testing business functionality that may be implemented in the
class extending Actor has been raised quite a few times and I haven't found
any good suggestions yet. Most Actor testing examples are focused around
message receipt, type, timing etc. Akka team's response to this
post https://groups.google.com/forum/#!topic/akka-user/tWAvAMMcOYs seems to
be very dismissive. Why? This is legitimate issue! If there is no good way
to test functionality provided by classes extending Actors then perhaps it
should be stated please delegate such functionality to services etc.
What is wrong with example 1, and if nothing, how it is different from
example 2 where I want to stub methodB()?
Example 1 from https://code.google.com/p/specs/wiki/UsingMockito
object spec extends Specification with Mockito {
val m = mock[java.util.List[String]] // a concrete class would be
mocked with: mock(new java.util.LinkedList[String])
// stub a method call with a return value
m.get(0) returns one
...
}
Example 2
class ActorUnderTest extends Actor {
def receive = {
case TestMessage = methodA()
}
def methodA() = {
methodB()
//doSomtehing
}
def methodB() = {
}
}
Andre Piwoni
--
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] Akka Http Client - User-Agent header
Hey guys, is it possible to set custom header (User-Agent) for akka
streams
val connection = Http().outgoingConnection(someServer, 443)
val request:HttpRequest = RequestBuilding.Get(s/some/address.json)
//I want to add header here
//request.addHeader(HttpHeader(User-Agent,Mozilla/4.0 (compatible; MSIE
6.0; Windows NT 5.0)))
Source.single(request).via(connection.flow).runWith(Sink.head).flatMap {
response =
response.status match {
case status if status.isSuccess =
val ticker = Unmarshal(response.entity).to[Ticker]
println(ticker)
ticker
case status =
println(s$status error:${response.toString})
Future.failed(new IOException(sToken request failed with status
${response.status} and error ${response.entity}))
}
}
--
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: Akka Cluster Project - Monolithic JAR or JARs per service?
Glad to help! On Wednesday, January 7, 2015 3:53:28 AM UTC-7, Kane Rogers wrote: *Awesome*. This is exactly the answer I was looking for, Ryan! I need to read and re-read your post a couple more times for it to sink in, but this seems like a great starting point. A blog article on this topic would really be appreciated, though! :- ) I'm of the opinion that while Typesafe has done an absolutely brilliant job at documenting the technology from a developer's point of view, documentation on the ops/production side of things really is a little lacking. I'm super glad that business like Conspire are giving back to the community like this - your 5 part blog series has been absolutely invaluable to us. Thanks again, Ryan, Kane On Wednesday, 7 January 2015 02:39:57 UTC+11, Ryan Tanner wrote: We're also deploying an Akka cluster on CoreOS with Docker. We deploy the same fat JAR for every node (in fact, the exact same docker image) and then change their behavior by setting the role via environment variables. In our case, each role has a bootstrap class which sets up whatever role-specific actors might be needed (but *not* the worker actors) as well as the actors needed on every node. Cluster-aware routers running on our supervisor node are responsible for actually creating the worker actors as needed. We still split each role into sub-projects in our SBT project. We then have an SBT project within that called node which aggregates all of the service-specific sub-projects into a single JAR and builds the Docker image using sbt-docker. This way, we can iterate quickly on code within a specific service and keep our compile/test times down. That node project also houses our multi-JVM end-to-end tests. Then, opposite that, is our commons project which every other project depends on. The service projects explicitly do *not* depend on each other, only commons. This keeps us from getting them too coupled. Since our service isn't directly user-facing, we don't bother trying to upgrade a single service at a time, we just restart the whole thing and let it pull down the new Docker image if needed. Most of this is written up on our blog: http://blog.conspire.com/post/64130417462/akka-at-conspire-part-1-how-we-built-our-backend-on I've been meaning to write about our transition from Chef/Vagrant to CoreOS/Docker but I haven't found the time yet. Hopefully within the next few weeks (which, of course, I said a month ago). On Sunday, January 4, 2015 6:42:21 PM UTC-7, Kane Rogers wrote: Hi, hAkkers! We're in the process of moving our distributed Akka service from the dark ages of remoting and manual management of IPs (shudder) into the wonderful new world of Akka Cluster. Currently, our project is split up something like this: - spray-frontend - worker-1 - worker-2 - worker-3 Where the spray-frontend forwards messages to the different worker, depending on the type of job. In our current environment, each of these projects are deployed as individual fat JARs using sbt-assembly, and deployed onto individual nodes. In our planned environment, we'll be deploying these fat JARs into docker containers and allow CoreOS to take care of distributing the nodes. We're toying with things like roles, ClusterPoolRouter and ClusterGroupRouter to take care of distributing work amongst the correct node - but nothing is set in stone yet. This then begs the question - how should these nodes be deployed? I can see a couple of possibilities: - Docker container with fat JAR per project (eg. spray-frontend container, worker-1 container etc. etc). - Docker container with fat JAR containing all projects (eg. one container containing code for spray-frontend AND worker-1 etc.). Role is then set via environment variable, or a different main class is fired off on startup. Exploring the different options, one limitation that I can see is that ClusterPoolRouter requires the class of the actor that's going to be remotely deployed to the cluster to be *present on the class path of the router. *That is, if our front-ends are to create a worker on a remote machine to handle a request, the class for that router must be in the JAR on the front-end machine. *Please correct me if I'm mistaken here.* The advantage we've found in splitting the project up into these different sub-projects is tests are a lot quicker, code is smaller, etc. etc. Upgrades are also then made easier, as only certain machines have to be upgraded/restarted if a component of the service is improved/fixed. We also have a shared project between the different services that contains the dialect (eg. the different case classes for message sent between services). This was a best practice that we read about when we first went down the Akka path a couple of years ago, but things may have changed since then!
Re: [akka-user] Using ssl and tls with akka 2.3.7
wow thank you so much Will for this Feedback. I already have a new version (https://gist.github.com/Alien2150/9468c871135fd94869a2) that can deal with multiple connections. I think i will embed your feedback and will come up with a new version. Meanwhile i am struggling with another issue: https://groups.google.com/forum/#!topic/akka-user/wjUy6g2NUOg Regards, Thomas On Wednesday, January 7, 2015 7:25:06 PM UTC+1, Will Sargent wrote: Hi Thomas, There's some things you should watch out for in your code: * If you want to use TLS 1.2, you should specify getInstance(TLSv1.2) specifically (JDK 1.7 defaults to TLS 1.0) * You should disable SSLv3 (at the very least) using setEnabledProtocols(). * You are better off initializing the SSLContext with null instead of new SecureRandom, and leave it up to JSSE itself. Also a couple of configuration points: * Since you are using SSLEngine in server mode, you should start the JVM with -Djdk.tls.rejectClientInitiatedRenegotiation=true to disable client renegotation. * You should also set -Djdk.tls.ephemeralDHKeySize=2048 to increase the hardcoded keysize internally. Finally, as Henry mentioned earlier, the code here doesn't do any server identity checks. If you're using HTTPS, then you should use HostnameChecker directly or set setEndpointIdentificationAlgorithm(HTTPS) directly -- otherwise, you may want to look at RFC 6125 for a generic server identity check. More here: http://tersesystems.com/2014/03/23/fixing-hostname-verification/ Hope that helps, Will. On Friday, December 19, 2014 8:56:39 AM UTC-8, Thomas Zimmer wrote: Hi, I also had this issue but thanks to some examples [ https://github.com/xbucchiotty/akka-stream-ssltlscipher/blob/master/src/test/scala/Test.scala] and of course the TLS Specs [ https://github.com/akka/akka/blob/62a20195af79c7b405303b5f97970c9ca7a6891a/akka-stream/src/test/scala/akka/stream/io/SslTlsFlowSpec.scala] i could create a small actor-application which is using reactive streams: https://gist.github.com/Alien2150/d0c74d99c19df59109ff You can simply run it with openssl s_client (Which I used during testing). Regards, Thomas On Saturday, December 13, 2014 10:42:01 AM UTC+1, Pavel Popov wrote: Big thanks!, it explained a lot. On Sat, Dec 13, 2014 at 11:01 AM, Roland Kuhn goo...@rkuhn.info wrote: Hi Pavel, an SSL engine can operate on any kind of byte stream, it is not tied to TCP per se. This is why we will offer it as a DSL element that you can plug anywhere into your pipeline. As to looking into the IO package: I am not certain that I would expect SSL to be in there given that SSL itself does not do IO, it is only an encryption protocol suite. Regards, Roland 12 dec 2014 kl. 16:36 skrev Pavel Popov pa...@blackopsdev.com: Thank you for reply. But I don't understand the reason: why it was moved to streams, instead of being a part of IO? But from user's perspective It will be predictable to find SSL listener inside IO package, not somewhere else... On Fri, Dec 12, 2014 at 4:00 PM, Björn Antonsson bjorn.a...@typesafe.com wrote: Hi Paul, SSL/TLS support in akka will be part of the akka streams work that is ongoing right now. The aim is to have it available by Q1 2015. B/ On 11 December 2014 at 15:36:36, pa...@blackopsdev.com ( pa...@blackopsdev.com) wrote: Hello, everyone! I'm using akka.io 2.3.7 and I don't see any SSL/TLS support there. As far as I understand it was removed (since 2.3.x). Is it correct? Why? Will come back? And... Is there a clean workaround? May be this topic was discussed before, but I didn't find an appropriate link. Thanks, Paul -- 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+...@googlegroups.com. To post to this group, send email to akka...@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Björn Antonsson Typesafe http://typesafe.com/ – Reactive Apps on the JVM twitter: @bantonsson http://twitter.com/#!/bantonsson -- 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+...@googlegroups.com. To post to this group, send email to akka...@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more
Re: [akka-user] Using ssl and tls with akka 2.3.7
Finally, as Henry mentioned earlier, the code here doesn't do any server identity checks. If you're using HTTPS, then you should use HostnameChecker directly or set setEndpointIdentificationAlgorithm(HTTPS) directly -- otherwise, you may want to look at RFC 6125 for a generic server identity check. More here: http://tersesystems.com/2014/03/23/fixing-hostname-verification/ Addendum: forgot to mention that server identity checks only really matter if you have SSLEngine operating as a client, rather than as a server, so it's not a requirement. Will Sargent Consultant, Professional Services Typesafe http://typesafe.com, the company behind Play Framework http://www.playframework.com, Akka http://akka.io and Scala http://www.scala-lang.org/ On Wed, Jan 7, 2015 at 10:25 AM, Will Sargent will.sarg...@typesafe.com wrote: Hi Thomas, There's some things you should watch out for in your code: * If you want to use TLS 1.2, you should specify getInstance(TLSv1.2) specifically (JDK 1.7 defaults to TLS 1.0) * You should disable SSLv3 (at the very least) using setEnabledProtocols(). * You are better off initializing the SSLContext with null instead of new SecureRandom, and leave it up to JSSE itself. Also a couple of configuration points: * Since you are using SSLEngine in server mode, you should start the JVM with -Djdk.tls.rejectClientInitiatedRenegotiation=true to disable client renegotation. * You should also set -Djdk.tls.ephemeralDHKeySize=2048 to increase the hardcoded keysize internally. Finally, as Henry mentioned earlier, the code here doesn't do any server identity checks. If you're using HTTPS, then you should use HostnameChecker directly or set setEndpointIdentificationAlgorithm(HTTPS) directly -- otherwise, you may want to look at RFC 6125 for a generic server identity check. More here: http://tersesystems.com/2014/03/23/fixing-hostname-verification/ Hope that helps, Will. On Friday, December 19, 2014 8:56:39 AM UTC-8, Thomas Zimmer wrote: Hi, I also had this issue but thanks to some examples [https://github.com/ xbucchiotty/akka-stream-ssltlscipher/blob/master/src/ test/scala/Test.scala] and of course the TLS Specs [ https://github.com/akka/akka/blob/62a20195af79c7b405303b5f97970c 9ca7a6891a/akka-stream/src/test/scala/akka/stream/io/SslTlsFlowSpec.scala] i could create a small actor-application which is using reactive streams: https://gist.github.com/Alien2150/d0c74d99c19df59109ff You can simply run it with openssl s_client (Which I used during testing). Regards, Thomas On Saturday, December 13, 2014 10:42:01 AM UTC+1, Pavel Popov wrote: Big thanks!, it explained a lot. On Sat, Dec 13, 2014 at 11:01 AM, Roland Kuhn goo...@rkuhn.info wrote: Hi Pavel, an SSL engine can operate on any kind of byte stream, it is not tied to TCP per se. This is why we will offer it as a DSL element that you can plug anywhere into your pipeline. As to looking into the IO package: I am not certain that I would expect SSL to be in there given that SSL itself does not do IO, it is only an encryption protocol suite. Regards, Roland 12 dec 2014 kl. 16:36 skrev Pavel Popov pa...@blackopsdev.com: Thank you for reply. But I don't understand the reason: why it was moved to streams, instead of being a part of IO? But from user's perspective It will be predictable to find SSL listener inside IO package, not somewhere else... On Fri, Dec 12, 2014 at 4:00 PM, Björn Antonsson bjorn.a...@typesafe.com wrote: Hi Paul, SSL/TLS support in akka will be part of the akka streams work that is ongoing right now. The aim is to have it available by Q1 2015. B/ On 11 December 2014 at 15:36:36, pa...@blackopsdev.com ( pa...@blackopsdev.com) wrote: Hello, everyone! I'm using akka.io 2.3.7 and I don't see any SSL/TLS support there. As far as I understand it was removed (since 2.3.x). Is it correct? Why? Will come back? And... Is there a clean workaround? May be this topic was discussed before, but I didn't find an appropriate link. Thanks, Paul -- 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+...@googlegroups.com. To post to this group, send email to akka...@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Björn Antonsson Typesafe http://typesafe.com/ – Reactive Apps on the JVM twitter: @bantonsson http://twitter.com/#!/bantonsson -- 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 ---
Re: [akka-user] Re: Should i each time create new actor or using one val reference?
If the UserLinksActor is stateless you can use a router pool
http://doc.akka.io/docs/akka/2.3.8/scala/routing.html#Pool instead of
creating a new one each time. Then you can easily control the level of
parallelism.
/Patrik
PS. Akka.system.actorOf inside a future callback inside an actor is scary,
because it will be broken if you change it to context.actorOf.
On Sat, Jan 3, 2015 at 7:40 PM, Paweł Kopiczko kopic...@gmail.com wrote:
Hi Paweł,
Creating new actor is cheap, but you will have to bother with destroying
it. Otherwise you will have a kind of memory leak.
Anyway you shouldn't block in actor's receive function. This can be easy
solved by using pipe pattern:
http://doc.akka.io/docs/akka/2.3.8/scala/actors.html#Ask__Send-And-Receive-Future
PS
This is my opinion, but I think you should consider using akka futures
instead of actors. Actors are usable only when you have well defined
hierarchy or you have to manage internal (and mutable) actor state. It
seems to me that both of those don't apply to your case.
Regards,
Paweł
On Saturday, January 3, 2015 12:24:57 AM UTC+1, Paweł Sadowski wrote:
Hi,
My code looks like
lazy val userLinksActor: ActorRef = Akka.system.actorOf(Props(new
UserLinksActor(articleReader)),userLinksActor)
def receive = {
case GetLinks(usersFuture) =
usersFuture.onComplete {
case Success(users: List[User]) = {
users.foreach(user =
//here should i use val userLinksActor or create each time new actor?
//each of this actor is calling ws, when i use val userLinksActor these
calls are synchronized, one after another. When i create new actor all
calls to //ws are asnyc
//I thought that i should use one reference to actor(val) and akka will
spawn new when needed and parallel calls
Akka.system.actorOf(Props(new UserLinksActor(articleReader))) !
GetUserLinks(user, originalSender))
}
}
}
I have another question here about akka, maybe someone can help
https://groups.google.com/forum/#!topic/play-framework/DrqNw-rA2Lo
--
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.
--
Patrik Nordwall
Typesafe http://typesafe.com/ - Reactive apps on the JVM
Twitter: @patriknw
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Customizing failure-zones in distributed publish subscribe
On Wed, Jan 7, 2015 at 6:32 AM, Muthukumaran Kothandaraman muthu.kmk2...@gmail.com wrote: Thanks Patrik. By failure-zones, I mean to assign different dispatchers to different combinations of topic + subscribers. For example, Subscriber A and Subscriber B both handle messages from topic C and hence there would be two subscribers - actor sub_a_topic_c and actor sub_b_topic_c (I choose a convention to name actors with the combination to distinguish different subscribers for same topic). In above example, I could assign different dispatchers - one each for two subscribers based on latencies of message-handling by subscribers, so that processing latencies by one actor does not affect the other for same topic. Is this approach fine in above context ? Sounds good. Of course the decision to separate dispatchers would be taken only after thorough measurement of latencies - Muthu On Tuesday, 6 January 2015 20:31:54 UTC+5:30, Patrik Nordwall wrote: Hi Muthu, On Mon, Jan 5, 2015 at 7:00 AM, Muthukumaran Kothandaraman muthu@gmail.com wrote: I have following requirements for designing a clusterwide messaging system 1. There can be many to many relationship between topics and subscribers. ie. one module (OSGi) in each cluster node can subscribe to more than one topic and each topic can be subscribed to by more than one module. So, I have created one subscriber actor per-module per-topic combination to avoid issues like head-of-line-blocking and to fairly distribute the processing across multiple actors 2. Subscriber actors likely to invoke some legacy code which may not be very finely tuned for latency and hence there could be different processing-latencies for the same message of same topic by different modules 3. Publish is invoked directly in the caller thread where message originates (ie. from within existing code which is not actor-based). Since 'tell' to mediator is non-blocking, I am assuming that this should be fine (pls correct me if I am making any wrong assumptions here) Yes, that is fine My topics-module combinations lead to upto max 100 actors running in each node of cluster. My thoughts on creating failure zone is now limited to only the subscribers part because I create only subscriber actors and publishing entirely happens in caller-thread. So, what are possible ways to create failure-zones a. topic-wise and b. topic+subscriber combinationwise (somehow, this appears to be a more complex part) What do you mean by failure-zones? What do you want to achieve or protect against? Regards, Patrik Any experiences and/or recommendations ? Thanks in advance - Muthu -- 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+...@googlegroups.com. To post to this group, send email to akka...@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Patrik Nordwall Typesafe http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw -- 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. -- Patrik Nordwall Typesafe http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Using ssl and tls with akka 2.3.7
Hi Thomas, There's some things you should watch out for in your code: * If you want to use TLS 1.2, you should specify getInstance(TLSv1.2) specifically (JDK 1.7 defaults to TLS 1.0) * You should disable SSLv3 (at the very least) using setEnabledProtocols(). * You are better off initializing the SSLContext with null instead of new SecureRandom, and leave it up to JSSE itself. Also a couple of configuration points: * Since you are using SSLEngine in server mode, you should start the JVM with -Djdk.tls.rejectClientInitiatedRenegotiation=true to disable client renegotation. * You should also set -Djdk.tls.ephemeralDHKeySize=2048 to increase the hardcoded keysize internally. Finally, as Henry mentioned earlier, the code here doesn't do any server identity checks. If you're using HTTPS, then you should use HostnameChecker directly or set setEndpointIdentificationAlgorithm(HTTPS) directly -- otherwise, you may want to look at RFC 6125 for a generic server identity check. More here: http://tersesystems.com/2014/03/23/fixing-hostname-verification/ Hope that helps, Will. On Friday, December 19, 2014 8:56:39 AM UTC-8, Thomas Zimmer wrote: Hi, I also had this issue but thanks to some examples [ https://github.com/xbucchiotty/akka-stream-ssltlscipher/blob/master/src/test/scala/Test.scala] and of course the TLS Specs [ https://github.com/akka/akka/blob/62a20195af79c7b405303b5f97970c9ca7a6891a/akka-stream/src/test/scala/akka/stream/io/SslTlsFlowSpec.scala] i could create a small actor-application which is using reactive streams: https://gist.github.com/Alien2150/d0c74d99c19df59109ff You can simply run it with openssl s_client (Which I used during testing). Regards, Thomas On Saturday, December 13, 2014 10:42:01 AM UTC+1, Pavel Popov wrote: Big thanks!, it explained a lot. On Sat, Dec 13, 2014 at 11:01 AM, Roland Kuhn goo...@rkuhn.info wrote: Hi Pavel, an SSL engine can operate on any kind of byte stream, it is not tied to TCP per se. This is why we will offer it as a DSL element that you can plug anywhere into your pipeline. As to looking into the IO package: I am not certain that I would expect SSL to be in there given that SSL itself does not do IO, it is only an encryption protocol suite. Regards, Roland 12 dec 2014 kl. 16:36 skrev Pavel Popov pa...@blackopsdev.com: Thank you for reply. But I don't understand the reason: why it was moved to streams, instead of being a part of IO? But from user's perspective It will be predictable to find SSL listener inside IO package, not somewhere else... On Fri, Dec 12, 2014 at 4:00 PM, Björn Antonsson bjorn.a...@typesafe.com wrote: Hi Paul, SSL/TLS support in akka will be part of the akka streams work that is ongoing right now. The aim is to have it available by Q1 2015. B/ On 11 December 2014 at 15:36:36, pa...@blackopsdev.com ( pa...@blackopsdev.com) wrote: Hello, everyone! I'm using akka.io 2.3.7 and I don't see any SSL/TLS support there. As far as I understand it was removed (since 2.3.x). Is it correct? Why? Will come back? And... Is there a clean workaround? May be this topic was discussed before, but I didn't find an appropriate link. Thanks, Paul -- 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+...@googlegroups.com. To post to this group, send email to akka...@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Björn Antonsson Typesafe http://typesafe.com/ – Reactive Apps on the JVM twitter: @bantonsson http://twitter.com/#!/bantonsson -- 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+...@googlegroups.com. To post to this group, send email to akka...@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com. To post to
[akka-user] TimeoutException when using tell on an ActorSelection if the target actor is created through AskSupport
Hello, I am experimenting with at-least-once-delivery in akka-persistence. My goal is to create a future-based service layer on top of an actor system by using AskSupport. The deliver method in AtLeastOnceDelivery expects an ActorPath as its message destination and delivers the message by using tell on an ActorSelection created from the ActorPath. Using tell on an ActorSelection always results in a TimeoutException in my unit tests if the target of the ActorSelection is a temporary actor created by AskSupport. I created a test-case on github that can be used to reproduce the problem: https://github.com/ferdinandhuebner/akka-asksupport-actorselection Here's a direkt link to the test-suite: https://github.com/ferdinandhuebner/akka-asksupport-actorselection/blob/master/src/test/scala/ActorSelectionVsAskSupportSuite.scala I tested with Java 1.8, 1.7 and akka 2.3.8, 2.3.7, 2.3.4 and 2.3.2, the result is always the same. Is this an expected behaviour of ActorSelection and temporary actors created through AskSupport? What I can tell from debugging the code: ActorSelection#deliverSelection doesn't seem to be able to resolve the temporary actor. After a few recursions it ends in a case that is commented with foreign ref and calls tell on an ActorRef [akka://test/temp] instead of [akka://test/temp/$a] I added another test-case with a proxy intermediary that receives the message from the AskSupport actor and sends it to the desired target. That code works fine. However, I want to avoid creating proxy actors. I don't think that I'm accidentally blocking somewhere in my test-code, since the test with the proxy actor runs fine. If anybody can share any hints or feedback, I would appreciate it. Thank you, Ferdinand -- 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] Not getting an OnComplete message for TCP Connection with Stream-M2 and Akka 2.3.7
Hi, i created a simple application (https://gist.github.com/Alien2150/9468c871135fd94869a2) to play around with the SSL-Stream. But as soon as my client has been closed I am seeing this log-message (without receiving any OnComplete messages): [INFO] [01/07/2015 14:12:53.549] [app-akka.actor.default-dispatcher-15] [akka:// app/system/IO-TCP/selectors/$a/1] Message [akka.io.Tcp$Abort$] from Actor[akka:/ /app/system/IO-TCP-STREAM/server-1-%2F0.0.0.0%3A16500/$a#-536894325] to Actor[ak ka://app/system/IO-TCP/selectors/$a/1#-1566861189] was not delivered. [1] dead l etters encountered. This logging can be turned off or adjusted with configuratio n settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'. I am not sure if this issue is related to: https://github.com/akka/akka/issues/16553 Regards, Thomas -- 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] Akka Cluster: consistent hashing with balancing?
Hello, I have a setup of 5 nodes running clustered using Akka Cluster (Akka 2.3.7) and I am using a consistent-hashing router to spread the load among all nodes. My consistent key is based on a String and I have verified that the number of actors creating in the cluster is almost evenly distributed. However, my problem is that for some particular keys there is around 3x more load than for the rest. This leads to have an unbalanced data processing cluster where some nodes are processing around 5000 messages per second and some others just 2000. Is there a way to distribute the actors in the cluster in a way that when a new actor for a new consistent hash key is created, the actor is created in the node that is processing less data? Thank you for your help, Hector. -- 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] akka-http-experimental: Using the spray DSL: how to complete a route with a Source[ByteString]?
Hi,
I know how to do this now using the new akka-http core API, but how would
it work using the spray-like DSL?
How can I complete an http get using a Future[Source[ByteString]]?
import akka.http.model._
import akka.http.server._
...
def route: Route =
path(get) {
get {
parameters('path, 'id ?) { (path, id) =
respondWithMediaType(`application/octet-stream`) {
complete {
val f: Future[Source[ByteString]] = ???
f.onComplete {
case Success(source) = ...
case Failure(ex) = ...
}
}
}
}
}
}
I would also be interested in an example going the other way: implementing
an http post that receives data from a stream.
Thanks,
Allan
--
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.
