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

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 thoug

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

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 he

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

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 t

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

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 201

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

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

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

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 probl

Re: [akka-user] Re: Microservices Architecture with AKKA Cluster

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

Re: [akka-user] Re: Microservices Architecture with AKKA Cluster

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,

[akka-user] How to add connection.remoteAddress to Http request handler - additional input parameter to Flow

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

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

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

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

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 `k

Re: [akka-user] How to disable TLSv1 when I configure "akka.remote.netty.ssl.security.protocol" property as TLSv1.2.

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

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

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 th

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

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

Re: [akka-user] Get ActorSystem as part of a stream materialization process

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

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

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!

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

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: t

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

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

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

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 ei