Re: [akka-user] Re: Websockets and Flow.fromSinkAndSource

[Aditya Prasad]

Filed an issue: https://github.com/akka/akka/issues/21089

On Monday, August 1, 2016 at 11:36:15 AM UTC-7, Aditya Prasad wrote:
>
> Hmm, I did, and that's why I'm asking this question :) It says:
>
> "The Akka HTTP WebSocket API does not support half-closed connections 
> which means that if the either stream completes the entire connection is 
> closed"
>
> The problem I'm seeing is that it does NOT close the connection if only 
> the output completes.
>
> Or did I misunderstand?
>
> On Mon, Aug 1, 2016 at 11:34 AM, Konrad Malawski <
> konrad.malaw...@lightbend.com> wrote:
>
>> Please read the docs on this topic: 
>> http://doc.akka.io/docs/akka/2.4/scala/http/client-side/websocket-support.html#Half-Closed_WebSockets
>>
>> -- 
>> Konrad `ktoso` Malawski
>> Akka  @ Lightbend 
>>
>> On 1 August 2016 at 20:17:56, Aditya Prasad (akpra...@gmail.com) wrote:
>>
>> tl;dr: webSocketClientFlow does not close the websocket (or shut down 
>> its input stream) when the output stream ends, but I think it's supposed 
>> to. It *does* do the reverse (shut down the output when the input 
>> terminates).
>>
>> On Friday, July 29, 2016 at 6:28:14 PM UTC-7, Aditya Prasad wrote: 
>>>
>>> Hi!
>>>
>>> I've got code like this:
>>>
 val flow = 
 Http().webSocketClientFlow(WebSocketRequest(s"ws://...")))
 val sink = Sink.actorRef(actor, EventsComplete)
 Source.tick[Message](KeepAliveDelay, KeepAliveDelay, 
 KeepAlive).via(flow).runWith(sink)
>>>
>>>
>>> The Source.tick is there because if I use Source.empty, the websocket 
>>> connection gets closed immediately. The docs suggest using Source.maybe 
>>> instead, 
>>> but then the websocket is still closed after some timeout. I need my client 
>>> to listen forever.
>>>
>>> Anyway: if actor finishes (e.g., server requests a hangup and it gets 
>>> an EventsComplete), the websocket does not close. The ticking keeps 
>>> going, sending stuff over the wire.
>>>
>>> This is strange because the docs say it doesn't support half-closed 
>>> websockets[1]. Any guesses what's going on, and what I should do about it? 
>>> In my actual code, one method generates the Source, and another piece of 
>>> code creates the Actor and runs with that Source.
>>>
>>> For now I've got a nasty (though fun to code!) workaround, with a custom 
>>> TerminationWatcherKillSwitch thing so that Flow.fromSinkAndSource will 
>>> terminate one stream if the other terminates.
>>>
>>> Thanks!
>>>
>>> [1] 
>>> http://doc.akka.io/docs/akka/2.4.8/scala/http/client-side/websocket-support.html
>>>
>> --
>> >> 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] Re: Websockets and Flow.fromSinkAndSource

[Aditya Prasad]

Hmm, I did, and that's why I'm asking this question :) It says:

"The Akka HTTP WebSocket API does not support half-closed connections which
means that if the either stream completes the entire connection is closed"

The problem I'm seeing is that it does NOT close the connection if only the
output completes.

Or did I misunderstand?

On Mon, Aug 1, 2016 at 11:34 AM, Konrad Malawski <
konrad.malaw...@lightbend.com> wrote:

> Please read the docs on this topic:
> http://doc.akka.io/docs/akka/2.4/scala/http/client-side/websocket-support.html#Half-Closed_WebSockets
>
> --
> Konrad `ktoso` Malawski
> Akka  @ Lightbend 
>
> On 1 August 2016 at 20:17:56, Aditya Prasad (akpra...@gmail.com) wrote:
>
> tl;dr: webSocketClientFlow does not close the websocket (or shut down its
> input stream) when the output stream ends, but I think it's supposed to. It
> *does* do the reverse (shut down the output when the input terminates).
>
> On Friday, July 29, 2016 at 6:28:14 PM UTC-7, Aditya Prasad wrote:
>>
>> Hi!
>>
>> I've got code like this:
>>
>>> val flow = Http().webSocketClientFlow(WebSocketRequest(s"ws://...")))
>>> val sink = Sink.actorRef(actor, EventsComplete)
>>> Source.tick[Message](KeepAliveDelay, KeepAliveDelay,
>>> KeepAlive).via(flow).runWith(sink)
>>
>>
>> The Source.tick is there because if I use Source.empty, the websocket
>> connection gets closed immediately. The docs suggest using Source.maybe 
>> instead,
>> but then the websocket is still closed after some timeout. I need my client
>> to listen forever.
>>
>> Anyway: if actor finishes (e.g., server requests a hangup and it gets an
>> EventsComplete), the websocket does not close. The ticking keeps going,
>> sending stuff over the wire.
>>
>> This is strange because the docs say it doesn't support half-closed
>> websockets[1]. Any guesses what's going on, and what I should do about it?
>> In my actual code, one method generates the Source, and another piece of
>> code creates the Actor and runs with that Source.
>>
>> For now I've got a nasty (though fun to code!) workaround, with a custom
>> TerminationWatcherKillSwitch thing so that Flow.fromSinkAndSource will
>> terminate one stream if the other terminates.
>>
>> Thanks!
>>
>> [1]
>> http://doc.akka.io/docs/akka/2.4.8/scala/http/client-side/websocket-support.html
>>
> --
> >> 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] Re: Websockets and Flow.fromSinkAndSource

[Konrad Malawski]

Please read the docs on this topic:
http://doc.akka.io/docs/akka/2.4/scala/http/client-side/websocket-support.html#Half-Closed_WebSockets

-- 
Konrad `ktoso` Malawski
Akka  @ Lightbend 

On 1 August 2016 at 20:17:56, Aditya Prasad (akpra...@gmail.com) wrote:

tl;dr: webSocketClientFlow does not close the websocket (or shut down its
input stream) when the output stream ends, but I think it's supposed to. It
*does* do the reverse (shut down the output when the input terminates).

On Friday, July 29, 2016 at 6:28:14 PM UTC-7, Aditya Prasad wrote:
>
> Hi!
>
> I've got code like this:
>
>> val flow = Http().webSocketClientFlow(WebSocketRequest(s"ws://...")))
>> val sink = Sink.actorRef(actor, EventsComplete)
>> Source.tick[Message](KeepAliveDelay, KeepAliveDelay,
>> KeepAlive).via(flow).runWith(sink)
>
>
> The Source.tick is there because if I use Source.empty, the websocket
> connection gets closed immediately. The docs suggest using Source.maybe 
> instead,
> but then the websocket is still closed after some timeout. I need my client
> to listen forever.
>
> Anyway: if actor finishes (e.g., server requests a hangup and it gets an
> EventsComplete), the websocket does not close. The ticking keeps going,
> sending stuff over the wire.
>
> This is strange because the docs say it doesn't support half-closed
> websockets[1]. Any guesses what's going on, and what I should do about it?
> In my actual code, one method generates the Source, and another piece of
> code creates the Actor and runs with that Source.
>
> For now I've got a nasty (though fun to code!) workaround, with a custom
> TerminationWatcherKillSwitch thing so that Flow.fromSinkAndSource will
> terminate one stream if the other terminates.
>
> Thanks!
>
> [1]
> http://doc.akka.io/docs/akka/2.4.8/scala/http/client-side/websocket-support.html
>
--
>> 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: Websockets and Flow.fromSinkAndSource

[Aditya Prasad]

tl;dr: webSocketClientFlow does not close the websocket (or shut down its 
input stream) when the output stream ends, but I think it's supposed to. It 
*does* do the reverse (shut down the output when the input terminates).

On Friday, July 29, 2016 at 6:28:14 PM UTC-7, Aditya Prasad wrote:
>
> Hi!
>
> I've got code like this:
>
>> val flow = Http().webSocketClientFlow(WebSocketRequest(s"ws://...")))
>> val sink = Sink.actorRef(actor, EventsComplete)
>> Source.tick[Message](KeepAliveDelay, KeepAliveDelay, 
>> KeepAlive).via(flow).runWith(sink)
>
>
> The Source.tick is there because if I use Source.empty, the websocket 
> connection gets closed immediately. The docs suggest using Source.maybe 
> instead, 
> but then the websocket is still closed after some timeout. I need my client 
> to listen forever.
>
> Anyway: if actor finishes (e.g., server requests a hangup and it gets an 
> EventsComplete), the websocket does not close. The ticking keeps going, 
> sending stuff over the wire.
>
> This is strange because the docs say it doesn't support half-closed 
> websockets[1]. Any guesses what's going on, and what I should do about it? 
> In my actual code, one method generates the Source, and another piece of 
> code creates the Actor and runs with that Source.
>
> For now I've got a nasty (though fun to code!) workaround, with a custom 
> TerminationWatcherKillSwitch thing so that Flow.fromSinkAndSource will 
> terminate one stream if the other terminates.
>
> Thanks!
>
> [1] 
> http://doc.akka.io/docs/akka/2.4.8/scala/http/client-side/websocket-support.html
>

-- 
>>  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] Get ActorSystem as part of a stream materialization process

[oleksiys]

Thank you Konrad,
it's exactly what I needed!

WBR,
Alexey

On Saturday, July 30, 2016 at 3:56:58 PM UTC-7, Konrad Malawski wrote:
>
> (feel free to copy paste the entire impl and use as-is if you want to btw)
>
> -- 
> Konrad `ktoso` Malawski
> Akka  @ Lightbend 
>
> On 31 July 2016 at 00:52:56, Konrad Malawski (konrad@lightbend.com 
> ) wrote:
>
> I like the idea, this can indeed be very useful!
> We'll see what the rest of the team has to say about it.
>
> I took a shot at implementing it actually, so here it is:
> https://github.com/akka/akka/pull/21076
>
> No guarantees about bug-free ness, but it seems rather complete ;-)
>
>
> It also shows of how awesome GraphStage really is, esp. with it's 
> StageActor feature which we'll blog about more in the near future.
> Just yesterday we published a post introducing GraphStage a bit from a 
> birds view btw: 
> http://blog.akka.io/streams/2016/07/30/mastering-graph-stage-part-1
> Track the blog if you want to learn interesting stuff about internals like 
> that :-)
>
>
> Happy hakking!
>
> -- 
> Konrad `ktoso` Malawski
> Akka  @ Lightbend 
>
> On 30 July 2016 at 23:19:17, Alexey S (kvr...@gmail.com ) 
> wrote:
>
> I'm trying to bind stream life-cycle to an actor life-cycle (let's call it 
> master actor). In a sense that if the stream is destroyed - the master 
> actor receives some Termination message but stays alive, but if the actor 
> is destroyed - the stream has to be shut down as well.
> When I construct part of the stream flow, that has to be responsible for 
> the logic above, I have only an ActorRef of the master actor I want bind 
> the stream life-cycle to.
>
> Originally I wanted to do the following: during stream materialization I 
> get its KillSwitch and create an aux actor with KillSwitch and master 
> ActorRef as parameters. The aux actor will create a watch for the master 
> actor and kill the stream using KillSwitch, once master actor shuts down.
>
> As an alternative I can probably create a branch in the flow, filter off 
> all the possible events/messages and attach the master actor as a 
> Sink.actorRef.
>
> WDYT?
>
> Thanks.
>
> WBR,
> Alexey
>
> On Sat, Jul 30, 2016 at 1:41 PM, Konrad Malawski  > wrote:
>
>> Not using safe APIs.
>> But instead I'd turn around the question and ask what you're trying to 
>> achieve?
>> Perhaps there's a cleaner way than reaching out to the ActorSystem.
>>
>> -- 
>> Konrad `ktoso` Malawski
>> Akka  @ Lightbend 
>>
>> On 30 July 2016 at 22:39:47, oleksiys (kvr...@gmail.com ) 
>> wrote:
>>
>> Hi,
>>
>> is it possible to get access to the ActorSystem, that is being used to 
>> materialize the stream during materialization?
>>
>> Something like:
>>
>> Flow[String].viaMat(*ExposeActorSystemMat.instance*).mapMaterializedValue(actorSystem
>>  
>> => doSomethingWithActorSystem(actorSystem))
>>
>> Thanks.
>>
>> WBR,
>> Alexey
>> --
>> >> 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.

Re: [akka-user] Default for akka.http.server.remote-address-header

[Konrad Malawski]

None that would really matter. The bottlenecks are elsewhere.

-- 
Konrad `ktoso` Malawski
Akka  @ Lightbend 

On 1 August 2016 at 19:33:22, Matt Hughes (hughes.m...@gmail.com) wrote:

Right, that’s what I figured. If you wrote a test that sent two headers,
you wouldn’t want to magically see a third added.

So no performance implications that you know of?




On August 1, 2016 at 1:19:32 PM, Konrad Malawski (
konrad.malaw...@lightbend.com) wrote:

If you need it, you'll find the option.
Why make everyone pay the price of fabricating that header :-)

Also, it's a bit weird – people are not expecting headers that were not in
the request to show up.
It's a more natural learning curve that you discover the feature and opt
into it.

-- 
Konrad `ktoso` Malawski
Akka  @ Lightbend 

On 1 August 2016 at 19:17:24, Matt Hughes (hughes.m...@gmail.com) wrote:

Was curious why the default configuration for this value is off.  Is it
performance related?  The desire to not modify HTTP headers?
--
>> 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] Default for akka.http.server.remote-address-header

[Matt Hughes]

Right, that’s what I figured. If you wrote a test that sent two headers, you 
wouldn’t want to magically see a third added.

So no performance implications that you know of?





On August 1, 2016 at 1:19:32 PM, Konrad Malawski 
(konrad.malaw...@lightbend.com) wrote:

If you need it, you'll find the option.
Why make everyone pay the price of fabricating that header :-)

Also, it's a bit weird – people are not expecting headers that were not in the 
request to show up.
It's a more natural learning curve that you discover the feature and opt into 
it.

-- 
Konrad `ktoso` Malawski
Akka @ Lightbend

On 1 August 2016 at 19:17:24, Matt Hughes (hughes.m...@gmail.com) wrote:

Was curious why the default configuration for this value is off.  Is it 
performance related?  The desire to not modify HTTP headers?
--
>> 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] How to disable TLSv1 when I configure "akka.remote.netty.ssl.security.protocol" property as TLSv1.2.

[Will Sargent]

> Otherwise, I have tried "jdk.tls.client.protocols" system property, but
it does not achieve the desired effect.

Okay -- "jdk.tls.client.protocols" only disables SSL from a client
perspective ONLY.  Akka remoting is from a server context.  And
"https.protocol" is only good for an HTTPSURLConnection, not for SSLEngine.

If you want to disable it from the server perspective and you want to do it
on a specific SSL context, then you have to call setAlgorithmConstraints
directly:

val sslParameters = sslContext.getDefaultSSLParameters() // clones new
instance from default
val sslEngine = sslContext.createSSLEngine(peerHost, peerPort)
sslParameters.setAlgorithmConstraints(algConstraints)
sslEngine.setSSLParameters(sslParameters)

Otherwise, if you want disabled algorithms the only reliable way to set it
is:

java -Djava.security.properties=disabledAlgorithms.properties

Wrote more about this in
https://tersesystems.com/2014/01/13/fixing-the-most-dangerous-code-in-the-world/

Adding this to the Akka issue so Konrad doesn't have to...



--
Will Sargent
*Engineer, Lightbend, Inc.*
will.sarg...@lightbend.com


On Sun, Jul 31, 2016 at 4:30 AM, Konrad 'ktoso' Malawski 
wrote:

> That seems like a good catch indeed!
> Thanks for finding this.
>
> I've made an issue and PR for it:
> https://github.com/akka/akka/issues/21077
> https://github.com/akka/akka/pull/21078
>
> If reviewed by team we could include this patch very soon.
>
> Thanks for reporting!
>
> -- Konrad
>
>
> W dniu czwartek, 28 lipca 2016 09:36:59 UTC+2 użytkownik
> yinzho...@gmail.com napisał:
>>
>> Thank you first for your reply :)
>>
>> I add TLSv1 to jdk.tls.disabledAlgorithms of JRE java.security file, in
>> this way I can resolve the problem, but the modify will globally affect,
>> for example there is a java app needs TLSv1.
>> Otherwise, I have tried "jdk.tls.client.protocols" system property, but
>> it does not achieve the desired effect.
>>
>> I have tried to invoke "setEnabledProtocols" method
>> of javax.net.ssl.SSLEngine class on my java test code, it can achieve the
>> desired effect.
>> The relevant AKKA source code of akka.remoting as follow:
>> case Some(context) ⇒
>> log.debug("Using client SSL context to create SSLEngine ...")
>> new SslHandler({
>>   val sslEngine = context.createSSLEngine
>>   sslEngine.setUseClientMode(true)
>>   sslEngine.setEnabledCipherSuites(settings.SSLEnabledAlgorithms.
>> toArray)
>>   sslEngine.setEnabledProtocols(Array("TLSv1.2"))   =>  Add this
>> line can resovle my problem, but I don't want to modify AKKA source code
>> :(
>>   sslEngine
>>
>> Is there a way to set ssl option without modify AKKA source code?
>> Thank you.
>>
>>
>> 在 2016年7月27日星期三 UTC+8上午4:02:45，Will Sargent写道：
>>>
>>> You can set the "jdk.tls.client.protocols" system property to set
>>> options for the JVM -- this is a feature that is only available in JDK 1.8
>>> though.
>>>
>>>
>>> https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSE_Protocols
>>>
>>> Otherwise, you would have to set the security
>>> property jdk.tls.disabledAlgorithms to add TLSv1 specifically.
>>>
>>>
>>> Will Sargent
>>> Engineer, Lightbend, Inc.
>>>
>>>
>>> On Tue, Jul 26, 2016 at 1:12 AM,  wrote:
>>>
 Configure file as follow:
 # Protocol to use for SSL encryption, choose from:
 # Java 6 & 7:
 #   'SSLv3', 'TLSv1'
 # Java 7:
 #   'TLSv1.1', 'TLSv1.2'
 protocol = "TLSv1.2"


 When I use nmap to scan, I find that TLSv1 is enabled:
 D:\softwares\nmap-7.12>nmap -p  --script=ssl* x.x.x.x --
 unprivileged


 Starting Nmap 7.12 ( https://nmap.org ) at 2016-07-26 15:33
 °?′óà÷2?±ê×?ê±??
 Nmap scan report for x.x.x.x
 Host is up (1.0s latency).
 PORT STATE  SERVICE
 /tcp open unknown
 | ssl-enum-ciphers:
 |  TLSv1.0:
 |ciphers:
 |  TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) -A
 |compressors:
 |  NULL
 |cipher preference: indeterminate
 |cipher preference error: Too few ciphers supported
 |  TLSv1.1:
 |ciphers:
 |  TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) -A
 |compressors:
 |  NULL
 |cipher preference: indeterminate
 |cipher preference error: Too few ciphers supported
 |  TLSv1.2:
 |ciphers:
 |  TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) -A
 |compressors:
 |  NULL
 |cipher preference: indeterminate
 |cipher preference error: Too few ciphers supported
 |_ least strength: A
 MAC Address: xx:xx:xx:xx:xx:xx


 Nmap done: 1 IP address (1 host up) scanned in 3.88 seconds


 D:\softwares\nmap-7.12>

 I want to disable TLSv1. Any method?
 Thank you.


 --
 >> Read the docs: http://akka.io/docs/
 >> Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/f

Re: [akka-user] Default for akka.http.server.remote-address-header

[Konrad Malawski]

If you need it, you'll find the option.
Why make everyone pay the price of fabricating that header :-)

Also, it's a bit weird – people are not expecting headers that were not in
the request to show up.
It's a more natural learning curve that you discover the feature and opt
into it.

-- 
Konrad `ktoso` Malawski
Akka  @ Lightbend 

On 1 August 2016 at 19:17:24, Matt Hughes (hughes.m...@gmail.com) wrote:

Was curious why the default configuration for this value is off.  Is it
performance related?  The desire to not modify HTTP headers?
--
>> 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] Default for akka.http.server.remote-address-header

[Matt Hughes]

Was curious why the default configuration for this value is off.  Is it 
performance related?  The desire to not modify HTTP headers?

-- 
>>  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] How to add connection.remoteAddress to Http request handler - additional input parameter to Flow

[Zlatko Roncevic]

Hi,

I need origin IP address in my request handler, but I don't know how to add 
this parameter ...

Code is here

  Source> serverSource =
Http.get(system).bind(ConnectHttp.toHost(host, port), materializer);
 
binding =  serverSource.to(Sink.foreach(connection -> {
 logger.info("Accepted new connection from {} " + 
connection.remoteAddress());
 
 
 connection.handleWith(Flow.create().mapAsync(1, 
requestHandler), materializer);

}
 )).run(materializer);

binding.handle((ok, ex) -> {
   if (ok != null) {
logger.info("Server listening on {}:{}",host, port);
   return ok;
   } else {
   logger.error("Problem during start: {}", ex);
   return -1;
   }
});


//Request handler

final Function> requestHandler = 
new Function>(){
@Override
public CompletionStage apply(HttpRequest request) throws 
Exception {
logger.trace("Request from : {} {} {}", request.method(), request.getUri(), 
request.getHeaders());
//I would like to have  connection.remoteAddress() value here
...


I'm missing something, what is right approach to put initial parameters to 
flow?

Thanks !

Regards

Zlatko
 


 

-- 
>>  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] Re: Microservices Architecture with AKKA Cluster

[Maatary Okouya]

BTW,

yup would love to collaborate on this issue. Although right now i barely
have the time. In a near future yes. Will definitely get back to you on
that.

On Mon, Aug 1, 2016 at 10:27 AM, Maatary Okouya 
wrote:

> Thank you very much for this detailed input.
>
> On Sun, Jul 31, 2016 at 2:43 AM, Dagny T  wrote:
>
>>
>> Typo on my last comment; meant to say I 'used' the existing Akka Graph
>> DSL.  (Definitely didn't write my own!)
>>
>> On Friday, July 15, 2016 at 9:03:05 AM UTC-7, Maatary Okouya wrote:
>>
>>> Hi,
>>>
>>> given that Longom is not working to Scala anytime soon. I wonder if
>>> someone could share with some good content on how build a good microservice
>>> architecture with AKKA including Recommendation, best practices, things to
>>> avoid and so on.
>>>
>>>
>>> Or if someone as experiences and want to share it here that would be
>>> grate.
>>>
>>>
>>> For instance what are the layer involves from database up to the REST
>>> Layer and so on.
>>>
>>>
>>> --
>> >> 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/_a23UPTX5Ic/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 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] Re: Microservices Architecture with AKKA Cluster

[Maatary Okouya]

Thank you very much for this detailed input.

On Sun, Jul 31, 2016 at 2:43 AM, Dagny T  wrote:

>
> Typo on my last comment; meant to say I 'used' the existing Akka Graph
> DSL.  (Definitely didn't write my own!)
>
> On Friday, July 15, 2016 at 9:03:05 AM UTC-7, Maatary Okouya wrote:
>
>> Hi,
>>
>> given that Longom is not working to Scala anytime soon. I wonder if
>> someone could share with some good content on how build a good microservice
>> architecture with AKKA including Recommendation, best practices, things to
>> avoid and so on.
>>
>>
>> Or if someone as experiences and want to share it here that would be
>> grate.
>>
>>
>> For instance what are the layer involves from database up to the REST
>> Layer and so on.
>>
>>
>> --
> >> 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/_a23UPTX5Ic/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 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: Akka Java TCP client , Sink.ignore()

[murtuza chhil]

Thanks for the clarification Konrad.
I kind  of figured it was a NoOp sink, but wasn't sure if there would be 
any side effects due to lack of knowledge.
For now my baby step simply wants to connect. As I move forward the 
Sink.ignore will get replaced by a sink that handles the responses.
My problem was resolved in this thread 
.

-chhil

On Monday, August 1, 2016 at 12:45:22 PM UTC+5:30, Johan Andrén wrote:
>
> Hi Chhil,
>
> If you do not care about any incoming data from the TCP server Sink.ignore 
> should be fine (it will accept but discard any data from the server).
>
> --
> Johan
> Akka Team
>
> On Friday, July 29, 2016 at 12:48:52 PM UTC+2, murtuza chhil wrote:
>>
>>
>> Hi,
>>
>> I am an Akka newbie trying to get my head around streams.
>>
>> In the following working snippet, if I have a netcat server running I can 
>> get the client to send the bytes across.
>>
>> The sink.ignore that I added is simply because I needed a sink to connect 
>> to to run the graph. Is that really needed and how would I run something 
>> without it because as I see it, 
>> I have a source and a the flow created by the Tcp.get(), that should 
>> be sufficient to send the data. 
>>
>> Did have a look at the TCpEcho example, but I want to do it without the 
>> runfold.
>>
>> ```
>> Flow> flow = 
>> Tcp
>> .get(system).outgoingConnection("127.0.0.1", 6000);
>> Source clientSource = Source.single(ByteString
>> .fromString("Chhil"));
>> clientSource.via(flow).to(Sink.ignore()).run(mat);
>> ```
>>
>> -chhil
>>
>

-- 
>>  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] Re: [akka-streams] Trying to mimic socket level programming , connect client and then send data if connection is available

[murtuza chhil]

Hi Konrad,

The  Source>> 
clientSource = Source.maybe(); does the trick, don't see a 
disconnect on the netcat server send.
Also figured, I shouldn't be running the graph multiple times once to 
connect and the second time to send data. Once its run, any data fed by the 
source will be sent out.
This was the reason I was seeing multiple connections.

Thank you. Appreciate the help.

-chhil

On Monday, August 1, 2016 at 2:57:47 PM UTC+5:30, Konrad Malawski wrote:
>
> Source.single completes the stream (closes the connection) once it has 
> signalled the data.
> Simply put a Source.maybe behind it (a.concat(b)) or use a different 
> source, like unfold or an iterator).
>
> -- 
> Konrad `ktoso` Malawski
> Akka  @ Lightbend 
>
> On 1 August 2016 at 11:24:51, murtuza chhil (chi...@gmail.com 
> ) wrote:
>
> Hi Johan,
>
> Thank you very much. Yes indeed stream + tcp is hurting me for sure and I 
> have tried reading the docs and sample code over and over.
>
> So yes, I made some progress. Please ignore the verbosity of the code, I 
> just need to familiarize myself with return values and look at the source 
> of those easily via eclipse.
>
>
> final ActorSystem system = ActorSystem.create("Client");
> final ActorMaterializer mat = ActorMaterializer.create(system);
>
> Tcp tcp = Tcp.get(system);
> Flow> 
> outgoingConnection = tcp
> .outgoingConnection("127.0.0.1", 6000);
>
> Source clientSource = Source.empty();  
>
> CompletionStage cs = clientSource.via(outgoingConnection)
> .runWith(Sink.ignore(), mat);
>
> cs.exceptionally(ex -> {
> ex.printStackTrace();
> return null;
> });
>
> Source clientSource1 = Source.single(ByteString
> .fromString("Chhil"));  
>
> NotUsed var = clientSource1.via(outgoingConnection).to(Sink.ignore())
> .run(mat);
>
> ​
>
> Managed to get a connection made usingSource.empty()​ for the initial 
> connect.
> The CompletionStage kicks in nicely. You mentioned I should be able to get 
>  CompletionStage to determine problems with the 
> connection, this I don't know how or when it gets returned when the graph 
> is run. Please do correct me if understanding is wrong.
> I use the materialized value from the connect and that works fine, as I 
> don't see a new connect after the initial connect with the Source.empty(). 
> I assume this is the right way to get the initial connection and then 
> change the source for regular communication.
>
> *Now the problem I have run into is, that after sending data, the channel 
> disconnects. What must I do to keep it open?*
>
> -chhil
>
>
> On Monday, August 1, 2016 at 12:31:08 PM UTC+5:30, Johan Andrén wrote: 
>>
>> Hi Chhil, 
>>
>> The flow returned by outgoingConnection materializes into a 
>> CompletionStage which will be failed if the 
>> connection fails, so that is where you can implement your error handling 
>> for the initial connection. You would have to keep the materialized value 
>> when you construct the flow though, so that it is returned from run(). 
>>
>> You can read more about materialized values here: 
>> http://doc.akka.io/docs/akka/2.4/java/stream/stream-composition.html#materialized-values
>>  
>> and TCP with streams here: 
>> http://doc.akka.io/docs/akka/2.4/java/stream/stream-io.html#stream-io-java 
>>  
>>
>> In general, read as much of the streams docs as you can to get a good 
>> understanding of how Akka Streams work, trial and error with streams + tcp 
>> will hurt!
>>
>> --
>> Johan
>> Akka Team
>>
>> On Monday, August 1, 2016 at 7:20:23 AM UTC+2, murtuza chhil wrote: 
>>>
>>> Hello, 
>>>
>>> I am a newbie trying to understand Akka Streams.
>>>
>>> Coming from regular socket programming I am trying to mimic a client 
>>> connection and have the following runnable graph.
>>>
>>> Flow> 
>>> flow = Tcp
>>> .get(system).outgoingConnection("127.0.0.1", 6000);
>>> Source clientSource = Source.single(ByteString
>>> .fromString("XYZ"));
>>>
>>> clientSource.via(flow).to(Sink.ignore()).run(mat);
>>>
>>> ​
>>>
>>> This works fine when used with the samples in the doc, where the source 
>>> is attached that has a list and there is a server listening and we run the 
>>> source->flow->sink through a materializer.
>>>
>>> But this is not a typical use case, typically one would attempt to 
>>> connect to a server,  and either it connects or fails. If connected send 
>>> data that will be made available and if connection fails, have the ability 
>>> to backoff.
>>>
>>>
>>> Currently I don't know how to access the error when a server is not 
>>> available and want to establish a connection before data is available.
>>> Don't know how to prevent connections every time data is sent, I 
>>> understand why it happens, but don't know how to reuse a materialized flow 
>>> that has alread

Re: [akka-user] Re: [akka-streams] Trying to mimic socket level programming , connect client and then send data if connection is available

[Konrad Malawski]

Source.single completes the stream (closes the connection) once it has
signalled the data.
Simply put a Source.maybe behind it (a.concat(b)) or use a different
source, like unfold or an iterator).

-- 
Konrad `ktoso` Malawski
Akka  @ Lightbend 

On 1 August 2016 at 11:24:51, murtuza chhil (chil...@gmail.com) wrote:

Hi Johan,

Thank you very much. Yes indeed stream + tcp is hurting me for sure and I
have tried reading the docs and sample code over and over.

So yes, I made some progress. Please ignore the verbosity of the code, I
just need to familiarize myself with return values and look at the source
of those easily via eclipse.


final ActorSystem system = ActorSystem.create("Client");
final ActorMaterializer mat = ActorMaterializer.create(system);

Tcp tcp = Tcp.get(system);
Flow> outgoingConnection = tcp
.outgoingConnection("127.0.0.1", 6000);

Source clientSource = Source.empty();

CompletionStage cs = clientSource.via(outgoingConnection)
.runWith(Sink.ignore(), mat);

cs.exceptionally(ex -> {
ex.printStackTrace();
return null;
});

Source clientSource1 = Source.single(ByteString
.fromString("Chhil"));

NotUsed var = clientSource1.via(outgoingConnection).to(Sink.ignore())
.run(mat);

​

Managed to get a connection made usingSource.empty()​ for the initial
connect.
The CompletionStage kicks in nicely. You mentioned I should be able to get
CompletionStage to determine problems with the
connection, this I don't know how or when it gets returned when the graph
is run. Please do correct me if understanding is wrong.
I use the materialized value from the connect and that works fine, as I
don't see a new connect after the initial connect with the Source.empty().
I assume this is the right way to get the initial connection and then
change the source for regular communication.

*Now the problem I have run into is, that after sending data, the channel
disconnects. What must I do to keep it open?*

-chhil


On Monday, August 1, 2016 at 12:31:08 PM UTC+5:30, Johan Andrén wrote:
>
> Hi Chhil,
>
> The flow returned by outgoingConnection materializes into a
> CompletionStage which will be failed if the
> connection fails, so that is where you can implement your error handling
> for the initial connection. You would have to keep the materialized value
> when you construct the flow though, so that it is returned from run().
>
> You can read more about materialized values here:
> http://doc.akka.io/docs/akka/2.4/java/stream/stream-composition.html#materialized-values
> and TCP with streams here:
> http://doc.akka.io/docs/akka/2.4/java/stream/stream-io.html#stream-io-java
>
>
> In general, read as much of the streams docs as you can to get a good
> understanding of how Akka Streams work, trial and error with streams + tcp
> will hurt!
>
> --
> Johan
> Akka Team
>
> On Monday, August 1, 2016 at 7:20:23 AM UTC+2, murtuza chhil wrote:
>>
>> Hello,
>>
>> I am a newbie trying to understand Akka Streams.
>>
>> Coming from regular socket programming I am trying to mimic a client
>> connection and have the following runnable graph.
>>
>> Flow> 
>> flow = Tcp
>> .get(system).outgoingConnection("127.0.0.1", 6000);
>> Source clientSource = Source.single(ByteString
>> .fromString("XYZ"));
>>
>> clientSource.via(flow).to(Sink.ignore()).run(mat);
>>
>> ​
>>
>> This works fine when used with the samples in the doc, where the source
>> is attached that has a list and there is a server listening and we run the
>> source->flow->sink through a materializer.
>>
>> But this is not a typical use case, typically one would attempt to
>> connect to a server,  and either it connects or fails. If connected send
>> data that will be made available and if connection fails, have the ability
>> to backoff.
>>
>>
>> Currently I don't know how to access the error when a server is not
>> available and want to establish a connection before data is available.
>> Don't know how to prevent connections every time data is sent, I
>> understand why it happens, but don't know how to reuse a materialized flow
>> that has already connected.
>> What I am trying to get my head around is how does one run a graph
>> without any source data and get a completable future that tells me if it
>> succeeded or not.
>> Then I want to use the same connection to send data later using the
>> source.
>>
>> I have attempted with a runfold and that give me the akka TCP Exception
>> when the server is not availble, but I simply want to forward the data from
>> the source without manipulation.
>>
>> There was another thread that I had started
>> https://groups.google.com/d/msg/akka-user/1ztizMy9FnI/U9toR-cOBgAJ,
>> would appreciate if someone responds to it.
>>
>> Any pointers or snippets would be greatly appreciated. Yes I 

[akka-user] Re: [akka-streams] Trying to mimic socket level programming , connect client and then send data if connection is available

[murtuza chhil]

Hi Johan,

Thank you very much. Yes indeed stream + tcp is hurting me for sure and I 
have tried reading the docs and sample code over and over.

So yes, I made some progress. Please ignore the verbosity of the code, I 
just need to familiarize myself with return values and look at the source 
of those easily via eclipse.


final ActorSystem system = ActorSystem.create("Client");
final ActorMaterializer mat = ActorMaterializer.create(system);

Tcp tcp = Tcp.get(system);
Flow> 
outgoingConnection = tcp
.outgoingConnection("127.0.0.1", 6000);

Source clientSource = Source.empty(); 

CompletionStage cs = clientSource.via(outgoingConnection)
.runWith(Sink.ignore(), mat);

cs.exceptionally(ex -> {
ex.printStackTrace();
return null;
});

Source clientSource1 = Source.single(ByteString
.fromString("Chhil")); 

NotUsed var = clientSource1.via(outgoingConnection).to(Sink.ignore())
.run(mat);

​

Managed to get a connection made usingSource.empty()​ for the initial 
connect.
The CompletionStage kicks in nicely. You mentioned I should be able to get  
CompletionStage 
to determine problems with the connection, this I don't know how or when it 
gets returned when the graph is run. Please do correct me if understanding 
is wrong.
I use the materialized value from the connect and that works fine, as I 
don't see a new connect after the initial connect with the Source.empty(). 
I assume this is the right way to get the initial connection and then 
change the source for regular communication.

*Now the problem I have run into is, that after sending data, the channel 
disconnects. What must I do to keep it open?*

-chhil


On Monday, August 1, 2016 at 12:31:08 PM UTC+5:30, Johan Andrén wrote:
>
> Hi Chhil,
>
> The flow returned by outgoingConnection materializes into a 
> CompletionStage which will be failed if the 
> connection fails, so that is where you can implement your error handling 
> for the initial connection. You would have to keep the materialized value 
> when you construct the flow though, so that it is returned from run(). 
>
> You can read more about materialized values here: 
> http://doc.akka.io/docs/akka/2.4/java/stream/stream-composition.html#materialized-values
>  
> and TCP with streams here: 
> http://doc.akka.io/docs/akka/2.4/java/stream/stream-io.html#stream-io-java 
>  
>
> In general, read as much of the streams docs as you can to get a good 
> understanding of how Akka Streams work, trial and error with streams + tcp 
> will hurt!
>
> --
> Johan
> Akka Team
>
> On Monday, August 1, 2016 at 7:20:23 AM UTC+2, murtuza chhil wrote:
>>
>> Hello,
>>
>> I am a newbie trying to understand Akka Streams.
>>
>> Coming from regular socket programming I am trying to mimic a client 
>> connection and have the following runnable graph.
>>
>> Flow> 
>> flow = Tcp
>> .get(system).outgoingConnection("127.0.0.1", 6000);
>> Source clientSource = Source.single(ByteString
>> .fromString("XYZ"));
>>
>> clientSource.via(flow).to(Sink.ignore()).run(mat);
>>
>> ​
>>
>> This works fine when used with the samples in the doc, where the source 
>> is attached that has a list and there is a server listening and we run the 
>> source->flow->sink through a materializer.
>>
>> But this is not a typical use case, typically one would attempt to 
>> connect to a server,  and either it connects or fails. If connected send 
>> data that will be made available and if connection fails, have the ability 
>> to backoff.
>>
>>
>> Currently I don't know how to access the error when a server is not 
>> available and want to establish a connection before data is available.
>> Don't know how to prevent connections every time data is sent, I 
>> understand why it happens, but don't know how to reuse a materialized flow 
>> that has already connected.
>> What I am trying to get my head around is how does one run a graph 
>> without any source data and get a completable future that tells me if it 
>> succeeded or not.
>> Then I want to use the same connection to send data later using the 
>> source.
>>
>> I have attempted with a runfold and that give me the akka TCP Exception 
>> when the server is not availble, but I simply want to forward the data from 
>> the source without manipulation.
>>
>> There was another thread that I had started 
>> https://groups.google.com/d/msg/akka-user/1ztizMy9FnI/U9toR-cOBgAJ, 
>> would appreciate if someone responds to it. 
>>
>> Any pointers or snippets would be greatly appreciated. Yes I am not used 
>> to this paradigm of programming but trying to figure it out.
>>
>> -chhil
>>
>>

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

[akka-user] Re: Akka Java TCP client , Sink.ignore()

[Johan Andrén]

Hi Chhil,

If you do not care about any incoming data from the TCP server Sink.ignore 
should be fine (it will accept but discard any data from the server).

--
Johan
Akka Team

On Friday, July 29, 2016 at 12:48:52 PM UTC+2, murtuza chhil wrote:
>
>
> Hi,
>
> I am an Akka newbie trying to get my head around streams.
>
> In the following working snippet, if I have a netcat server running I can 
> get the client to send the bytes across.
>
> The sink.ignore that I added is simply because I needed a sink to connect 
> to to run the graph. Is that really needed and how would I run something 
> without it because as I see it, 
> I have a source and a the flow created by the Tcp.get(), that should 
> be sufficient to send the data. 
>
> Did have a look at the TCpEcho example, but I want to do it without the 
> runfold.
>
> ```
> Flow> flow = 
> Tcp
> .get(system).outgoingConnection("127.0.0.1", 6000);
> Source clientSource = Source.single(ByteString
> .fromString("Chhil"));
> clientSource.via(flow).to(Sink.ignore()).run(mat);
> ```
>
> -chhil
>

-- 
>>  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-streams] Trying to mimic socket level programming , connect client and then send data if connection is available

[Johan Andrén]

Hi Chhil,

The flow returned by outgoingConnection materializes into a 
CompletionStage which will be failed if the connection 
fails, so that is where you can implement your error handling for the 
initial connection. You would have to keep the materialized value when you 
construct the flow though, so that it is returned from run(). 

You can read more about materialized values 
here: 
http://doc.akka.io/docs/akka/2.4/java/stream/stream-composition.html#materialized-values
 
and TCP with streams here: 
http://doc.akka.io/docs/akka/2.4/java/stream/stream-io.html#stream-io-java  

In general, read as much of the streams docs as you can to get a good 
understanding of how Akka Streams work, trial and error with streams + tcp 
will hurt!

--
Johan
Akka Team

On Monday, August 1, 2016 at 7:20:23 AM UTC+2, murtuza chhil wrote:
>
> Hello,
>
> I am a newbie trying to understand Akka Streams.
>
> Coming from regular socket programming I am trying to mimic a client 
> connection and have the following runnable graph.
>
> Flow> 
> flow = Tcp
> .get(system).outgoingConnection("127.0.0.1", 6000);
> Source clientSource = Source.single(ByteString
> .fromString("XYZ"));
>
> clientSource.via(flow).to(Sink.ignore()).run(mat);
>
> ​
>
> This works fine when used with the samples in the doc, where the source is 
> attached that has a list and there is a server listening and we run the 
> source->flow->sink through a materializer.
>
> But this is not a typical use case, typically one would attempt to connect 
> to a server,  and either it connects or fails. If connected send data that 
> will be made available and if connection fails, have the ability to backoff.
>
>
> Currently I don't know how to access the error when a server is not 
> available and want to establish a connection before data is available.
> Don't know how to prevent connections every time data is sent, I 
> understand why it happens, but don't know how to reuse a materialized flow 
> that has already connected.
> What I am trying to get my head around is how does one run a graph without 
> any source data and get a completable future that tells me if it succeeded 
> or not.
> Then I want to use the same connection to send data later using the source.
>
> I have attempted with a runfold and that give me the akka TCP Exception 
> when the server is not availble, but I simply want to forward the data from 
> the source without manipulation.
>
> There was another thread that I had started 
> https://groups.google.com/d/msg/akka-user/1ztizMy9FnI/U9toR-cOBgAJ, would 
> appreciate if someone responds to it. 
>
> Any pointers or snippets would be greatly appreciated. Yes I am not used 
> to this paradigm of programming but trying to figure it out.
>
> -chhil
>
>

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