[akka-user] Re: AKKA Cluster split brain and reconnect

2015-09-14 Thread Dennis Jönsson
Thank you for your help Morten, I am afraid we cannot use your solution in 
our project though.

I have party solved the issue by removing auto-down from the configuration 
and only allowing the cluster singleton to down members and members that 
notice quarantine when they reconnect will restart their actorsystems. 
However this causes a problem when the cluster singleton or acting master 
is the one who goes down or is separated from the cluster, now noone can 
down this node and no new singleton will start so the whole cluster is put 
in stasis. 

Anyone got any clever solution to this problem?

Best Regards

/Dennis

Den onsdag 9 september 2015 kl. 09:29:53 UTC+2 skrev Dennis Jönsson:
>
> Hello!
>
> I am in the final stages of using Akka as our clustering solution, now I 
> have noticed that when one member of the cluster looses connection and 
> forms its own separate cluster it will not try to reconnect to the original 
> cluster when possible.
> Is there something I need to do manually, perhaps listen to events and 
> trigger reconnection attempts?
>
> Also I have been trying to tinker with configuration to avoid quarantining 
> a member that looses connection to the cluster, is there a good way to 
> avoid this so that this member can reconnect at all without restarting the 
> remote actor system?
>
> Best Regards
>
> /Dennis
>

-- 
>>  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] Mock actor based on actorSelection

2015-09-14 Thread Heiko Seeberger
Lookup generally is an anti-pattern and also in Akka – except for remoting and 
testing – there is absolutely no need to use lookup via `actorSelection`. 
Either inject the `ActorRef` to B in the constructor of A or send a message to 
A with the `ActorRef` to B.

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de 
Twitter: @hseeberger 
Public key: keybase.io/hseeberger 
> On 13 Sep 2015, at 23:23, Rafael Pacheco  wrote:
> 
> Today I posted this question on StackOverflow, maybe someone can help me.
> I have searched a lot about this and yet have no answer.
> 
> 
> 
> http://stackoverflow.com/questions/32551674/how-to-mock-a-actor-based-on-actorselection
> 
> 
> 
> I have a Actor "A" (user/A) that send message "X" for a other actor "B" 
> (user/B) when receive a message "M". To do this the actor A use 
> ActorSelection I need test that when I send M to A, B will receive "X".
> 
> 
> 
> I try this approachs:
> 
> 
> 
> * I used TestProbe and JavaTestKit on "user/B" but have not success.
> 
> * I also see some similar questions about this but every answer said to use 
> ActorRef insted of ActorSelection. This is not a option for me, I realy need 
> use a ActorSelection.
> 
> 
> 
> Someone have some idea ?
> 
> 
> -- 
> >> 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] Re: Akka HTTP authentication

2015-09-14 Thread Rahul Singhai
Hi,

I am trying to implement authentication mechanism in Akka HTTP (v1.0-M5).
Do you guys know if LDAP authentication directives are available?
Is HTTPBasicAuthentication only available right now?

Rahul 

On Sunday, 19 April 2015 13:52:17 UTC+1, Jason Bass wrote:
>
> Spray provided an authenticate directive that could be used for HTTP 
> authentication.  That directive appears to have been dropped in Akka HTTP 
> (I'm using v1.0-M5).  I'm curious whether the directive will find its way 
> into the final release or whether there is an alternate method to 
> facilitate authentication.  Thanks,
>
> Jason
>

-- 
>>  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] Re: reference.conf conflicts in fat jar (I think)

2015-09-14 Thread Konrad Malawski
Hi all,
I'd highly discourage fiddling with published artifacts (i.e. by unzipping and 
changing files in there).
You should use a plugin like https://github.com/sbt/sbt-assembl in which you 
configure all reference.conf files to be concatenated,
then your application.conf simply overwrites any settings you need.

-- 
Cheers,
Konrad `ktoso` Malawski
Akka @ Typesafe

On 13 September 2015 at 16:19:28, Raymond Guo (kknigh...@gmail.com) wrote:

Hi,
could you please tell me how to rename the file in the jars(actor and remote), 
I found out that I cant do that with my zip sofware, thank you!!

On Tuesday, February 7, 2012 at 5:41:33 AM UTC+8, Josh Marcus wrote:
Hey folks,

Thanks for sharing your approach -- hopefully we can collectively figure out a 
way to solve this problem cleanly, moving forward.

I opted for the maximally simple solution, for now.  I renamed the 
reference.conf files from akka-actor and akka-remote (the two I needed), copied 
them into my local project resources directory, and then included them directly 
in my own reference.conf. 

--j

On Sat, Feb 4, 2012 at 11:27 AM, cessationoftime  wrote:
"The project directory is another project inside your project which
knows how to build your project."  -- SBT wiki

when I initially set this up I found that these two projects, my sbt
Build (plugins.sbt) and my project itself (Build.scala) had 2
different sets of dependencies which are not shared.  So I had to
declare my dependencies in both places.  I didn't find a way to make
those two projects share dependencies, but I also did not try very
hard.

Chris

On Feb 4, 11:11 am, Zach Cox  wrote:
> I think the most sustainable solution would be to only declare Akka
> dependencies in one place as usual (build.sbt or Build.scala) and then
> anything that generates a fat reference.conf just uses those project
> dependency jars. DRY and such.
>
> On Sat, Feb 4, 2012 at 10:08 AM, cessationoftime
>
>
>
>
>
>
>
>  wrote:
> > They are declared in my Build.scala as dependencies too.    And
> > mentioned in proguardCfg.sbt so it knows what to remove reference.conf
> > files from.
>
> > I mention the version number of akka in so many config files with this
> > setup that I put a list of locations that need to be changed in my
> > Build.scala.  So if anyone has a good idea where one should declare
> > the akka version in an easy-to-update location where both Build.scala
> > and plugins.sbt, and proguardCfg.sbt can get at it, I'd love to hear
> > about it.  Though thinking about it now it would probably be optimal
> > to read it out of my akka  .conf files since it is there too.  Then I
> > could update the version in common.conf and not need to update
> > Build.scala, plugins.sbt and proguardCfg.sbt too.
>
> > On Feb 4, 10:48 am, Zach Cox  wrote:
> >> Chris - thanks for describing your solution & posting code! Is
> >> plugins.sbt the only place you declare those Akka dependencies? Or are
> >> they duplicated in another build.sbt or Build.scala file?
>
> >> On Sat, Feb 4, 2012 at 8:58 AM, Chris Van Vranken
>
> >>  wrote:
> >> >> After sinking 2 days into this, I have reached the conclusion that 1)
> >> >> the sbt assembly plugin, in its current state, is incapable of
> >> >> including a generated fat reference.conf file in the fat jar, and 2)
> >> >> sbt may not even be capable of generating that fat reference.conf
> >> >> using the jars in the project's dependencies.
>
> >> >> I would love more than anything for someone to prove me wrong by
> >> >> posting code samples to the mailing list. :) #hinthint
>
> >> > Here to prove you wrong. (At least on point #2)
>
> >> > I am not familiar with the assembly plugin, but I have this working 
> >> > using a
> >> > modified version of the proguard plugin.
> >> >https://github.com/cessationoftime/xsbt-proguard-plugin
> >> > I want to do a little more work on it before I do a pull request to
> >> > siasia/xsbt-proguard-plugin. The config isn't as pretty as it could be, I
> >> > want to split up my Tuple Injar\Outjar filter setting.  But it works 
> >> > well.
>
> >> > I feel the best solution would ultimately be a fork of the proguard 
> >> > plugin
> >> > which handles akka config issues.  Or a plugin that simply uses the
> >> > sbt-proguard-plugin as a dependency and handles akka config issues.
>
> >> > The config works like this:
>
> >> > plugins.sbt:
> >> > list the akka JARs which contain reference.conf files so that they may be
> >> > merged at compile time
>
> >> > Commands.scala:
> >> > implements finding and merging of the reference.conf files at compile 
> >> > time.
> >> > Also strips comments from the .conf files.
> >> > All reference.conf files merge with myapp.conf and common.conf and become
> >> > application.conf. But I ONLY merge in the "node" configuration of 
> >> > myapp.conf
>
> >> > Build.scala :  (resourceGenerators in Compile <+=
> >> > Commands.AkkaConfig.akkaMergedRefConfigKey)
> >> > this causes me to generate the merged akka config file when I com

[akka-user] [akka-http] No response is returned when the request payload exceeds the configured max-content-length

2015-09-14 Thread birynk
Hi, 

We are using akka-http 1.0 to implement our REST API and would like to set 
a limit to the max body size the user can send over REST. We have 
configured it in the akka http configuration as 10MB as following:

  http {

server {
 ...
  parsing {
max-content-length = 10m
  }
}
 }

The problem is that the client never receives a response from the server 
and remains blocked waiting for a response. Nevertheless the following will 
be logged by the ActorSystem:  

WARN  a.a.ActorSystemImpl akka.actor.ActorSystemImpl(TheSystemActorName) - 
Illegal request, responding with status '413 Request Entity Too Large': 
Request Content-Length 10485761 exceeds the configured limit of 10485760

Is there a way to retrieve the 413 status code back to the client or to 
catch this exception and explicitly set the status code in the request 
context?

Thx.

-- 
>>  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 2.4, how to access the journal ActorRef?

2015-09-14 Thread Brice Figureau
On Fri, 2015-09-11 at 11:02 +0200, Brice Figureau wrote:
> Hi all,
> 
> In previous Akka (2.3 or the 2.4-Mx), we could call
> 
> Persistence(system).journalFor()
> and
> Persistence(system).snapshotFor()
> 
> to get back the various ActorRef.
> 
> Admittely it wasn't very useful in a normal scenario, but when testing
> it allowed to 'mock' the journals and control the journal outside of
> Akka.
> 
> For instance, I have an in-memory journal and snapshot store that I use
> for integration tests. I can then in the test ask those actors for what
> they were asked to persist to check that the correct things were
> persisted. I can also flush the journal content between each tests.
> 
> I couldn't find a way to get back the ActorRef for the journals/snapshot
> stores, since those methods are now private to Akka.
> 
> Is there a way I can do the same thing?

It turns out that Akka creates the journals just below `/system` (at
least now), so it is just a matter of identifying the
`/system/` actor selection and send my own message back to
my journal.

-- 
Brice Figureau 

-- 
>>  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 2.4, how to access the journal ActorRef?

2015-09-14 Thread Patrik Nordwall
It was made internal because user should not interact directly with
journal. Fore testing special cases you can create a accessor class in the
akka package, or write it in Java.

/Patrik

On Mon, Sep 14, 2015 at 3:49 PM, Brice Figureau 
wrote:

> On Fri, 2015-09-11 at 11:02 +0200, Brice Figureau wrote:
> > Hi all,
> >
> > In previous Akka (2.3 or the 2.4-Mx), we could call
> >
> > Persistence(system).journalFor()
> > and
> > Persistence(system).snapshotFor()
> >
> > to get back the various ActorRef.
> >
> > Admittely it wasn't very useful in a normal scenario, but when testing
> > it allowed to 'mock' the journals and control the journal outside of
> > Akka.
> >
> > For instance, I have an in-memory journal and snapshot store that I use
> > for integration tests. I can then in the test ask those actors for what
> > they were asked to persist to check that the correct things were
> > persisted. I can also flush the journal content between each tests.
> >
> > I couldn't find a way to get back the ActorRef for the journals/snapshot
> > stores, since those methods are now private to Akka.
> >
> > Is there a way I can do the same thing?
>
> It turns out that Akka creates the journals just below `/system` (at
> least now), so it is just a matter of identifying the
> `/system/` actor selection and send my own message back to
> my journal.
>
> --
> Brice Figureau 
>
> --
> >>  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  -  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] Re: AKKA Cluster split brain and reconnect

2015-09-14 Thread Konrad Malawski
Hi guys,

The tools linked by Morten seem interesting, I'll give them a read later :)

I have party solved the issue by removing auto-down from the configuration 
Good, it's not a good idea to rely on auto-downing (as it's pretty naive and 
1-by-1 timer based) in production.

We recommend using explicit Cluster.down() commands fed by external monitoring 
solutions, or ops which have an overview on the cluster "from the outside" and 
can make the right decision to down and kill specific nodes. In general 
deciding this automatically is always risky in some form (due to the nature of 
any distributed application – you never know if a node is "slow" or "really 
down").

and only allowing the cluster singleton to down members and members that notice 
quarantine when they reconnect will restart their actorsystems. However this 
causes a problem when the cluster singleton or acting master is the one who 
goes down or is separated from the cluster, now noone can down this node and no 
new singleton will start so the whole cluster is put in stasis. 
Correct, however at least it is then consistent – no split-brain can happen in 
an Akka cluster without automatic downing.

You could call Cluster.down(someNodesAddress) to mark nodes down, and cause the 
singletons to kick in migration manually.



Anyone got any clever solution to this problem?
We do actually - the Split Brain Resolver.

It's part of the Reactive Platform and implements a number of strategies on how 
downing can be performed more safely than just timeouts (auto-downing). The 
strategies are for example "static quorum" or "keep majority" etc. Each of them 
has specific trade-offs, i.e. scenarios where they work well, and failure 
scenarios where the strategy would make a decision consistent with how it's 
working, but maybe not what you need. 

The docs are available here: 
http://doc.akka.io/docs/akka/rp-15v09p01/scala/split-brain-resolver.html and go 
pretty in-depth about how it all works.

In order to use this in production you'll need to obtain a Reactive Platform 
subscription, more details here: 
http://www.typesafe.com/products/typesafe-reactive-platform (it also explains 
on the bottom how you can try it out).

I also did a webinar 2 weeks ago about new features in Akka 2.4 and Reactive 
Platform where I also covered the Split Brain Resolver a bit: 
https://youtu.be/D3mPl8OUrjs?t=9m11s The entire webinar should be pretty 
interesting I hope, though I've marked the 9 minute mark where it's mostly 
about the Resolver.



You can contact us here to get specific details on the subscription: 
https://www.typesafe.com/company/contact

Hope this helps!



-- 
Cheers,
Konrad `ktoso` Malawski
Akka @ 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.


Re: [akka-user] Unit testing Akka-http low level API

2015-09-14 Thread Konrad Malawski
Hi Val,
notice that the high-level API has it's own routing DSL etc, which makes it 
need a nice testing abstraction.

The low-level API on the other hand is plain Akka Streams, i.e. Flow / Source / 
Sink of HttpRequest and HttpResponse.
This means that the TestKit for it is, in fact, the same as for Akka Streams! 

Here are the docs: 
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0/scala/stream-testkit.html

We should document this assumption more explicitly I think (I'll do that - 
here's the ticket https://github.com/akka/akka/issues/18469 ).


Hope this helps!
-- 
Cheers,
Konrad `ktoso` Malawski
Akka @ Typesafe

On 11 September 2015 at 05:20:11, Val P (injvst...@gmail.com) wrote:

Hi,

Can the akka-http 1.0 low level api be tested using Akka-http-testkit?
So far, It appears only the high level api (using the routing dsl) can be 
tested?

Could someone be kind enough to point me or show me how to write unit tests for 
the low level API?





--
>> 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.


Re: [akka-user] How to live without ask()?

2015-09-14 Thread Justin du coeur
On Sat, Sep 12, 2015 at 8:15 PM, kraythe  wrote:

> Because they rely on waiting some amount of time for something to come
> back from elsewhere and that means that you tie up the actor while you are
> waiting.
>

I think others have covered this reasonably well, but this is the crux of
the confusion: ask() and Future specifically do *not* block unless you're
misusing them.  Indeed, that's the whole point of the ask() approach.
Basically, so long as you avoid Await (which is almost always dangerous),
they scale very well.  I think you've gotten some misinformation from
somewhere.  (If you happen to recall where, a link would be helpful so
folks can make a correction...)

-- 
>>  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] Where did Spray's anyParams go?

2015-09-14 Thread Konrad Malawski
Hi Matthew,
it's one of the few directives we were pondering if we need to port then or
not as it was considered rather rarely used, here's the ticket:
https://github.com/akka/akka/issues/15934
In Spray it had a bug which was fixed only recently, so we'll need to
forward port the fix as well: https://github.com/spray/spray/issues/981

Do you have strong feelings towards having it forward-ported, i.e. an
example use case where it indeed is very useful?

On Wed, Sep 9, 2015 at 12:35 AM, Matthew Adams 
wrote:

> I see formFields & parameters, but nothing that gets them from wherever.
> Missing by design?
>
> -matthew
>
> --
> >> 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,
Konrad 'ktoso' Malawski
Akka  @ 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-http] One-per-thread thingy for RabbitMQ producer channels

2015-09-14 Thread tigerfoot
Hello...

I'm reading through the RabbitMQ docs and it says they recommend having one 
channel per thread to avoid concurrency issues.
My question is:  Where in the the Scala DSL for akka-http would I create a 
Channel object that would be accessible inside the routing directives?

I suppose I could create/use/destroy channels on each request inside the 
route directive but that seems like a bad approach.

There are some good articles on using Akka streams and RabbitMQ on the 
consumer side of the queue but I'm focused on the producer side, namely the 
ability to push lots and lots of messages into the queue as fast as my 
RESTful service can handle.

Thanks,
Greg

-- 
>>  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-http] One-per-thread thingy for RabbitMQ producer channels

2015-09-14 Thread tigerfoot
Would this work?  In the code below would I get one channel/thread?  Is 
there one route instance per thread under the covers of Akka HTTP?

val connection = ... // create connection out here

val routes = {

val channel = connection.createChannel()

path("v1" / "hello") {

  get {

complete {

  channel.basicPublish(...)

  s"Say hello to akka-http"

}

  }

}

  }


Http().bindAndHandle(routes, config.getString("http.interface"), 
config.getInt("http.port"))

-- 
>>  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] Where did Spray's anyParams go?

2015-09-14 Thread Matthew Adams
Not in production code.  Only demoware.  Port forward as resources allow.

On Mon, Sep 14, 2015 at 6:05 PM, Konrad Malawski  wrote:

> Hi Matthew,
> it's one of the few directives we were pondering if we need to port then
> or not as it was considered rather rarely used, here's the ticket:
> https://github.com/akka/akka/issues/15934
> In Spray it had a bug which was fixed only recently, so we'll need to
> forward port the fix as well: https://github.com/spray/spray/issues/981
>
> Do you have strong feelings towards having it forward-ported, i.e. an
> example use case where it indeed is very useful?
>
> On Wed, Sep 9, 2015 at 12:35 AM, Matthew Adams 
> wrote:
>
>> I see formFields & parameters, but nothing that gets them from wherever.
>> Missing by design?
>>
>> -matthew
>>
>> --
>> >> 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,
> Konrad 'ktoso' Malawski
> Akka
> 
>  @ 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 a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/-sbaRZmcyZ8/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.
>



-- 
mailto:matt...@matthewadams.me 
skype:matthewadams12
googletalk:matt...@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams

-- 
>>  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] Re: AKKA Cluster split brain and reconnect

2015-09-14 Thread Dennis Jönsson
Thank you for this information Konrad I will be looking at this in detail 
today :)

In fact I had an implementation of Keep Majority that worked yesterday but 
we met some more problems. It may be that we need some not normal behavior 
here, after some discussions we came to the conclusion that we dont want to 
prevent another singleton being created in a split clustergroup. This is 
because our singleton is the consumer of messages and we want the split 
cluster to be able to continue working until we can merge again. We dont 
have any persistance or the like so that should not be a problem right?

However, if we create two separate clusters like this, they wont try to 
reconnect later, is it possible to force heartbeats to specific addresses? 
Then we could down one of the clusters and have them rejoin when they are 
able to find each other again.



Den måndag 14 september 2015 kl. 17:24:20 UTC+2 skrev Konrad Malawski:
>
> Hi guys,
>
> The tools linked by Morten seem interesting, I'll give them a read later :)
>
> I have party solved the issue by removing auto-down from the configuration
>  
>
> Good, it's not a good idea to rely on auto-downing (as it's pretty naive 
> and 1-by-1 timer based) in production.
>
> We recommend using explicit Cluster.down() commands fed by external 
> monitoring solutions, or ops which have an overview on the cluster "from 
> the outside" and can make the right decision to down and kill specific 
> nodes. In general deciding this automatically is always risky in some form 
> (due to the nature of any distributed application – you never know if a 
> node is "slow" or "really down").
>
> and only allowing the cluster singleton to down members and members that 
> notice quarantine when they reconnect will restart their actorsystems. 
> However this causes a problem when the cluster singleton or acting master 
> is the one who goes down or is separated from the cluster, now noone can 
> down this node and no new singleton will start so the whole cluster is put 
> in stasis. 
>
> Correct, however at least it is then consistent – no split-brain can 
> happen in an Akka cluster *without* automatic downing.
>
> You could call Cluster.down(someNodesAddress) to mark nodes down, and 
> cause the singletons to kick in migration manually.
>
>
> Anyone got any clever solution to this problem?
>
> We do actually - the Split Brain Resolver.
>
> It's part of the Reactive Platform and implements a number of strategies 
> on how downing can be performed more safely than just timeouts 
> (auto-downing). The strategies are for example "static quorum" or "keep 
> majority" etc. Each of them has specific trade-offs, i.e. scenarios where 
> they work well, and failure scenarios where the strategy would make a 
> decision consistent with how it's working, but maybe not what you need. 
>
> The docs are available here: 
> http://doc.akka.io/docs/akka/rp-15v09p01/scala/split-brain-resolver.html and 
> go pretty in-depth about how it all works.
>
> In order to use this in production you'll need to obtain a Reactive 
> Platform subscription, more details here: 
> http://www.typesafe.com/products/typesafe-reactive-platform (it also 
> explains on the bottom how you can try it out).
>
> I also did a webinar 2 weeks ago about new features in Akka 2.4 and 
> Reactive Platform where I also covered the Split Brain Resolver a bit: 
> https://youtu.be/D3mPl8OUrjs?t=9m11s The entire webinar should be pretty 
> interesting I hope, though I've marked the 9 minute mark where it's mostly 
> about the Resolver.
>
>
> You can contact us here to get specific details on the subscription: 
> https://www.typesafe.com/company/contact
>
> Hope this helps!
>
>
> -- 
> Cheers,
> Konrad `ktoso` Malawski
> Akka  @ 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.