[akka-user] [akka-http] Configuring HTTPS with a trusted certificate chain

[Julian Michael]

Hi akka-user,

I'm trying to host a simple server that uses HTTPS. I'm having exactly the 
same problem as pointed out in this issue 
,
where Chrome responds with ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
It worked when I used a self-signed certificate (while Chrome complained 
that the cert wasn't trusted, I could go through and view the page),
but now that I'm using a proper trusted certificate chain it's not working.
This leads me to think there's something wrong with my keystore, but I 
don't know where to start in diagnosing that.

Adding the -Djavax.net.debug=all flag to my build.sbt didn't cause anything 
to be printed,
but I tried openssl s_client -connect : and the output was as 
follows.

CONNECTED(0003)

140735126758224:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 
alert handshake failure:s23_clnt.c:769:

---

no peer certificate available

---

No client certificate CA names sent

---

SSL handshake has read 7 bytes and written 308 bytes

---

New, (NONE), Cipher is (NONE)

Secure Renegotiation IS NOT supported

Compression: NONE

Expansion: NONE

No ALPN negotiated

SSL-Session:

Protocol  : TLSv1.2

Cipher: 

Session-ID: 

Session-ID-ctx: 

Master-Key: 

Key-Arg   : None

PSK identity: None

PSK identity hint: None

SRP username: None

Start Time: 1478765759

Timeout   : 300 (sec)

Verify return code: 0 (ok)

---


I don't know much about web protocols and don't really understand this 
output.

Any idea what the problem might be and how I can fix it?


Thank you!

Julian

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka-remote docker<->docker works fine with netty.tcp, but fails with artery - ideas?

[johan . kjolhede . bonniernews]

One additional piece of info that could be useful:

It works if I let the docker containers call each other by container IP 
instead of host IP+fowarding.




Den onsdag 9 november 2016 kl. 19:29:44 UTC+1 skrev Akka Team:
>
> Ah, sorry, didn't notice it in the command line.
>
> Can you verify with some other tool that you can communicate using udp 
> between the nodes? (using netcat for example)
>
> Set logs to debug to see if there is anything helpful in there.
> Additionally artery contains a "flight recorder" which you can enable 
> using the setting akka.remote.artery.advanced.flight-recorder.enabled, it 
> will write artery related events to a binary logfile, which you can then 
> feed to akka.remote.artery.FlightRecorderDump in akka-remote to get human 
> readable output, it may also contain some hints about what/why/how it is 
> not working.
>
> --
> Johan
> Akka Team
>
> On Wed, Nov 9, 2016 at 7:14 PM, > 
> wrote:
>
>> Yes - i Did. Please see my original post for details. You will see that I 
>> use the udp parameter for my docker port forwarding. Also please note that 
>> I've tested artery successfully in docker as long as one of the 
>> applications is running outside docker. However the problem occurs only 
>> when both producer and consumer run in containers. See the test results 
>> table and error log in my previous message for more details.
>>
>> /Johan
>>
>> --
>> >>  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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Akka-remoting with Artery using load balancing/round robbing dns

[johan . kjolhede . bonniernews]

Case:

I have two services (A and B) that wish to talk to each other using 
akka-remoting over artery.
Each service executes on it's own machine behind a load balancer mapping a 
dns name, e.g. $A resolving -> multiple IP addresses.

For A to talk to B, we can for example execute:

// Make request from an A to a B
val b = context.actorSelection(s
"akka://$systemName@$B:$port/user/$actorName")
b ! Request()

where $B is the load balanced address that is resolved to a B instance 
(maybe B1, maybe B2.. etc)

In order for B to receive this message, B would need to have an akka conf 
with canonical.hostname = $B. Otherwise artery will filter out these 
messages...

So far, this works. However, now let's say this is bidirectional 
communication. 
B wants to reply to A's requests, but also, B wants to send its own 
independent requests to A and expect A to reply back to B.

B would then have something like the following code
// Reply from B back to A
def receive {
  case  Request() => sender() ! Reply()
}

But because A has canonical.hostname set to $A, which is a load balanced 
address, the reply could end up at A1, A2 or any Ai for that matter.

To work around this, all I can think of is to let each actor resolution 
actually do a manual dns lookup before calling context.actorSelection.. and 
write the explicit resolved address of each actor to their own akka conf.
*Is this conclusion correct?*

I suspect akka.tcp does not have this problem as sender() would just re-use 
the existing tcp connection, but artery being build on udp, will suffer 
from the problem above.
Am I missing something? :)

/ Johan

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka-remote docker<->docker works fine with netty.tcp, but fails with artery - ideas?

[johan . kjolhede . bonniernews]

Another piece to the puzzle: 
docker <-> docker does work routed through the host as long as the 
containers run on different hosts.
It's only when doing docker <-> docker routed through host on the same host 
that it doesn't work.

Seems like an issue in the artery or aeron protocol.


Den onsdag 9 november 2016 kl. 19:29:44 UTC+1 skrev Akka Team:
>
> Ah, sorry, didn't notice it in the command line.
>
> Can you verify with some other tool that you can communicate using udp 
> between the nodes? (using netcat for example)
>
> Set logs to debug to see if there is anything helpful in there.
> Additionally artery contains a "flight recorder" which you can enable 
> using the setting akka.remote.artery.advanced.flight-recorder.enabled, it 
> will write artery related events to a binary logfile, which you can then 
> feed to akka.remote.artery.FlightRecorderDump in akka-remote to get human 
> readable output, it may also contain some hints about what/why/how it is 
> not working.
>
> --
> Johan
> Akka Team
>
> On Wed, Nov 9, 2016 at 7:14 PM, > 
> wrote:
>
>> Yes - i Did. Please see my original post for details. You will see that I 
>> use the udp parameter for my docker port forwarding. Also please note that 
>> I've tested artery successfully in docker as long as one of the 
>> applications is running outside docker. However the problem occurs only 
>> when both producer and consumer run in containers. See the test results 
>> table and error log in my previous message for more details.
>>
>> /Johan
>>
>> --
>> >>  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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Why default-plugin-dispatcher is PinnedDispatcher thread-pool-executor ?

[Yaroslav Klymko]

Hi guys, 

Just curious about reasoning to make `default-plugin-dispatcher` as 

default-plugin-dispatcher {
  type = PinnedDispatcher
  executor = "thread-pool-executor"
}

Why not a fork-join-executor ?

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka-remoting with Artery using load balancing/round robbing dns

[Viktor Klang]

the host needs to be a stable identifier.

What problem are you trying to solve with the rr dns?

On Thu, Nov 10, 2016 at 10:48 AM, 
wrote:

> Case:
>
> I have two services (A and B) that wish to talk to each other using
> akka-remoting over artery.
> Each service executes on it's own machine behind a load balancer mapping a
> dns name, e.g. $A resolving -> multiple IP addresses.
>
> For A to talk to B, we can for example execute:
>
> // Make request from an A to a B
> val b = context.actorSelection(s"akka://$systemName@$B:$port/user/$
> actorName")
> b ! Request()
>
> where $B is the load balanced address that is resolved to a B instance
> (maybe B1, maybe B2.. etc)
>
> In order for B to receive this message, B would need to have an akka conf
> with canonical.hostname = $B. Otherwise artery will filter out these
> messages...
>
> So far, this works. However, now let's say this is bidirectional
> communication.
> B wants to reply to A's requests, but also, B wants to send its own
> independent requests to A and expect A to reply back to B.
>
> B would then have something like the following code
> // Reply from B back to A
> def receive {
>   case  Request() => sender() ! Reply()
> }
>
> But because A has canonical.hostname set to $A, which is a load balanced
> address, the reply could end up at A1, A2 or any Ai for that matter.
>
> To work around this, all I can think of is to let each actor resolution
> actually do a manual dns lookup before calling context.actorSelection.. and
> write the explicit resolved address of each actor to their own akka conf.
> *Is this conclusion correct?*
>
> I suspect akka.tcp does not have this problem as sender() would just
> re-use the existing tcp connection, but artery being build on udp, will
> suffer from the problem above.
> Am I missing something? :)
>
> / Johan
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Why default-plugin-dispatcher is PinnedDispatcher thread-pool-executor ?

[Endre Varga]

Because there is no reason for a FJP executor. PinnedDispatcher dedicates a
thread to an actor, there is no sharing and hence no work stealing. FJP is
overkill in that case and makes no sense.

-Endre

On Thu, Nov 10, 2016 at 12:41 PM, Yaroslav Klymko  wrote:

> Hi guys,
>
> Just curious about reasoning to make `default-plugin-dispatcher` as
>
> default-plugin-dispatcher {
>   type = PinnedDispatcher
>   executor = "thread-pool-executor"
> }
>
> Why not a fork-join-executor ?
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Exposing Akka actors through a REST API

[Alvaro Santuy]

Hello everybody.

Is there any project out there capable to easily build REST routes to Akka 
Actors? I would like to map REST resources to Akka Actors and messages 
other than manually encode the routes in Akka HTTP...

Thank you.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: [akka-http] Configuring HTTPS with a trusted certificate chain

[johannes . rudolph]

Hi Julian,

can you post more information about your code and what happens exactly when 
you run it? What kind of key material do you have and how do you load it? 
Are you using akka-http on the client side or on the server side?

Johannes

On Thursday, November 10, 2016 at 9:50:08 AM UTC+1, Julian Michael wrote:
>
> Hi akka-user,
>
> I'm trying to host a simple server that uses HTTPS. I'm having exactly the 
> same problem as pointed out in this issue 
> ,
> where Chrome responds with ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
> It worked when I used a self-signed certificate (while Chrome complained 
> that the cert wasn't trusted, I could go through and view the page),
> but now that I'm using a proper trusted certificate chain it's not working.
> This leads me to think there's something wrong with my keystore, but I 
> don't know where to start in diagnosing that.
>
> Adding the -Djavax.net.debug=all flag to my build.sbt didn't cause 
> anything to be printed,
> but I tried openssl s_client -connect : and the output was 
> as follows.
>
> CONNECTED(0003)
>
> 140735126758224:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 
> alert handshake failure:s23_clnt.c:769:
>
> ---
>
> no peer certificate available
>
> ---
>
> No client certificate CA names sent
>
> ---
>
> SSL handshake has read 7 bytes and written 308 bytes
>
> ---
>
> New, (NONE), Cipher is (NONE)
>
> Secure Renegotiation IS NOT supported
>
> Compression: NONE
>
> Expansion: NONE
>
> No ALPN negotiated
>
> SSL-Session:
>
> Protocol  : TLSv1.2
>
> Cipher: 
>
> Session-ID: 
>
> Session-ID-ctx: 
>
> Master-Key: 
>
> Key-Arg   : None
>
> PSK identity: None
>
> PSK identity hint: None
>
> SRP username: None
>
> Start Time: 1478765759
>
> Timeout   : 300 (sec)
>
> Verify return code: 0 (ok)
>
> ---
>
>
> I don't know much about web protocols and don't really understand this 
> output.
>
> Any idea what the problem might be and how I can fix it?
>
>
> Thank you!
>
> Julian
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka-remoting with Artery using load balancing/round robbing dns

[johan . kjolhede . bonniernews]

Ok. Just wanted that confirmed. We already have a workaround for it so I 
was mostly just curious to see if it was needed :).

/ Johan



Den torsdag 10 november 2016 kl. 13:03:36 UTC+1 skrev √:
>
> the host needs to be a stable identifier.
>
> What problem are you trying to solve with the rr dns?
>
> On Thu, Nov 10, 2016 at 10:48 AM,  > wrote:
>
>> Case:
>>
>> I have two services (A and B) that wish to talk to each other using 
>> akka-remoting over artery.
>> Each service executes on it's own machine behind a load balancer mapping 
>> a dns name, e.g. $A resolving -> multiple IP addresses.
>>
>> For A to talk to B, we can for example execute:
>>
>> // Make request from an A to a B
>> val b = context.actorSelection(s
>> "akka://$systemName@$B:$port/user/$actorName")
>> b ! Request()
>>
>> where $B is the load balanced address that is resolved to a B instance 
>> (maybe B1, maybe B2.. etc)
>>
>> In order for B to receive this message, B would need to have an akka conf 
>> with canonical.hostname = $B. Otherwise artery will filter out these 
>> messages...
>>
>> So far, this works. However, now let's say this is bidirectional 
>> communication. 
>> B wants to reply to A's requests, but also, B wants to send its own 
>> independent requests to A and expect A to reply back to B.
>>
>> B would then have something like the following code
>> // Reply from B back to A
>> def receive {
>>   case  Request() => sender() ! Reply()
>> }
>>
>> But because A has canonical.hostname set to $A, which is a load balanced 
>> address, the reply could end up at A1, A2 or any Ai for that matter.
>>
>> To work around this, all I can think of is to let each actor resolution 
>> actually do a manual dns lookup before calling context.actorSelection.. and 
>> write the explicit resolved address of each actor to their own akka conf.
>> *Is this conclusion correct?*
>>
>> I suspect akka.tcp does not have this problem as sender() would just 
>> re-use the existing tcp connection, but artery being build on udp, will 
>> suffer from the problem above.
>> Am I missing something? :)
>>
>> / Johan
>>
>> -- 
>> >> 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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka-remoting with Artery using load balancing/round robbing dns

[Endre Varga]

Actor remote messaging is a P2P protocol and as such any kind of
name-remapping is harmful. Trying to load balance Akka Remote connections I
think is a mistake and makes not much sense. You *can* load balance Akka
provided services of course, but you need to expose them as a different
protocol (i.e. REST API, custom TCP endpoint, etc.).

On Thu, Nov 10, 2016 at 5:12 PM, 
wrote:

> Ok. Just wanted that confirmed. We already have a workaround for it so I
> was mostly just curious to see if it was needed :).
>
> / Johan
>
>
>
> Den torsdag 10 november 2016 kl. 13:03:36 UTC+1 skrev √:
>>
>> the host needs to be a stable identifier.
>>
>> What problem are you trying to solve with the rr dns?
>>
>> On Thu, Nov 10, 2016 at 10:48 AM,  wrote:
>>
>>> Case:
>>>
>>> I have two services (A and B) that wish to talk to each other using
>>> akka-remoting over artery.
>>> Each service executes on it's own machine behind a load balancer mapping
>>> a dns name, e.g. $A resolving -> multiple IP addresses.
>>>
>>> For A to talk to B, we can for example execute:
>>>
>>> // Make request from an A to a B
>>> val b = context.actorSelection(s"akka://$systemName@$B:$port/user/$a
>>> ctorName")
>>> b ! Request()
>>>
>>> where $B is the load balanced address that is resolved to a B instance
>>> (maybe B1, maybe B2.. etc)
>>>
>>> In order for B to receive this message, B would need to have an akka
>>> conf with canonical.hostname = $B. Otherwise artery will filter out these
>>> messages...
>>>
>>> So far, this works. However, now let's say this is bidirectional
>>> communication.
>>> B wants to reply to A's requests, but also, B wants to send its own
>>> independent requests to A and expect A to reply back to B.
>>>
>>> B would then have something like the following code
>>> // Reply from B back to A
>>> def receive {
>>>   case  Request() => sender() ! Reply()
>>> }
>>>
>>> But because A has canonical.hostname set to $A, which is a load balanced
>>> address, the reply could end up at A1, A2 or any Ai for that matter.
>>>
>>> To work around this, all I can think of is to let each actor resolution
>>> actually do a manual dns lookup before calling context.actorSelection.. and
>>> write the explicit resolved address of each actor to their own akka conf.
>>> *Is this conclusion correct?*
>>>
>>> I suspect akka.tcp does not have this problem as sender() would just
>>> re-use the existing tcp connection, but artery being build on udp, will
>>> suffer from the problem above.
>>> Am I missing something? :)
>>>
>>> / Johan
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >> Search the archives: https://groups.google.com/grou
>>> p/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 https://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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka-remoting with Artery using load balancing/round robbing dns

[Patrik Nordwall]

And for the record, it's just accidental that it works with tcp. We don't
guarantee that the same connection is reused.
tors 10 nov. 2016 kl. 17:14 skrev Endre Varga :

> Actor remote messaging is a P2P protocol and as such any kind of
> name-remapping is harmful. Trying to load balance Akka Remote connections I
> think is a mistake and makes not much sense. You *can* load balance Akka
> provided services of course, but you need to expose them as a different
> protocol (i.e. REST API, custom TCP endpoint, etc.).
>
> On Thu, Nov 10, 2016 at 5:12 PM, 
> wrote:
>
> Ok. Just wanted that confirmed. We already have a workaround for it so I
> was mostly just curious to see if it was needed :).
>
> / Johan
>
>
>
> Den torsdag 10 november 2016 kl. 13:03:36 UTC+1 skrev √:
>
> the host needs to be a stable identifier.
>
> What problem are you trying to solve with the rr dns?
>
> On Thu, Nov 10, 2016 at 10:48 AM,  wrote:
>
> Case:
>
> I have two services (A and B) that wish to talk to each other using
> akka-remoting over artery.
> Each service executes on it's own machine behind a load balancer mapping a
> dns name, e.g. $A resolving -> multiple IP addresses.
>
> For A to talk to B, we can for example execute:
>
> // Make request from an A to a B
> val b = context.actorSelection(s"akka://$systemName@
> $B:$port/user/$actorName")
> b ! Request()
>
> where $B is the load balanced address that is resolved to a B instance
> (maybe B1, maybe B2.. etc)
>
> In order for B to receive this message, B would need to have an akka conf
> with canonical.hostname = $B. Otherwise artery will filter out these
> messages...
>
> So far, this works. However, now let's say this is bidirectional
> communication.
> B wants to reply to A's requests, but also, B wants to send its own
> independent requests to A and expect A to reply back to B.
>
> B would then have something like the following code
> // Reply from B back to A
> def receive {
>   case  Request() => sender() ! Reply()
> }
>
> But because A has canonical.hostname set to $A, which is a load balanced
> address, the reply could end up at A1, A2 or any Ai for that matter.
>
> To work around this, all I can think of is to let each actor resolution
> actually do a manual dns lookup before calling context.actorSelection.. and
> write the explicit resolved address of each actor to their own akka conf.
> *Is this conclusion correct?*
>
> I suspect akka.tcp does not have this problem as sender() would just
> re-use the existing tcp connection, but artery being build on udp, will
> suffer from the problem above.
> Am I missing something? :)
>
> / Johan
>
> --
> >> 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 https://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 https://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 https://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 ema

Re: [akka-user] Akka-remoting with Artery using load balancing/round robbing dns

[Viktor Klang]

Consider that confirmed then. ;)

On Thu, Nov 10, 2016 at 5:12 PM, 
wrote:

> Ok. Just wanted that confirmed. We already have a workaround for it so I
> was mostly just curious to see if it was needed :).
>
> / Johan
>
>
>
> Den torsdag 10 november 2016 kl. 13:03:36 UTC+1 skrev √:
>>
>> the host needs to be a stable identifier.
>>
>> What problem are you trying to solve with the rr dns?
>>
>> On Thu, Nov 10, 2016 at 10:48 AM,  wrote:
>>
>>> Case:
>>>
>>> I have two services (A and B) that wish to talk to each other using
>>> akka-remoting over artery.
>>> Each service executes on it's own machine behind a load balancer mapping
>>> a dns name, e.g. $A resolving -> multiple IP addresses.
>>>
>>> For A to talk to B, we can for example execute:
>>>
>>> // Make request from an A to a B
>>> val b = context.actorSelection(s"akka://$systemName@$B:$port/user/$a
>>> ctorName")
>>> b ! Request()
>>>
>>> where $B is the load balanced address that is resolved to a B instance
>>> (maybe B1, maybe B2.. etc)
>>>
>>> In order for B to receive this message, B would need to have an akka
>>> conf with canonical.hostname = $B. Otherwise artery will filter out these
>>> messages...
>>>
>>> So far, this works. However, now let's say this is bidirectional
>>> communication.
>>> B wants to reply to A's requests, but also, B wants to send its own
>>> independent requests to A and expect A to reply back to B.
>>>
>>> B would then have something like the following code
>>> // Reply from B back to A
>>> def receive {
>>>   case  Request() => sender() ! Reply()
>>> }
>>>
>>> But because A has canonical.hostname set to $A, which is a load balanced
>>> address, the reply could end up at A1, A2 or any Ai for that matter.
>>>
>>> To work around this, all I can think of is to let each actor resolution
>>> actually do a manual dns lookup before calling context.actorSelection.. and
>>> write the explicit resolved address of each actor to their own akka conf.
>>> *Is this conclusion correct?*
>>>
>>> I suspect akka.tcp does not have this problem as sender() would just
>>> re-use the existing tcp connection, but artery being build on udp, will
>>> suffer from the problem above.
>>> Am I missing something? :)
>>>
>>> / Johan
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >> Search the archives: https://groups.google.com/grou
>>> p/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 https://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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka-remoting with Artery using load balancing/round robbing dns

[Johan Kjölhede]

Thanks for clarifying that. We suspected that but weren't sure. We can close 
this thread ;). Thanks everyone for great input

Skickat från min iPhone

> 10 nov. 2016 kl. 18:03 skrev Patrik Nordwall :
> 
> And for the record, it's just accidental that it works with tcp. We don't 
> guarantee that the same connection is reused.
>> tors 10 nov. 2016 kl. 17:14 skrev Endre Varga :
>> Actor remote messaging is a P2P protocol and as such any kind of 
>> name-remapping is harmful. Trying to load balance Akka Remote connections I 
>> think is a mistake and makes not much sense. You *can* load balance Akka 
>> provided services of course, but you need to expose them as a different 
>> protocol (i.e. REST API, custom TCP endpoint, etc.). 
>> 
>> On Thu, Nov 10, 2016 at 5:12 PM,  
>> wrote:
>> Ok. Just wanted that confirmed. We already have a workaround for it so I was 
>> mostly just curious to see if it was needed :).
>> 
>> / Johan
>> 
>> 
>> 
>> Den torsdag 10 november 2016 kl. 13:03:36 UTC+1 skrev √:
>> the host needs to be a stable identifier.
>> 
>> What problem are you trying to solve with the rr dns?
>> 
>> On Thu, Nov 10, 2016 at 10:48 AM,  wrote:
>> Case:
>> 
>> I have two services (A and B) that wish to talk to each other using 
>> akka-remoting over artery.
>> Each service executes on it's own machine behind a load balancer mapping a 
>> dns name, e.g. $A resolving -> multiple IP addresses.
>> 
>> For A to talk to B, we can for example execute:
>> 
>> // Make request from an A to a B
>> val b = 
>> context.actorSelection(s"akka://$systemName@$B:$port/user/$actorName")
>> b ! Request()
>> 
>> where $B is the load balanced address that is resolved to a B instance 
>> (maybe B1, maybe B2.. etc)
>> 
>> In order for B to receive this message, B would need to have an akka conf 
>> with canonical.hostname = $B. Otherwise artery will filter out these 
>> messages...
>> 
>> So far, this works. However, now let's say this is bidirectional 
>> communication. 
>> B wants to reply to A's requests, but also, B wants to send its own 
>> independent requests to A and expect A to reply back to B.
>> 
>> B would then have something like the following code
>> // Reply from B back to A
>> def receive {
>>   case  Request() => sender() ! Reply()
>> }
>> 
>> But because A has canonical.hostname set to $A, which is a load balanced 
>> address, the reply could end up at A1, A2 or any Ai for that matter.
>> 
>> To work around this, all I can think of is to let each actor resolution 
>> actually do a manual dns lookup before calling context.actorSelection.. and 
>> write the explicit resolved address of each actor to their own akka conf.
>> Is this conclusion correct?
>> 
>> I suspect akka.tcp does not have this problem as sender() would just re-use 
>> the existing tcp connection, but artery being build on udp, will suffer from 
>> the problem above.
>> Am I missing something? :)
>> 
>> / Johan
>> 
>> -- 
>> >> 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 https://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 https://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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> >

[akka-user] Re: Exposing Akka actors through a REST API

[Matt Edge]

Not quite sure what you mean when you say you don't want to "manually 
encode" the routes in Akka HTTP. What is it about Akka HTTP that is giving 
you trouble?

I personally have built a couple Akka applications with a REST API sitting 
in front of it. Most of the time I've used http4s but I've also used spray 
(pre Akka HTTP), Akka HTTP (with varying levels of success) and even Spring 
Boot. The trick for me was a clear separation between the REST layer and 
the Akka App (i.e boundaries).

So could you provide more information to your issue?

On Thursday, November 10, 2016 at 10:28:10 AM UTC-5, Alvaro Santuy wrote:
>
> Hello everybody.
>
> Is there any project out there capable to easily build REST routes to Akka 
> Actors? I would like to map REST resources to Akka Actors and messages 
> other than manually encode the routes in Akka HTTP...
>
> Thank you.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: [akka-http] Configuring HTTPS with a trusted certificate chain

[Julian Michael]

Hi Johannes,

Actually, I figured it out: embarrassingly, I had forgotten to import my 
private key into the Java keystore. Once I did that everything worked.. 
sorry to bother you! If only I had a type system that could have warned me 
about it ahead of time, ha ha..

Best,
Julian

On Thursday, November 10, 2016 at 7:44:39 AM UTC-8, 
johannes...@lightbend.com wrote:
>
> Hi Julian,
>
> can you post more information about your code and what happens exactly 
> when you run it? What kind of key material do you have and how do you load 
> it? Are you using akka-http on the client side or on the server side?
>
> Johannes
>
> On Thursday, November 10, 2016 at 9:50:08 AM UTC+1, Julian Michael wrote:
>>
>> Hi akka-user,
>>
>> I'm trying to host a simple server that uses HTTPS. I'm having exactly 
>> the same problem as pointed out in this issue 
>> ,
>> where Chrome responds with ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
>> It worked when I used a self-signed certificate (while Chrome complained 
>> that the cert wasn't trusted, I could go through and view the page),
>> but now that I'm using a proper trusted certificate chain it's not 
>> working.
>> This leads me to think there's something wrong with my keystore, but I 
>> don't know where to start in diagnosing that.
>>
>> Adding the -Djavax.net.debug=all flag to my build.sbt didn't cause 
>> anything to be printed,
>> but I tried openssl s_client -connect : and the output was 
>> as follows.
>>
>> CONNECTED(0003)
>>
>> 140735126758224:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 
>> alert handshake failure:s23_clnt.c:769:
>>
>> ---
>>
>> no peer certificate available
>>
>> ---
>>
>> No client certificate CA names sent
>>
>> ---
>>
>> SSL handshake has read 7 bytes and written 308 bytes
>>
>> ---
>>
>> New, (NONE), Cipher is (NONE)
>>
>> Secure Renegotiation IS NOT supported
>>
>> Compression: NONE
>>
>> Expansion: NONE
>>
>> No ALPN negotiated
>>
>> SSL-Session:
>>
>> Protocol  : TLSv1.2
>>
>> Cipher: 
>>
>> Session-ID: 
>>
>> Session-ID-ctx: 
>>
>> Master-Key: 
>>
>> Key-Arg   : None
>>
>> PSK identity: None
>>
>> PSK identity hint: None
>>
>> SRP username: None
>>
>> Start Time: 1478765759
>>
>> Timeout   : 300 (sec)
>>
>> Verify return code: 0 (ok)
>>
>> ---
>>
>>
>> I don't know much about web protocols and don't really understand this 
>> output.
>>
>> Any idea what the problem might be and how I can fix it?
>>
>>
>> Thank you!
>>
>> Julian
>>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.