[akka-user] Akka scheduler

[José Diaz]

Hi guys

I am a newbie in akka.

I am using scheduler for starts my supervisor.

system.scheduler().schedule(Duration.Zero(),
Duration.create(collectorInterval,---> 1 Minute
TimeUnit.MINUTES), supervisor,
Supervisor
.START_COLLECTING,
system.dispatcher(), null);

The code of my Supervisor.java is here 
.


My question is My actor with your child actors can finished in two or 10 
minutes by example.

What happen when the new interval is reached? 
a) A new Supervisor is created?

@Component
@Scope("prototype")  --> I am using spring and set scope prototype for help 
with it.
public class Supervisor 


b) None. Because the first Supervisor not finished.

Thanks yours responses.


Jose


-- 
>>  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-HTTP] How do I not specify the charset?

[Derek Wyatt]

We have been able to see it work, if we put the charset *between* the 
multipart/form-data and the boundary.  i.e.

Content-Type: multipart/form-data; charset=utf-8; 
boundary=some-nonsense-here

Which should reasonably work for everyone, including this busted app.  I 
know that it messes with the rendering a little bit (i.e. the MediaType is 
rendered, and then the charset is rendered), but would you guys consider a 
PR with that change?

On Tuesday, September 13, 2016 at 1:37:39 PM UTC-4, Derek Wyatt wrote:
>
> I'm not arguing that Akka is doing the wrong thing.
>
> But, I'm pretty screwed right now because significant functionality of the 
> app for which I'm proxying is broken due to this and it's probably going to 
> be my problem to fix :)  So, is there any way that I can hook into the 
> parsing and rendering of the request in order to munge it into something 
> that doesn't break this poorly behaving app?
>
> On Tuesday, September 13, 2016 at 1:29:03 PM UTC-4, √ wrote:
>>
>> "The "charset" parameter is used with some media types to define the 
>> character set (section 3.4) of the data. When no explicit charset parameter 
>> is provided by the sender, media subtypes of the "text" type are defined to 
>> have a default charset value of "ISO-8859-1" when received via HTTP. Data 
>> in character sets other than "ISO-8859-1" or its subsets MUST be labeled 
>> with an appropriate charset value. See section 3.4.1 
>>  for 
>> compatibility problems."
>>
>> https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7
>>
>> -- 
>> Cheers,
>> √
>>
>> On Sep 13, 2016 18:58, "Derek Wyatt"  wrote:
>>
>>> Hi guys,
>>>
>>> I've written a reverse-proxy with Akka-HTTP and I'm hitting a problem 
>>> while trying to interact with an ASP.NET app.  The only interesting 
>>> thing I can see is that without the proxy, the Content-Type is lacking a 
>>> charset but the proxy adds charset=UTF-8.
>>>
>>> I can't find a way to replicate that using Akka HTTP.  I think we can 
>>> all agree that the addition of charset=UTF-8 is the right thing to do, but 
>>> in this case it may be causing us a problem and I'd like to force it to 
>>> look the same.  The best I've gotten so far is a definition where it has 
>>> 'charset=', which isn't quite right.
>>>
>>> Can this be done?
>>>
>>> -- 
>>> >> 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] [Akka-HTTP] How do I not specify the charset?

[Derek Wyatt]

I'm not arguing that Akka is doing the wrong thing.

But, I'm pretty screwed right now because significant functionality of the 
app for which I'm proxying is broken due to this and it's probably going to 
be my problem to fix :)  So, is there any way that I can hook into the 
parsing and rendering of the request in order to munge it into something 
that doesn't break this poorly behaving app?

On Tuesday, September 13, 2016 at 1:29:03 PM UTC-4, √ wrote:
>
> "The "charset" parameter is used with some media types to define the 
> character set (section 3.4) of the data. When no explicit charset parameter 
> is provided by the sender, media subtypes of the "text" type are defined to 
> have a default charset value of "ISO-8859-1" when received via HTTP. Data 
> in character sets other than "ISO-8859-1" or its subsets MUST be labeled 
> with an appropriate charset value. See section 3.4.1 
>  for 
> compatibility problems."
>
> https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7
>
> -- 
> Cheers,
> √
>
> On Sep 13, 2016 18:58, "Derek Wyatt"  
> wrote:
>
>> Hi guys,
>>
>> I've written a reverse-proxy with Akka-HTTP and I'm hitting a problem 
>> while trying to interact with an ASP.NET app.  The only interesting 
>> thing I can see is that without the proxy, the Content-Type is lacking a 
>> charset but the proxy adds charset=UTF-8.
>>
>> I can't find a way to replicate that using Akka HTTP.  I think we can all 
>> agree that the addition of charset=UTF-8 is the right thing to do, but in 
>> this case it may be causing us a problem and I'd like to force it to look 
>> the same.  The best I've gotten so far is a definition where it has 
>> 'charset=', which isn't quite right.
>>
>> Can this be done?
>>
>> -- 
>> >> 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] Re: [Akka-HTTP] How do I not specify the charset?

[Derek Wyatt]

I was able to verify that this is breaking the app in question, but not 
with Akka.  I merely added the charset to the request that was working, and 
it broke.

But I think I have a more fundamental problem: I can't see the raw request 
that came in from the client.  It, of course, is only represented using the 
Akka HTTP model and that model requires a charset for NonBinary 
ContentTypes.  So, if I wanted to try and force the outgoing request (to 
the server for which I am being a reverse-proxy) to match the incoming 
request in this regard, I wouldn't have enough information to know that I 
should do that.

Is there any way to get at the raw HTTP request so I can inspect it?  I 
think I need to see exactly how the client created it in the first place.

On Tuesday, September 13, 2016 at 12:58:15 PM UTC-4, Derek Wyatt wrote:
>
> Hi guys,
>
> I've written a reverse-proxy with Akka-HTTP and I'm hitting a problem 
> while trying to interact with an ASP.NET app.  The only interesting thing 
> I can see is that without the proxy, the Content-Type is lacking a charset 
> but the proxy adds charset=UTF-8.
>
> I can't find a way to replicate that using Akka HTTP.  I think we can all 
> agree that the addition of charset=UTF-8 is the right thing to do, but in 
> this case it may be causing us a problem and I'd like to force it to look 
> the same.  The best I've gotten so far is a definition where it has 
> 'charset=', which isn't quite right.
>
> Can this be done?
>

-- 
>>  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-HTTP] How do I not specify the charset?

[Viktor Klang]

"The "charset" parameter is used with some media types to define the
character set (section 3.4) of the data. When no explicit charset parameter
is provided by the sender, media subtypes of the "text" type are defined to
have a default charset value of "ISO-8859-1" when received via HTTP. Data
in character sets other than "ISO-8859-1" or its subsets MUST be labeled
with an appropriate charset value. See section 3.4.1
 for
compatibility problems."

https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7

-- 
Cheers,
√

On Sep 13, 2016 18:58, "Derek Wyatt"  wrote:

> Hi guys,
>
> I've written a reverse-proxy with Akka-HTTP and I'm hitting a problem
> while trying to interact with an ASP.NET app.  The only interesting thing
> I can see is that without the proxy, the Content-Type is lacking a charset
> but the proxy adds charset=UTF-8.
>
> I can't find a way to replicate that using Akka HTTP.  I think we can all
> agree that the addition of charset=UTF-8 is the right thing to do, but in
> this case it may be causing us a problem and I'd like to force it to look
> the same.  The best I've gotten so far is a definition where it has
> 'charset=', which isn't quite right.
>
> Can this be done?
>
> --
> >> 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] [Akka-HTTP] How do I not specify the charset?

[Derek Wyatt]

Hi guys,

I've written a reverse-proxy with Akka-HTTP and I'm hitting a problem while 
trying to interact with an ASP.NET app.  The only interesting thing I can 
see is that without the proxy, the Content-Type is lacking a charset but 
the proxy adds charset=UTF-8.

I can't find a way to replicate that using Akka HTTP.  I think we can all 
agree that the addition of charset=UTF-8 is the right thing to do, but in 
this case it may be causing us a problem and I'd like to force it to look 
the same.  The best I've gotten so far is a definition where it has 
'charset=', which isn't quite right.

Can this be done?

-- 
>>  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 Multithreading on Akka-Cluster

[silvio poma]

Hi Guido, can you suggest me some guide that explains the configuration 
changes that need to be done?
I've seen that with the M4 it was included the configuration for for usage 
with Docker, that is what i need.

Thanks Silvio

Il giorno mercoledì 7 settembre 2016 17:50:44 UTC+2, Guido Medina ha 
scritto:
>
> Artery is at  in milestone 3 (m3), you are welcome to use as I believe it 
> is in an extremely good shape but I would pursue both,
> as it will only require you a day of work (as a newbie) in configuration 
> and dependencies, no code changes will be required:
>
>
> http://search.maven.org/#artifactdetails%7Ccom.typesafe.akka%7Cakka-remote_2.11%7C2.4-ARTERY-M3%7Cjar
>
> As for dispatchers, be careful there, I didn't mean "one dispatcher per 
> actor" but more like "one dispatcher per one or more types of actors"
>
> HTH,
>
> Guido.
>
> On Wednesday, September 7, 2016 at 4:37:13 PM UTC+1, silvio poma wrote:
>>
>> Dear Guido,
>> Thanks a lot for you answer. 
>> We have already improved our concurrency model, using multiple instances 
>> for each actor, that now work in parallel using multiple dispatcher.
>> Now we have not so much time to release our product to the client. 
>> What do you suggest to focus our efforts on? 
>> Which of this two arguments can effectively improve the system efficiency?
>>
>> - Passing from Remote to Artery?
>> - Remove Java serializer and use another one?
>>
>> Thanks,
>> Looking forward to hear you.
>> Silvio
>>   
>>
>> Il giorno mercoledì 7 settembre 2016 11:16:08 UTC+2, Guido Medina ha 
>> scritto:
>>>
>>> Messages can be slow when being sent remotely from node A to node B,
>>> current Akka remote will give you a top of 100k msg/sec best scenario 
>>> and that depending on the message size,
>>> there is a new Akka remote (Akka artery which is a rewrite of Akka 
>>> remote) on the way so that shouldn't discourage you.
>>>
>>> Serialization is important, make sure you are not using the default Java 
>>> serialization, I suggest you to use Kryo for example.
>>>
>>> The fact that you are using actors doesn't really mean you are using 
>>> concurrency right, books like "Java concurrency in Practice" still apply, 
>>> you need to know how dispatchers work in Akka
>>> and how to spread your actors among dispatcher for specialized tasks, 
>>> also, you need to learn how to create several instances of the same actor 
>>> so that they act as workers,
>>> hence activating a proper level of concurrency.
>>>
>>> I think the main problem is that *-it is a common mistake by new Akka 
>>> users-* is to try to just throw actors at the problem and expect that 
>>> it will magically solve concurrency issues.
>>> You need to read the documentation and understand how actors, routers 
>>> and dispatchers can work together and how to combine them.
>>>
>>> If you are simply sending messages to one actor in a node you still have 
>>> a single threaded kind processor,
>>>
>>> I have tackled this kind of problem by creating several instances *-say 
>>> N x CPUs depending on the problem they are solving-*,
>>> send such list to a remote node and there create a dumb round-robin 
>>> router and use such router to send messages to such pool of actors,
>>> and then you will have some decent concurrency in that node, make sure 
>>> you use more than one dispatcher or else everything will be executed by the 
>>> same dispatcher,
>>> which translates to having a single thread pool executor doing 
>>> everything.
>>>
>>> http://doc.akka.io/docs/akka/2.4.10/java/dispatchers.html
>>> http://doc.akka.io/docs/akka/2.4.10/java/routing.html
>>>
>>> HTH,
>>>
>>> Guido.
>>>
>>> On Monday, September 5, 2016 at 11:58:47 AM UTC+1, silvio poma wrote:

 Dear Konrad,
 Thanks for your answer, our Actors didn't do anything that blocks the 
 system.
 One possible cause for our performance problem is that in our 
 "cluster-metrics-adaptive-group" router have just one routees associated 
 to 
 one actor (We have one actor for microsistem right now). We think to 
 increase the number of actor for each microsistem and consequencialy the 
 routees lists, is this a possible solution?
 If it is right to do so, there is a way to increase and decrease the 
 group without going directly inside the code, and leaves akka do so ?
 Thanks Silvio 

 Il giorno lunedì 5 settembre 2016 11:26:58 UTC+2, Konrad Malawski ha 
 scritto:
>
> This is not really enough information to say where or what the 
> bottlenecks are. If you need a full architecture overview that's a 
> commercial thing we can offer.
>
> Having that said, you did not mention what HTTP server you're using.
> Actors are simply multiplexed onto threads, so if you're doing 
> blocking in your actors you'll end up blocking the entire system - this 
> could be one of the reasons you're seeing bad perf and no parallelism.
> Another reason could be that you do all inside one 

[akka-user] Re: Debugging marshalling implicits

[Richard Rodseth]

Bump.

Is this the right way to debug the missing conversion?
val prm = implicitly[Future[PimpedResult[(StatusCode, Result[StatusDTO])]]
=> ToResponseMarshallable]


On Wed, Sep 7, 2016 at 8:43 PM, Richard Rodseth  wrote:

> Can anyone help me with this please?
> I have the following in my route:
>
> val result = (requestHandler ? RequestHandler.AskForStatus).
> mapTo[PimpedResult[(StatusCode, Result[StatusDTO])]]
>
> onSuccess(result) {
>   case _ => complete(result)
> }
>
> The mapTo is really just to assist my debugging. The result could be a
> Result[StatusDTO] or a PimpedResult.
> Anyway, I get the following error on the complete call:
>
> type mismatch; found : 
> scala.concurrent.Future[PimpedResult[(akka.http.scaladsl.model.StatusCode,
> Result[StatusDTO])]] (which expands to) scala.concurrent.Future[
> PimpedResult[(akka.http.scaladsl.model.StatusCode,
> scala.util.Either[APIError,StatusDTO])]] required: akka.http.scaladsl.
> marshalling.ToResponseMarshallable
>
> I added the following after the mapTo:
>
> val prm = implicitly[Future[PimpedResult[(StatusCode,
> Result[StatusDTO])]] => ToResponseMarshallable]
>
> and that line gets this error:
>
> Multiple markers at this line:
>
> not enough arguments for method implicitly: (implicit e:
> scala.concurrent.Future[PimpedResult[(akka.http.scaladsl.model.StatusCode,
> Result[StatusDTO])]] ⇒ akka.http.scaladsl.marshalling.
> ToResponseMarshallable)scala.concurrent.Future[PimpedResult[(akka.http.scaladsl.model.StatusCode,
> Result[StatusDTO])]] ⇒ akka.http.scaladsl.marshalling.ToResponseMarshallable.
> Unspecified value parameter e.
> No implicit view available from scala.concurrent.Future[
> PimpedResult[(akka.http.scaladsl.model.StatusCode, Result[StatusDTO])]] ⇒
> akka.http.scaladsl.marshalling.ToResponseMarshallable.
>
> Here is the custom marshaller. I know it's in scope because the
> errorMarshaller works in the case where the response is Result[StatusDTO]
> rather than PimpedResult
>
> // See https://bitbucket.org/binarycamp/spray-contrib/src
> trait APICustomMarshallers {
>
>   implicit def errorMarshaller[T](
> implicit translator: ErrorTranslator[T],
> statusCodeMapper: ErrorToStatusCodeMapper,
> m: ToEntityMarshaller[T]): ToResponseMarshaller[APIError] = {
>
> val base = PredefinedToResponseMarshallers.
> fromStatusCodeAndHeadersAndValue
> val result = base.compose {
>   error: APIError => 
> (statusCodeMapper.orElse(ErrorToStatusCodeMapper.Default)(error),
> DefaultHttpHeaders.NoCacheHeaders, translator(error))
> }
> result
>   }
>
>   implicit def statusMarshaller[T](implicit m: ToEntityMarshaller[T]):
> ToResponseMarshaller[PimpedResult[(StatusCode, T)]] = {
> val base = PredefinedToResponseMarshallers.
> fromStatusCodeAndHeadersAndValue // Needs the entity marshaller
> val result = base.compose {
>   pimpedResult: PimpedResult[(StatusCode, T)] =>
> pimpedResult.result match {
>   case Right(response) => (response._1, 
> DefaultHttpHeaders.NoCacheHeaders,
> response._2)
>   case _   => throw new RuntimeException("StatusMarshaller
> got invalid PimpedResult")
> }
> }
> result
>   }
> }
>
> Thanks for any help.
>
>
>
>
>

-- 
>>  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 Http Logging with traceId

[Arun]

Thanks Yann and Jan.

The kamon looks clean way of implementation, the page also talks about 
http://kamon.io/integrations/logback/mdc-in-an-asyncronous-environment/ 
 the way you have describe in your blog as well. 

I am going ahead with kamon.

Thanks to everyone. 

Regards,
Arun

On Tuesday, September 13, 2016 at 2:02:46 PM UTC+5:30, Yann Simon wrote:
>
> I don't think so.
> The source thread is the thread used to handle the message, as the log is 
> done in another actor (and maybe in another thread).
>
> Le mar. 13 sept. 2016 à 10:28, Arun  a 
> écrit :
>
>> Thanks Yann. Let me explore these options. 
>>
>> As per akka documentation 
>> http://doc.akka.io/docs/akka/2.4.10/scala/logging.html , can I use 
>> "sourceThread" 
>> as traceid?
>>
>> Regards,
>> Arun
>>
>> On Tuesday, September 13, 2016 at 1:23:48 PM UTC+5:30, Yann Simon wrote:
>>
>>> I wrote that some times ago: 
>>> http://yanns.github.io/blog/2014/05/04/slf4j-mapped-diagnostic-context-mdc-with-play-framework/
>>> I use a somewhat modified version of that, but it works only with 
>>> Futures.
>>> With actors (and akka-stream and akka-http), I think that you only have 
>>> 2 options:
>>> - use kamon.io
>>> - propagating a "context" yourself, and using a custom Logger that reads 
>>> from this context
>>>
>>> Yann
>>>
>>> Le mar. 13 sept. 2016 à 08:57, Arun  a écrit :
>>>
 Thanks Jan.

 I am looking for something similar to 
 http://code.hootsuite.com/logging-contextual-info-in-an-asynchronous-scala-application/
  
 , I could able to find that either by using custom akka dispatcher or 
 custom execution context, we can achieve the same, but I would prefer 
 anything I can do with minimal changes in akka default behaviour. 

 Using MDC with Logback; the logback uses a ThreadLocal variable and 
 this works when one thread is used for one request, in case of Akka 
 asynchronous communication happens across multiple threads.

 Thanks
 Arun

 On Tuesday, September 13, 2016 at 11:27:58 AM UTC+5:30, Jan Algermissen 
 wrote:

> Hi Arun
>
> Take a look at kamon.io
>
> Jan
>
> Sent from my iPhone
>

> On 13.09.2016, at 07:48, Arun  wrote:
>
> Hi,
>
> We have a requirement where we need to log information with traceId 
> (or unique identifier) for  a given HTTP request across route and actors. 
> This can help us to trace logging.
>
> The configuration is as following:
>
> akka {
>   loggers = ["akka.event.slf4j.Slf4jLogger"]
>   loglevel = "INFO"
>   logging-filter = "akka.event.slf4j.Slf4jLoggingFilter"
>
> }
>
>
> and logback.xml is as following:
>
>
> 
> 
> 
> true
> 
> @timestamp
> msg
> [ignore]
> [ignore]
> logger
> [ignore]
> 
>  class="net.logstash.logback.stacktrace.ShortenedThrowableConverter">
> 80
> 2048
> 20
>   true
> 
> 
> 
> 
> 
> 
> 
>
>
> Please let me know how we can enable traceId from route to actor systems.
>
>
> Thanks
>
> Arun
>
> -- 
> >> 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+...@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/
>> 

Re: [akka-user] Akka Multithreading on Akka-Cluster

[silvio poma]

I have an http endpoint with a consumerActor (in Node 0) that read the msg 
from the camel msg and with it create our Message.class than it send to a 
router1 that forward to one of "N" Worker1 in Node 1, Worker1 make a query 
on Couchbase process the result and send the Message.class to to a router2 
that forward to one of "N" Worker2 in Node 2, Worker2 make a query on 
Couchbase process the result and send the Message.class to to a router3 
that forward to one of "N" Worker3 in Node 3, at the end Worker3 make a 
query on Couchbase process the result and send the http response. 

Il giorno martedì 13 settembre 2016 10:42:39 UTC+2, √ ha scritto:
>
> What is your bottleneck?
>
> On Tue, Sep 13, 2016 at 10:13 AM, silvio poma  > wrote:
>
>> Thanks guy, I eventually fixed all the configuration as you suggested and 
>> now everything is working.
>> I can see a big improvement in the average time of response of my service 
>> but the throughput is still the same of before.
>> Any other suggestions, my target is to have throughput as high as 
>> possible?
>>
>> Thanks for yours tips!
>> Silvio 
>>
>>
>> Il giorno sabato 10 settembre 2016 12:11:35 UTC+2, Guido Medina ha 
>> scritto:
>>>
>>> Your contribution makes ID strategy automatic even better, you know 
>>> automatic = explicit + incremental right?
>>> So I think it would also work for your project, but I do understand why 
>>> you have chosen explicit as you want to fail if you introduce a new class 
>>> and forget to register it.
>>>
>>> I use automatic because I only register classes I need extremely 
>>> optimize in regards of message size over the wire which is important from 
>>> the low latency PoV,
>>> I believe your contribution should also work with automatic? do you 
>>> happen to know if it is tied to explicit or to the phase of registering 
>>> listed classes?
>>>
>>> If the latter then I believe it should also apply to automatic listed 
>>> classes to register.
>>>
>>> Guido.
>>>
>>> On Friday, September 9, 2016 at 8:36:54 PM UTC+1, Justin du coeur wrote:

 On Fri, Sep 9, 2016 at 2:51 PM, Guido Medina  wrote:

> The problem with explicit is that there are so many "trait" and 
> "classes" not really registered which is why I use it,
> it is the newest ID strategy as it register things you might not care 
> but commonly used messages you register,
> that way you get performance for what is important and automatic 
> registration for other things.
>

 Yeah -- like I said, hardcore.  But my situation is extreme: I'm using 
 Kryo for *persistent* serialization -- as far as I know, Querki may be the 
 first project doing that in production.  That being the case, I care about 
 the bytes taken up by FQDNs (and the time required to look them up, and 
 the 
 risks of things changing out from under me), so I've built out quite a 
 bit 
 
  of 
 infrastructure 
 
  
 to make this work safely.

 (Yes, I know -- I'm insane.  But I like Kryo's attitude more than 
 protobuf's from a code-cohesion POV, so I've invested the time to make it 
 work solidly for Akka Persistence.)

 *Totally* understood about the sheer number of classes involved in 
 making this work -- I spent quite a while wrestling with that.  But note 
 that I contributed a new feature to the romix library 
 
  
 to help with this.  The SubclassResolver allows you to register a single 
 serializer for an entire type hierarchy, when that makes sense.  (Which it 
 does for many of the common library types.)  I found that this cuts down 
 on 
 the number of "overhead" registrations required by a *huge* fraction -- 
 you 
 can suddenly deal with, eg, Set with a single registration instead of six.

 And yes, I need to find some time to write up a long blog post about 
 all of this...

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

Re: [akka-user] Akka Multithreading on Akka-Cluster

[Viktor Klang]

What is your bottleneck?

On Tue, Sep 13, 2016 at 10:13 AM, silvio poma 
wrote:

> Thanks guy, I eventually fixed all the configuration as you suggested and
> now everything is working.
> I can see a big improvement in the average time of response of my service
> but the throughput is still the same of before.
> Any other suggestions, my target is to have throughput as high as possible?
>
> Thanks for yours tips!
> Silvio
>
>
> Il giorno sabato 10 settembre 2016 12:11:35 UTC+2, Guido Medina ha scritto:
>>
>> Your contribution makes ID strategy automatic even better, you know
>> automatic = explicit + incremental right?
>> So I think it would also work for your project, but I do understand why
>> you have chosen explicit as you want to fail if you introduce a new class
>> and forget to register it.
>>
>> I use automatic because I only register classes I need extremely optimize
>> in regards of message size over the wire which is important from the low
>> latency PoV,
>> I believe your contribution should also work with automatic? do you
>> happen to know if it is tied to explicit or to the phase of registering
>> listed classes?
>>
>> If the latter then I believe it should also apply to automatic listed
>> classes to register.
>>
>> Guido.
>>
>> On Friday, September 9, 2016 at 8:36:54 PM UTC+1, Justin du coeur wrote:
>>>
>>> On Fri, Sep 9, 2016 at 2:51 PM, Guido Medina  wrote:
>>>
 The problem with explicit is that there are so many "trait" and
 "classes" not really registered which is why I use it,
 it is the newest ID strategy as it register things you might not care
 but commonly used messages you register,
 that way you get performance for what is important and automatic
 registration for other things.

>>>
>>> Yeah -- like I said, hardcore.  But my situation is extreme: I'm using
>>> Kryo for *persistent* serialization -- as far as I know, Querki may be the
>>> first project doing that in production.  That being the case, I care about
>>> the bytes taken up by FQDNs (and the time required to look them up, and the
>>> risks of things changing out from under me), so I've built out quite a
>>> bit
>>> 
>>>  of
>>> infrastructure
>>> 
>>> to make this work safely.
>>>
>>> (Yes, I know -- I'm insane.  But I like Kryo's attitude more than
>>> protobuf's from a code-cohesion POV, so I've invested the time to make it
>>> work solidly for Akka Persistence.)
>>>
>>> *Totally* understood about the sheer number of classes involved in
>>> making this work -- I spent quite a while wrestling with that.  But note
>>> that I contributed a new feature to the romix library
>>> 
>>> to help with this.  The SubclassResolver allows you to register a single
>>> serializer for an entire type hierarchy, when that makes sense.  (Which it
>>> does for many of the common library types.)  I found that this cuts down on
>>> the number of "overhead" registrations required by a *huge* fraction -- you
>>> can suddenly deal with, eg, Set with a single registration instead of six.
>>>
>>> And yes, I need to find some time to write up a long blog post about all
>>> of this...
>>>
>> --
> >> 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] Cluster seed nodes resulting in multiple split brains?

[Patrik Nordwall]

How do you then handle node crashes and other unexpected failures?

It's right that we strongly recommend against auto-down, but you must still
use something. I hope that is not completely unclear in the documentation:
http://doc.akka.io/docs/akka/2.4/scala/cluster-usage.html#Downing

On Mon, Sep 12, 2016 at 6:06 PM, kraythe  wrote:

> All I do is issue a Cluster.get(system).leave(cluster.selfAddress)
>
> On Monday, September 12, 2016 at 9:49:22 AM UTC-5, √ wrote:
>>
>> What are you using/doing for downing?
>>
>> On Mon, Sep 12, 2016 at 4:13 PM, kraythe  wrote:
>>
>>> No, we have disabled that as per suggestion in the docs. Should we?
>>>
>>> --
>>> >>  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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend  -  Reactive apps on the JVM
Twitter: @patriknw

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

Re: [akka-user] Akka Http Logging with traceId

[Yann Simon]

I don't think so.
The source thread is the thread used to handle the message, as the log is
done in another actor (and maybe in another thread).

Le mar. 13 sept. 2016 à 10:28, Arun  a écrit :

> Thanks Yann. Let me explore these options.
>
> As per akka documentation
> http://doc.akka.io/docs/akka/2.4.10/scala/logging.html , can I use 
> "sourceThread"
> as traceid?
>
> Regards,
> Arun
>
> On Tuesday, September 13, 2016 at 1:23:48 PM UTC+5:30, Yann Simon wrote:
>
>> I wrote that some times ago:
>> http://yanns.github.io/blog/2014/05/04/slf4j-mapped-diagnostic-context-mdc-with-play-framework/
>> I use a somewhat modified version of that, but it works only with Futures.
>> With actors (and akka-stream and akka-http), I think that you only have 2
>> options:
>> - use kamon.io
>> - propagating a "context" yourself, and using a custom Logger that reads
>> from this context
>>
>> Yann
>>
>> Le mar. 13 sept. 2016 à 08:57, Arun  a écrit :
>>
>>> Thanks Jan.
>>>
>>> I am looking for something similar to
>>> http://code.hootsuite.com/logging-contextual-info-in-an-asynchronous-scala-application/
>>> , I could able to find that either by using custom akka dispatcher or
>>> custom execution context, we can achieve the same, but I would prefer
>>> anything I can do with minimal changes in akka default behaviour.
>>>
>>> Using MDC with Logback; the logback uses a ThreadLocal variable and this
>>> works when one thread is used for one request, in case of Akka asynchronous
>>> communication happens across multiple threads.
>>>
>>> Thanks
>>> Arun
>>>
>>> On Tuesday, September 13, 2016 at 11:27:58 AM UTC+5:30, Jan Algermissen
>>> wrote:
>>>
 Hi Arun

 Take a look at kamon.io

 Jan

 Sent from my iPhone

>>>
 On 13.09.2016, at 07:48, Arun  wrote:

 Hi,

 We have a requirement where we need to log information with traceId (or
 unique identifier) for  a given HTTP request across route and actors. This
 can help us to trace logging.

 The configuration is as following:

 akka {
   loggers = ["akka.event.slf4j.Slf4jLogger"]
   loglevel = "INFO"
   logging-filter = "akka.event.slf4j.Slf4jLoggingFilter"

 }


 and logback.xml is as following:


 
 
 
 true
 
 @timestamp
 msg
 [ignore]
 [ignore]
 logger
 [ignore]
 
 >>> class="net.logstash.logback.stacktrace.ShortenedThrowableConverter">
 80
 2048
 20
   true
 
 
 
 
 
 
 


 Please let me know how we can enable traceId from route to actor systems.


 Thanks

 Arun

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

Re: [akka-user] Akka Http Logging with traceId

[Arun]

Thanks Yann. Let me explore these options. 

As per akka 
documentation http://doc.akka.io/docs/akka/2.4.10/scala/logging.html , can 
I use "sourceThread" as traceid?

Regards,
Arun

On Tuesday, September 13, 2016 at 1:23:48 PM UTC+5:30, Yann Simon wrote:
>
> I wrote that some times ago: 
> http://yanns.github.io/blog/2014/05/04/slf4j-mapped-diagnostic-context-mdc-with-play-framework/
> I use a somewhat modified version of that, but it works only with Futures.
> With actors (and akka-stream and akka-http), I think that you only have 2 
> options:
> - use kamon.io
> - propagating a "context" yourself, and using a custom Logger that reads 
> from this context
>
> Yann
>
> Le mar. 13 sept. 2016 à 08:57, Arun  a 
> écrit :
>
>> Thanks Jan.
>>
>> I am looking for something similar to 
>> http://code.hootsuite.com/logging-contextual-info-in-an-asynchronous-scala-application/
>>  
>> , I could able to find that either by using custom akka dispatcher or 
>> custom execution context, we can achieve the same, but I would prefer 
>> anything I can do with minimal changes in akka default behaviour. 
>>
>> Using MDC with Logback; the logback uses a ThreadLocal variable and this 
>> works when one thread is used for one request, in case of Akka asynchronous 
>> communication happens across multiple threads.
>>
>> Thanks
>> Arun
>>
>> On Tuesday, September 13, 2016 at 11:27:58 AM UTC+5:30, Jan Algermissen 
>> wrote:
>>
>>> Hi Arun
>>>
>>> Take a look at kamon.io
>>>
>>> Jan
>>>
>>> Sent from my iPhone
>>>
>>
>>> On 13.09.2016, at 07:48, Arun  wrote:
>>>
>>> Hi,
>>>
>>> We have a requirement where we need to log information with traceId (or 
>>> unique identifier) for  a given HTTP request across route and actors. This 
>>> can help us to trace logging.
>>>
>>> The configuration is as following:
>>>
>>> akka {
>>>   loggers = ["akka.event.slf4j.Slf4jLogger"]
>>>   loglevel = "INFO"
>>>   logging-filter = "akka.event.slf4j.Slf4jLoggingFilter"
>>>
>>> }
>>>
>>>
>>> and logback.xml is as following:
>>>
>>>
>>> 
>>> 
>>> 
>>> true
>>> 
>>> @timestamp
>>> msg
>>> [ignore]
>>> [ignore]
>>> logger
>>> [ignore]
>>> 
>>> >> class="net.logstash.logback.stacktrace.ShortenedThrowableConverter">
>>> 80
>>> 2048
>>> 20
>>>   true
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>
>>>
>>> Please let me know how we can enable traceId from route to actor systems.
>>>
>>>
>>> Thanks
>>>
>>> Arun
>>>
>>> -- 
>>> >> 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+...@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] Akka Multithreading on Akka-Cluster

[silvio poma]

Thanks guy, I eventually fixed all the configuration as you suggested and 
now everything is working.
I can see a big improvement in the average time of response of my service 
but the throughput is still the same of before.
Any other suggestions, my target is to have throughput as high as possible?

Thanks for yours tips!
Silvio 


Il giorno sabato 10 settembre 2016 12:11:35 UTC+2, Guido Medina ha scritto:
>
> Your contribution makes ID strategy automatic even better, you know 
> automatic = explicit + incremental right?
> So I think it would also work for your project, but I do understand why 
> you have chosen explicit as you want to fail if you introduce a new class 
> and forget to register it.
>
> I use automatic because I only register classes I need extremely optimize 
> in regards of message size over the wire which is important from the low 
> latency PoV,
> I believe your contribution should also work with automatic? do you happen 
> to know if it is tied to explicit or to the phase of registering listed 
> classes?
>
> If the latter then I believe it should also apply to automatic listed 
> classes to register.
>
> Guido.
>
> On Friday, September 9, 2016 at 8:36:54 PM UTC+1, Justin du coeur wrote:
>>
>> On Fri, Sep 9, 2016 at 2:51 PM, Guido Medina  wrote:
>>
>>> The problem with explicit is that there are so many "trait" and 
>>> "classes" not really registered which is why I use it,
>>> it is the newest ID strategy as it register things you might not care 
>>> but commonly used messages you register,
>>> that way you get performance for what is important and automatic 
>>> registration for other things.
>>>
>>
>> Yeah -- like I said, hardcore.  But my situation is extreme: I'm using 
>> Kryo for *persistent* serialization -- as far as I know, Querki may be the 
>> first project doing that in production.  That being the case, I care about 
>> the bytes taken up by FQDNs (and the time required to look them up, and the 
>> risks of things changing out from under me), so I've built out quite a 
>> bit 
>> 
>>  of 
>> infrastructure 
>> 
>>  
>> to make this work safely.
>>
>> (Yes, I know -- I'm insane.  But I like Kryo's attitude more than 
>> protobuf's from a code-cohesion POV, so I've invested the time to make it 
>> work solidly for Akka Persistence.)
>>
>> *Totally* understood about the sheer number of classes involved in making 
>> this work -- I spent quite a while wrestling with that.  But note that I 
>> contributed a new feature to the romix library 
>> 
>>  
>> to help with this.  The SubclassResolver allows you to register a single 
>> serializer for an entire type hierarchy, when that makes sense.  (Which it 
>> does for many of the common library types.)  I found that this cuts down on 
>> the number of "overhead" registrations required by a *huge* fraction -- you 
>> can suddenly deal with, eg, Set with a single registration instead of six.
>>
>> And yes, I need to find some time to write up a long blog post about all 
>> of this...
>>
>

-- 
>>  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 Http Logging with traceId

[Konrad Malawski]

Reactive Monitoring is able to propagate MDC across Actors:
https://www.lightbend.com/products/monitoring

-- 
Konrad `ktoso` Malawski
Akka  @ Lightbend 

On 13 September 2016 at 08:57:24, Arun (sethia.a...@gmail.com) wrote:

Thanks Jan.

I am looking for something similar to
http://code.hootsuite.com/logging-contextual-info-in-an-asynchronous-scala-application/
, I could able to find that either by using custom akka dispatcher or
custom execution context, we can achieve the same, but I would prefer
anything I can do with minimal changes in akka default behaviour.

Using MDC with Logback; the logback uses a ThreadLocal variable and this
works when one thread is used for one request, in case of Akka asynchronous
communication happens across multiple threads.

Thanks
Arun

On Tuesday, September 13, 2016 at 11:27:58 AM UTC+5:30, Jan Algermissen
wrote:
>
> Hi Arun
>
> Take a look at kamon.io
>
> Jan
>
> Sent from my iPhone
>
> On 13.09.2016, at 07:48, Arun  wrote:
>
> Hi,
>
> We have a requirement where we need to log information with traceId (or
> unique identifier) for  a given HTTP request across route and actors. This
> can help us to trace logging.
>
> The configuration is as following:
>
> akka {
>   loggers = ["akka.event.slf4j.Slf4jLogger"]
>   loglevel = "INFO"
>   logging-filter = "akka.event.slf4j.Slf4jLoggingFilter"
>
> }
>
>
> and logback.xml is as following:
>
>
> 
> 
> 
> true
> 
> @timestamp
> msg
> [ignore]
> [ignore]
> logger
> [ignore]
> 
>  class="net.logstash.logback.stacktrace.ShortenedThrowableConverter">
> 80
> 2048
> 20
>   true
> 
> 
> 
> 
> 
> 
> 
>
>
> Please let me know how we can enable traceId from route to actor systems.
>
>
> Thanks
>
> Arun
>
> --
> >> 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.

-- 
>>  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 Http Logging with traceId

[Yann Simon]

I wrote that some times ago:
http://yanns.github.io/blog/2014/05/04/slf4j-mapped-diagnostic-context-mdc-with-play-framework/
I use a somewhat modified version of that, but it works only with Futures.
With actors (and akka-stream and akka-http), I think that you only have 2
options:
- use kamon.io
- propagating a "context" yourself, and using a custom Logger that reads
from this context

Yann

Le mar. 13 sept. 2016 à 08:57, Arun  a écrit :

> Thanks Jan.
>
> I am looking for something similar to
> http://code.hootsuite.com/logging-contextual-info-in-an-asynchronous-scala-application/
> , I could able to find that either by using custom akka dispatcher or
> custom execution context, we can achieve the same, but I would prefer
> anything I can do with minimal changes in akka default behaviour.
>
> Using MDC with Logback; the logback uses a ThreadLocal variable and this
> works when one thread is used for one request, in case of Akka asynchronous
> communication happens across multiple threads.
>
> Thanks
> Arun
>
> On Tuesday, September 13, 2016 at 11:27:58 AM UTC+5:30, Jan Algermissen
> wrote:
>
>> Hi Arun
>>
>> Take a look at kamon.io
>>
>> Jan
>>
>> Sent from my iPhone
>>
>
>> On 13.09.2016, at 07:48, Arun  wrote:
>>
>> Hi,
>>
>> We have a requirement where we need to log information with traceId (or
>> unique identifier) for  a given HTTP request across route and actors. This
>> can help us to trace logging.
>>
>> The configuration is as following:
>>
>> akka {
>>   loggers = ["akka.event.slf4j.Slf4jLogger"]
>>   loglevel = "INFO"
>>   logging-filter = "akka.event.slf4j.Slf4jLoggingFilter"
>>
>> }
>>
>>
>> and logback.xml is as following:
>>
>>
>> 
>> 
>> 
>> true
>> 
>> @timestamp
>> msg
>> [ignore]
>> [ignore]
>> logger
>> [ignore]
>> 
>> > class="net.logstash.logback.stacktrace.ShortenedThrowableConverter">
>> 80
>> 2048
>> 20
>>   true
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>
>>
>> Please let me know how we can enable traceId from route to actor systems.
>>
>>
>> Thanks
>>
>> Arun
>>
>> --
>> >> 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.
>

-- 
>>  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 Http Logging with traceId

[Arun]

Thanks Jan.

I am looking for something similar 
to 
http://code.hootsuite.com/logging-contextual-info-in-an-asynchronous-scala-application/
 
, I could able to find that either by using custom akka dispatcher or 
custom execution context, we can achieve the same, but I would prefer 
anything I can do with minimal changes in akka default behaviour. 

Using MDC with Logback; the logback uses a ThreadLocal variable and this 
works when one thread is used for one request, in case of Akka asynchronous 
communication happens across multiple threads.

Thanks
Arun

On Tuesday, September 13, 2016 at 11:27:58 AM UTC+5:30, Jan Algermissen 
wrote:
>
> Hi Arun
>
> Take a look at kamon.io
>
> Jan
>
> Sent from my iPhone
>
> On 13.09.2016, at 07:48, Arun  wrote:
>
> Hi,
>
> We have a requirement where we need to log information with traceId (or 
> unique identifier) for  a given HTTP request across route and actors. This 
> can help us to trace logging.
>
> The configuration is as following:
>
> akka {
>   loggers = ["akka.event.slf4j.Slf4jLogger"]
>   loglevel = "INFO"
>   logging-filter = "akka.event.slf4j.Slf4jLoggingFilter"
>
> }
>
>
> and logback.xml is as following:
>
>
> 
> 
> 
> true
> 
> @timestamp
> msg
> [ignore]
> [ignore]
> logger
> [ignore]
> 
>  class="net.logstash.logback.stacktrace.ShortenedThrowableConverter">
> 80
> 2048
> 20
>   true
> 
> 
> 
> 
> 
> 
> 
>
>
> Please let me know how we can enable traceId from route to actor systems.
>
>
> Thanks
>
> Arun
>
> -- 
> >> 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.