Re: [akka-user] akka-http HttpService equivalent
Hi, Thanks for the hint, Björn. I've been pursuing the idea and used japi.HttpApp, but ended up with the following compilation error: [error] found : akka.http.server.scala.Route [error] (which expands to) akka.http.server.RequestContext = scala. concurrent.Future[akka.http.server.RouteResult] [error] required: akka.http.server.japi.Route Before going any further, I'd love figuring out what's the intent of the japi package and how the seemingly alike types - scala.Route and japi.Route - compare. Where should they be used? Jacek On Wednesday, December 10, 2014 2:54:16 PM UTC+1, Björn Antonsson wrote: Hi Stevo, There is no direct equivalent to the spray.routing.HttpService. The closest is probably the akka.http.server.japi.HttpService and akka.http.server.japi.HttpApp. B/ On 9 December 2014 at 16:04:57, Stevo Slavić (ssl...@gmail.com javascript:) wrote: Hello Akka community, In akka-http, is there an equivalent to spray.routing.HttpService? Kind regards, Stevo Slavic. -- 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 javascript:. To post to this group, send email to akka...@googlegroups.com javascript:. 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+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] akka-http HttpService equivalent
Hi, It appears to be first step of Java routing API [1] with just a single commit (perhaps squashed earlier to make it look so). What's Java routing API? How is this different from Scala's one if any? [1] https://github.com/akka/akka/commits/release-2.3-dev/akka-http-java/src/main/scala/akka/http/server/japi/HttpApp.scala Jacek On Sunday, January 4, 2015 1:34:56 PM UTC+1, Jacek Laskowski wrote: Hi, Thanks for the hint, Björn. I've been pursuing the idea and used japi.HttpApp, but ended up with the following compilation error: [error] found : akka.http.server.scala.Route [error] (which expands to) akka.http.server.RequestContext = scala. concurrent.Future[akka.http.server.RouteResult] [error] required: akka.http.server.japi.Route Before going any further, I'd love figuring out what's the intent of the japi package and how the seemingly alike types - scala.Route and japi.Route - compare. Where should they be used? Jacek On Wednesday, December 10, 2014 2:54:16 PM UTC+1, Björn Antonsson wrote: Hi Stevo, There is no direct equivalent to the spray.routing.HttpService. The closest is probably the akka.http.server.japi.HttpService and akka.http.server.japi.HttpApp. B/ On 9 December 2014 at 16:04:57, Stevo Slavić (ssl...@gmail.com) wrote: Hello Akka community, In akka-http, is there an equivalent to spray.routing.HttpService? Kind regards, Stevo Slavic. -- 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+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] akka-http HttpService equivalent
Hi Jacek, As the name implies, japi is the java api, you’re not meant to be using those if you’re using Scala - just use the normal scala APIs. The Scala Routing DSL cannot be reused directly by Java since it’s using all kinds of Scala types which simlpy do not look as nice in Java. Akka HTTP (and Akka in general) aims to provide both languages with equally awesome DSLs, thus if things do not look great in Java, they may require a separate DSL which in turn can Java-native types everywhere etc. to make it feel “right” for a Java developer. For example Akka Streams also has two separate DSLs. This is in order to maximise the user’s happieness when working with it from either Java or Scala, we simply can apply “what a Scala/Java developer would expect here” and provide the best possible DSL for each. The Java Routing DSL is in the works, some tests are here: https://github.com/akka/akka/blob/release-2.3-dev/akka-http-java8-tests/src/test/java/akka/http/server/japi/HandlerBindingTest.java It’s looks a bit different than the Scala one, which is because Java is not Scala and we’re unable to apply all the tricks we can apply in Scala Land for the Java DSL. Please note that this is a major improvement over spray, since it never had a Java DSL – with Akka HTTP even Java users will be able to use it :-) Cheers, -- Konrad 'ktoso' Malawski hAkker @ typesafe http://akka.io On 4 January 2015 at 14:08:16, Jacek Laskowski (jacek.japila...@gmail.com) wrote: Hi, It appears to be first step of Java routing API [1] with just a single commit (perhaps squashed earlier to make it look so). What's Java routing API? How is this different from Scala's one if any? [1] https://github.com/akka/akka/commits/release-2.3-dev/akka-http-java/src/main/scala/akka/http/server/japi/HttpApp.scala Jacek On Sunday, January 4, 2015 1:34:56 PM UTC+1, Jacek Laskowski wrote: Hi, Thanks for the hint, Björn. I've been pursuing the idea and used japi.HttpApp, but ended up with the following compilation error: [error] found : akka.http.server.scala.Route [error] (which expands to) akka.http.server.RequestContext = scala.concurrent.Future[akka.http.server.RouteResult] [error] required: akka.http.server.japi.Route Before going any further, I'd love figuring out what's the intent of the japi package and how the seemingly alike types - scala.Route and japi.Route - compare. Where should they be used? Jacek On Wednesday, December 10, 2014 2:54:16 PM UTC+1, Björn Antonsson wrote: Hi Stevo, There is no direct equivalent to the spray.routing.HttpService. The closest is probably the akka.http.server.japi.HttpService and akka.http.server.japi.HttpApp. B/ On 9 December 2014 at 16:04:57, Stevo Slavić (ssl...@gmail.com) wrote: Hello Akka community, In akka-http, is there an equivalent to spray.routing.HttpService? Kind regards, Stevo Slavic. -- 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 – Reactive Apps on the JVM twitter: @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+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. -- 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] Reproducing akka.remote.OversizedPayloadException locally
A few days ago I stumbled across *akka.remote.OversizedPayloadException*. Successfully I found the solution in this user list: the problem was in *akka.remote.netty.tcp.maximum-frame-size* config parameter which is set to128000 bytes by default. My question is how can I reproduce this exception locally, because I tried to send messages with size exceeding this value in the tests but didn't get this exception, only when messages are passing between application instances(seperate JVMs). Also another question is about *akka.remote.netty.tcp.**receive-buffer-size *and *akka.remote.netty.tcp.**send-buffer-size. *Do they have to correlate with *maximum-frame-size *as in default config? What are the consequences if they don't correlate? Thanks in advance! -- 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] /me still away tomorrow
Hey guys, Hope you had a great break :-) Just a quick note in case you're not sure if/when I'm around. I'm back in PL already but off work until the 6th (as the 6th is a public holiday in poland http://www.kalendarzswiat.pl/lista_swiat/2015). I'm arranging some family stuffs over these days, but in case we want to do some whole-team-planning I can pop in during the day (can't make it for the stand up though). In general excited to get back to hakking! Cya soon! :-) -- Cheers, Konrad 'ktoso' Malawski hAkker @ Typesafe -- 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 Project - Monolithic JAR or JARs per service?
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 general advice would be really appreciated! Thanks and kind regards, Kane -- 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] Customizing failure-zones in distributed publish subscribe
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) 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) 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+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.
