Hi, Ivan You could check my reply to Konrad about the use case.
I'm just guessing that your TraceLocalStorage is essentially a map just like threadlocal, right? threadlocal: use thread id as hash key TraceLocalStorage : some unique id like uuid?? If I'd like to get some request level related data in any of the message receiver within the whole request-response life-cycle, shall I need to carry on this "key" all along with my messages? Thanks Leon 在 2014年5月30日星期五UTC-7上午7时56分44秒，Ivan Topolnjak写道： > > Leon, > > I'm not sure about what is the data that you want to pass around, but we > (Kamon) developed something that we call "TraceLocalStorage", that > effectively is like a implementation of ThreadLocals for actors, let me > explain a bit the motivations on that: in my current workplace we have a > lot of applications and all of them communicate using HTTP, so when you get > a request there will be some extra headers with tracing/client/etc > information that regardless of whether you use them or not, you need to > pass to other applications when asking for something. This data is > important since it helps us monitor and trace how things are behaving, but > it has nothing to do with business logic and if we fail to propagate that > information we will have less monitoring data, but still out customers will > be happy. In our previous generation apps ThreadLocals served well, now the > TraceLocalStorage is on duty for our reactive apps :). > > Beware that our intention is to allow passing data that is *not related to > business logic*, so in case that Kamon is not available your app will still > be running fine, if something is required by your business logic to work > properly it should be encoded in the message protocol you use with your > actors. If you want to get an idea of how to use it you can take a look at > the tests [1] and use the "0.3.1-2f0bf70826cfde49e980d362179717314290b6f1" > version that we published a few days ago in our snapshots repo [2]. If you > need any additional help, head over to our mailing list [3], hope that this > info helps, best regards! > > > [1] > https://github.com/kamon-io/Kamon/blob/master/kamon-core/src/test/scala/kamon/trace/TraceLocalSpec.scala > [2] http://snapshots.kamon.io/ > [3] https://groups.google.com/forum/#!forum/kamon-user > > > > On Fri, May 30, 2014 at 7:59 AM, Konrad Malawski <[email protected] > <javascript:>> wrote: > >> The thread local stuff is quite "scary" in an Actor setting by the way >> and if possible it would be best to work around it (in a way other than >> setCurrentThreadId - I'm guessing that's your current impl?). >> Would you be able to construct MDC on your own, bypassing the >> threadlocals? >> >> >> On Fri, May 30, 2014 at 12:57 PM, Konrad Malawski <[email protected] >> <javascript:>> wrote: >> >>> So metrics. >>> I would suggest piggybacking on kamon: http://kamon.io/ >>> Since the guys have many of the things figured out already - it's open >>> source so it should be possible to either get metrics from their pointcuts >>> or piggyback in some other way. >>> >>> >>> On Fri, May 30, 2014 at 11:58 AM, Leon Ma <[email protected] >>> <javascript:>> wrote: >>> >>>> My case is actually to pass some information like Mapped Diagnostic >>>> Context. >>>> >>>> Some of my legacy java code is using threadlocal to carry on those MDC >>>> information, that's why I need a way to: >>>> >>>> intercept "tell" : collect threadlocal information and do some wrapping >>>> like MDCCtx(mymessage, threadLocalInfoThatINeed) >>>> intercept "receive" : unwrapper MDCCtx, recover thread local info. >>>> >>>> Thanks >>>> >>>> Leon >>>> >>>> >>>> >>>> >>>> >>>> 在 2014年5月29日星期四UTC+8下午11时27分01秒，Konrad Malawski写道： >>>> >>>>> Hello Leon, >>>>> Well, "the Scala way"™ would rather be using plain total or partial >>>>> functions and composing them - I believe that's what whoever the quoted >>>>> sentence comes from had in mind. >>>>> In Akka we also believe that less magic is better :-) >>>>> >>>>> I would therefore suggest you to try modelling your required behaviour >>>>> in terms of functions instead of aspects. >>>>> What's your use case? >>>>> >>>>> >>>>> -- >>>>> Cheers, >>>>> Konrad 'ktoso' Malawski >>>>> hAkker - Typesafe, Inc >>>>> >>>>> <http://scaladays.org> >>>>> >>>> -- >>>> >>>>>>>>>> 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 [email protected] <javascript:>. >>>> To post to this group, send email to [email protected] >>>> <javascript:>. >>>> Visit this group at http://groups.google.com/group/akka-user. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Cheers, >>> Konrad 'ktoso' Malawski >>> hAkker - Typesafe, Inc >>> >>> <http://scaladays.org> >>> >> >> >> >> -- >> Cheers, >> Konrad 'ktoso' Malawski >> hAkker - Typesafe, Inc >> >> <http://scaladays.org> >> >> -- >> >>>>>>>>>> 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
