Re: [akka-user] Role of Akka in SMACK

['Ryan Tanner' via Akka User List]

Be careful with Flink.  IME it's got a long way to go.  The core model is 
fantastic but there's a lot of low-hanging fruit that needs to be fixed.

On Tuesday, May 2, 2017 at 4:03:12 PM UTC-6, Evan Chan wrote:
>
> Hi Shiva,
>
> Spark will likely be too high latency for you.  Practical minimal batch 
> size is a couple seconds.
>
> Think of Akka as a best fit for if you want to deploy individual apps each 
> reading from some set of fixed Kafka partitions.  Each one could then write 
> to HDFS.  However you would need to handle failover, state, etc. etc.
> It is likely that Flink has much more built in for you - HDFS integration, 
> checkpointing, failover, shuffling/routing of messages, integration with 
> Kafka, etc.
>
> You might want to look into Intel Gearpump - this is Akka-based very low 
> latency dynamic stream processing, and they have handled distribution 
> already.
>
> -Evan
>
> On Friday, April 28, 2017 at 7:52:50 AM UTC-7, Shivakumar Ramagopal wrote:
>>
>> Viktor,
>>
>>
>> On Fri, Apr 28, 2017 at 5:03 PM, Viktor Klang  
>> wrote:
>>
>>>
>>>
>>> On Fri, Apr 28, 2017 at 1:12 PM, Shiva Ramagopal  
>>> wrote:
>>>
 Hi Viktor,

 On Fri, Apr 28, 2017 at 2:55 PM, Viktor Klang  
 wrote:

> Hi Shiva,
>
> On Fri, Apr 28, 2017 at 11:20 AM, Shiva Ramagopal  
> wrote:
>
>> I'm looking to compare Kafka Streams vs Akka Streams in two areas: 
>>
>> 1. For ingesting between Kafka and HDFS/RDBMS 
>>
>> Requirements are mainly around performance and latency. A Kafka topic 
>> can have several million events, each corresponding to a database change 
>> capture. When ingesting this topic into HDFS I'm also looking to 
>> partition 
>> the data by day, typically based on a timestamp field in the event 
>> record, 
>> aggregations on-the-fly (say by a userid field) and parquetizing 
>> (preferably on the fly to optimize performance by reducing two I/O 
>> operations).
>>
>
> Looking forward to see your benchmark!
>

 Hey, you wanted requirements! :) 

>  
>
>>
>> 2. Low-latency processing
>>
>> Experiences around performances of Storm/Flink and Akka Streams would 
>> be *very* nice. Typical use-cases are de-duping and enrichment with 
>> metrics 
>> computation (# duplicate events/records, aggregate metrics etc). Low 
>> latency and scalability are main considerations
>>
>
> Low latency is not a metric, and scalability is not a profile. :)
> In other words: What latency distribution are you targeting and what 
> scalability curve?
>

 I know latency is a nuanced topic. I'm just looking for broad 
 experiences on performance comparisons if anyone has done that. Currently 
 we have a Storm topology over 5 nodes doing enrichment of events from 
 Kafka 
 that involves a lookup into a db per event. 90th percentile of latency of 
 this processing is under 200 ms and we are happy with this. While Storm is 
 mature, Akka Streams seems more general purpose than Storm. I'd like to 
 use 
 Akka Streams for this reason if performance is comparable to Storm. 

>>>
>>> There's one important architectural difference here tho: Akka Streams 
>>> are local-only (as in materialization). You can of course materialize Akka 
>>> Streams on multiple nodes and use a transport to coordinate data 
>>> processing. Interestingly it doesn't lock you in to a particular backend 
>>> such that Kafka Streams or even Storm would do.
>>>
>>
>> The materialization part was something I was not aware of. Thanks for 
>> pointing it out, really appreciate it.
>>
>>>
>>> All of this boils down to requirements. Something like Flink or Google 
>>> Beam could be viable options here as well. In your situation I'd look at 
>>> the requirements and make a couple of prototypes before picking a winner.
>>>
>>
>> I was also looking for something to unify batch and streaming - which is 
>> how I came to look at SMACK. I'd really like to keep the tech stack small 
>> and have the parts integrate tightly with each other. Guess I have to pick 
>> between Spark, Flink, Beam and Storm. 
>>
>>>  
>>>
  

>  
>
>>
>> On Thu, Apr 27, 2017 at 8:31 PM, Viktor Klang  
>> wrote:
>>
>>>
>>>
>>> On Thu, Apr 27, 2017 at 10:39 AM, Shiva Ramagopal  
>>> wrote:
>>>
 Hi,

 I have read through multiple articles describing the SMACK stack 
 but I'm having difficulty understanding the role of Akka in the stack. 
 How 
 does Akka fit in?

>>>
>>> Akka is for building the application itself.
>>>  
>>>

 Also I would like to know of experiences in using Akka Streams vs 
 Kafka Connect for ingesting from 

[akka-user] Re: Best way to handle large response from Actor

['Ryan Tanner' via Akka User List]

Two possibilities:

1. Go out-of-band and drop down to Http using, say, Netty.  Flink does this 
(it uses Akka remoting for command-and-control but transmits data using 
Netty).

2. Stick the files on a blob store like S3 and just send messages telling 
the other actor a file is available (or whatever the relevant event is). 
 Note that S3's consistency guarantees make this tricky as you can't assume 
the remote actor will be able to read a file you just wrote so you'll need 
retries and proper failure handling.

On Thursday, April 27, 2017 at 2:46:25 AM UTC-6, Sumanta Dutta wrote:
>
> Hi, we generally use ask pattern to handle request-response between client 
> and Akka Cluster. The client waits on the Future. We have a need where the 
> response size (~150MB) is too large to fit in one message even after 
> increasing message-frame-size to -
>
> maximum-payload-bytes = 5000 bytes
> netty.tcp {
>   message-frame-size = 5000b
>   send-buffer-size = 5000b
>   receive-buffer-size = 5000b
>   maximum-frame-size = 5000b
> }
>
> We don't like keep increasing the above limits. So one possibility is to 
> break the response in small chunks, but then how to handle on the Future 
> side using the ask pattern. The other possibility may be to use GraphStage 
> between Actors to stream the response back. Is that a viable solution? Is 
> there any example out there?
>
> Thanks,
> Sumanta
>

-- 
>>  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: Has akka-http has abandoned per request actors in favor an anti-pattern DSL?

['Ryan Tanner' via Akka User List]

Leaving aside the tone of this post...

Have you looked at the longer example of the DSL?

http://doc.akka.io/docs/akka-http/current/scala/http/routing-dsl/index.html#longer-example

It has examples of how to delegate an endpoint's business logic off to 
actors or futures.

On Sunday, April 2, 2017 at 7:09:32 PM UTC-6, kraythe wrote:
>
> I was really excited about akka-http as I would be able to unburden my 
> code from the baggage of play and handle my server side as a pure akka 
> actors app but unless I am much mistaken something is dreadfully amiss with 
> the implementation. 
>
> One of the main core features is the actor paradigm and the integration of 
> a rich actor system. However, the preferred approach to akka-http seems to 
> be a throwback to one file programming. The main reason it seems this way 
> is the DSL. Take this example from a tutorial: 
>
>  path("bank" / IntNumber) { id =>
> get {
>   complete {
> getById(id).map{result =>
>   if(result.isDefined)
>   HttpResponse(entity =write(result.get))
>   else
> HttpResponse(entity ="This bank does not exist")
> }
>
>
>   }
> }
>   }~
> path("bank" / "update") {
>   post {
> entity(as[String]) { bankJson =>
>   complete {
> val bank =parse(bankJson).extract[Bank]
> update(bank).map{result => HttpResponse(entity ="Bank has 
>  been updated successfully")}
>   }
> }
>   }
> }
> }
>   }
>
>
> Simple enough right? Too me I see the start of an anti-pattern but lets 
> look further. It gets worse though, quickly,  as shown in the akka-http 
> documentation here 
> .
>  
> Still not bothered? The problem is that these examples are shallow and not 
> rooted in the real world. In the bank application above would be hundreds 
> of endpoints and each endpoint would have to validate data send by the 
> user, check to see whether that data correct against the database and a 
> dozen other things that would alter the nature of the return type to a  bad 
> request or internal error. The banking app would also have to log the 
> problems so forensics can be done on malicious users. Just taking one route 
> "deposit" would be several hundred lines of code INSIDE the route. However, 
> it seems that there is no way to break off the route, offload it to another 
> component (such as a Per Request Actor) and then continue the DSL where you 
> left off. I had the chance to see for an app in another company that was 
> asking my advice and their route is 12k lines long and at one point nested 
> 30 levels deep.
>
> Now I know what you might say, "But Robert, you can break up the route 
> into multiple files" which is true but something has to manually 
> concatenate all of those routes together and they cant be done off of the 
> main route. once you are in the routes DSL you are stuck there. Sure, you 
> can call an actor with a future to do a completion but that actor itself 
> might return data that requires a different kind of completion based upon 
> certain criteria such as whether the user has had their account suspended. 
> So if your completions are diverse, how do you break up the route? 
>
> Now if someone has answers to these issues I would love to hear them but 
> after researching I found that basically PRA's are deprecated in favor of a 
> "convenient" DSL that entraps the user. For my purposes I opted to go with 
> the low level API and factor off the route dispatching to a routing actor 
> (yes, I know this is what the materializer does) and then just pull out 
> route data the old fashioned way. My router,  does path checking and then 
> dispatches to another actor to handle that specific request and then sends 
> the HttpResponse entity back to the sender which completes the ask and the 
> route. My startup looks like this: 
>
>   val serverSource: Source[Http.IncomingConnection, Future[Http.
> ServerBinding]] =
> Http().bind(interface = "localhost", port = 8080)
>   log.info("Server online at http://localhost:8080;)
>   val bindingFuture: Future[Http.ServerBinding] =
> serverSource.to(Sink.foreach { connection => // foreach materializes 
> the source
>   import akka.pattern.ask
>   println("Accepted new connection from " + connection.remoteAddress)
>   connection.handleWithAsyncHandler(request => (httpRouter ? request).
> mapTo[HttpResponse], parallelism = 4)
> }).run()
>
>
> A snippet of the router looks like this. 
>
> class HttpRequestRouter extends Actor {
>   protected val log = Logging(context.system, this)
>
>
>   override def receive: Receive = {
> case request: HttpRequest =>
>   val requestId = UUID.randomUUID()
>   request match {
>  case HttpRequest(GET, Uri.Path("/"), _, 

[akka-user] Re: Naive question

['Ryan Tanner' via Akka User List]

One option, which may not be feasible depending on your use case, is to 
simply replay *all* events from scratch, rebuilding current state on the 
fly when needed.  If you can configure enough retention on your Kafka 
cluster, it's an option.

Another is to keep periodic snapshots so that you have a more recent 
starting point.  You start at the last snapshot, apply all events since the 
snapshot and end up with current state.

This is how both Akka Persistence and Kafka's new log compaction are meant 
to work.

On Wednesday, March 15, 2017 at 4:30:23 AM UTC-6, kant kodali wrote:
>
>  if my current state A = {key1: val1, key2: val2, ...key50: val50} and 
> the next state B = {key1: val1, key2: val2, ...key5: val5} then 
> Persistence actor would store A-B = {key6: val6, key7: val7, 
> ...key50: val50} ?
>
> On Tuesday, March 14, 2017 at 10:20:42 AM UTC-7, kant kodali wrote:
>>
>> Thanks for all the replies. When I first came across event sourcing it 
>> clearly says one stores events and changes in the state but not the state 
>> itself. so In my case, I get messages from Kafka and each message is say 
>> JSON with 50 fields like this {key1: val1, key2: val2, ...key50: val50} 
>> and every message will have all or subset of these keys. Now my goal is to 
>> store these stream of messages as events in Cassandra and for me to store 
>> the changes in state I always need to know the current state to see the 
>> change in state caused by the next request but I wonder how this is done 
>> typically with PersistenceActor? Any simplistic example would help a great 
>> deal!
>>
>>
>>
>> On Sunday, March 12, 2017 at 7:09:06 AM UTC-7, kant kodali wrote:
>>>
>>> Hi,
>>>
>>> What does it mean when someone says we store the event itself rather 
>>> than storing the state/data? such that the events can be replayed to store 
>>> the state/data. Does it mean storing the functions/transformation itself 
>>> (simply put the JVM byte code for the function itself) ?
>>>
>>> Thanks!
>>> kant
>>>
>>

-- 
>>  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: Another Newbie Question -- Sending message to Millions of Cluster sharded actors.

['Ryan Tanner' via Akka User List]

Unless you've profiled and found it to be a problem, worry about it later.

On Wednesday, June 8, 2016 at 10:10:37 AM UTC-6, kraythe wrote:
>
> Sorry but i have another newbie question. I have an actor that uses 
> cluster sharding. There are potentially millions of these in the sytem 
> concurrently and they maintain some state. At some point I would like to 
> contact a million of these and ask them for their state to render 
> information or apply analytics on the states. I could easily do something 
> like this: 
>
> private void collectData(final Set ids) {
> final ActorRef ref = 
> ClusterSharding.get(MyApp.getActorSystem()).shardRegion(MyActor.SHARD_REGION);
> ids.stream().forEach(ref.tell(new MyActor().GetState(id)));
> }
>
>
>
>
> The problem i see is that we are running 9 nodes nominally (there can be 
> nodes rolling and other cluster issues) and if I do this call, Im almost 
> guaranteed that I am creating a million messages and sending 8/9 ths of 
> them over serialization to another node. I keep thinking there has to be a 
> better way to call a whole series of actors designated by ids but with the 
> SAME message and have the sharding system do its magic, creating actors as 
> needed if they have been passivated and sending the message to them. It 
> would be even better if I could provide a list of IDs and the rest of the 
> message would be packaged up. 
>
> Or it could be that I am overthinking this and should just flood the 
> system. After this initial pull the analytics system gets updates from 
> those actors via Distributed PubSub and that is efficient, its just at this 
> initial call that it MIGHT be bad. For some sets of data the numbers of 
> actors i am talking to only number in the tens but for other sets they 
> number in the millions. 
>
>  
>
>
>

-- 
>>  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: Considerations when pushing millions of messages through DistributedPubSub?

['Ryan Tanner' via Akka User List]

Might be best to send those over Kafka.  Millions of updates per minute is 
a trivial load for a properly tuned Kafka cluster, doesn't even require 
more than 2-3 machines.

On Thursday, June 2, 2016 at 3:09:31 PM UTC-6, kraythe wrote:
>
> Good to know. I think I could batch the updates if need be. I will profile 
> the load and see how it boils out.
>
> On Thursday, June 2, 2016 at 2:09:55 PM UTC-5, kraythe wrote:
>>
>> Greetings,
>>
>> I am wiring together some actors using distributed pub-sub. Basically I 
>> have actors that are broadcasting their state change. These updates will be 
>> in the millions and be received by multiple actor subscribers per node. 
>> Given that there are millions of these potential updates per minute, are 
>> there any considerations that I should keep in mind when implementing the 
>> system? Thanks in advance.
>>
>> -- Robert
>>
>

-- 
>>  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] Am I Reinventing the Wheel?

['Ryan Tanner' via Akka User List]

How are you coordinating state between logically-equal actors on different 
physical nodes?

On Wednesday, June 1, 2016 at 3:24:57 PM UTC-6, kraythe wrote:
>
> So the reason I didn't think this was cluster sharding is that I actually 
> want these supervisor actors (and their supervised children) to be 
> REPLICATED on every node (they handle user requests). Basically if there is 
> an actor with key 10, I want one actor with key 10 per node. I didn't want 
> the messages getting rerouted to another node. So if I have one of these 
> actors running on every node how can I do that with sharding? Id imagine I 
> would have to be fancy with the shard id but i have no idea how. 
>
> -- Robert
>
> On Wednesday, June 1, 2016 at 3:42:16 PM UTC-5, Konrad Malawski wrote:
>>
>>
>> I was working on a supervisor that lazy creates actors based on some key 
>> and then will forward messages to that actor. 
>>
>> That's Cluster Sharding :-)
>>
>> http://doc.akka.io/docs/akka/snapshot/scala/cluster-sharding.html 
>>
>> Technically you can use it on one node too, yeah.
>>
>>
>> Happy hAkking!
>> -- 
>> Konrad `ktoso` Malawski
>> Akka  @ Lightbend 
>>
>>
>>

-- 
>>  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: Bootstrapping akka-cluster from etcd - options?

['Ryan Tanner' via Akka User List]

I used to run an Akka cluster on top of etcd.  I just had a wrapper script 
that grabbed seed hosts from etcd and passed them as flags to my java 
command.

We were using fleetd to deploy our Akka cluster nodes as Docker instances. 
 Each node had a sidekick job in fleetd that updated etcd with the Akka 
host's hostname and port every 60 seconds.  If the Akka node crashed, the 
sidekick would be taken down as well and the etcd entry for that Akka host 
would expire within 45 seconds.

On Tuesday, April 26, 2016 at 1:10:18 PM UTC-6, Val P wrote:
>
> Hi,
> Does anyone have any experience with ConstructR or akka-cluster-etcd for 
> bootstrapping an akka cluster off of etcd? How do the two compare, and are 
> there other options?
>
> ConstructR: https://github.com/hseeberger/constructr
> akka-cluster-etcd: https://github.com/rkrzewski/akka-cluster-etcd
>
>
>

-- 
>>  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: Can I use in-memory Actor state as a search engine ?

['Ryan Tanner' via Akka User List]

I don't want to rain on anyone's parade, but I think there's a reason that 
products like Solr and Elasticsearch are complicated: search is hard! 
 Getting it right at scale is *really tough*.

Personally, I would gladly trade the operational complexity of ES/Solr over 
reimplementing them myself.  

On Wednesday, March 30, 2016 at 12:42:53 AM UTC-6, Chelios wrote:
>
> Hey guys
>
> I've got an Eventsource based application (Not CQRS - Read and write are 
> both on the write side). The state of all the entities/aggregates/actor are 
> stored in memory because the data is not going to go above 120GB and I've 
> have a machine with 265GB RAM.
>
> *Problem:*
> Suppose I have a million Products where each *Product* is an Actor 
> supervised by *ProductSupervisorActor* and I want to perform the 
> following query:
> *Query*: Find all the products where the *product description* matches 
> some user input.
>
> I'm wondering if I could get away with just querying the state of the 
> million actors and aggregating the result into one 
> *SearchRequestHandlerActor* instead of using a search database like SOLR 
> ? I've used SOLR before and it's super fast but I'm just trying to reduce 
> the complexity in my application. If the state is already in memory may be 
> I can just find a way to query it instead of introducing another moving 
> part (SOLR) into the system that I have to manage and make sure that the 
> data is synchronized.
>
> I would really like to find a solution to perform the above query 
> efficiently by just using Actors with paging. If I can achieve this then I 
> can have *ProductActor*s running anywhere in a cluster and the search 
> would work just fine. Instead, if I was using SOLR I would have to shard or 
> partition the database which just another hassle.
>
> RIght now I've got a *ProductSearchRequestHandlerActor *which*, *on 
> initilization, accepts *totalNumberOfMessagesExpect: Long* and accepts 
> messages of type *Option[ProductState]* until the 
> *totalNumberOfMessagesExpect* is reached. *I have not implemented paging 
> yet.* 
>
> I just wanted to get your opinion or ideas on how I can achieve this 
> efficiently or any tips or I'm being silly for trying this because there is 
> no central index ? 
>
> Chel
>

-- 
>>  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 pass a Spring security context to all actors in a Akka system?

['Ryan Tanner' via Akka User List]

Don't pass auth info into the *system, *pass with with each message into 
the *actor*.  When a request comes in and its identity is authenticated, 
pass that authentication along with your messages.  Then, if needed, let 
your actors figure out authorization based on that authenticated identity 
with whatever requirements are necessary for that component.

This avoids both the ThreadLocal issue *and* makes it trivial to scale that 
across nodes—you pass whatever information is required all the way through 
your application.  So long as it's serializable, it doesn't matter if those 
messages cross your cluster or stay local.

On Thursday, March 17, 2016 at 11:49:17 AM UTC-6, Bernd G. wrote:
>
> Hi Konrad, thanks for the heads up. 
>
> Good point, I will also ask around in the Spring community. 
>
> It can be looked at, however, as a general question of security in a Akka 
> system - how can I pass user identity information into a Akka system so 
> that it can be picked up by any Actor receiving messages? After thinking a 
> bit about it, it's of course not that straight forward - even if I'm able 
> to bring the Spring SecurityContext onto each thread in the Akka system (by 
> overriding the ExecutionContext (
> http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html), what 
> should be happening when an actor is actually executed on a remote machine? 
>
> So my question for this community is: How is identity passed into an Akka 
> System? Or put differently, how do you solve the issue of authorization 
> within an Actor? As an Actor is responsible for the state of a certain 
> resource, it is also its responsibility to make sure to block unauthorized 
> users to change its state.
>  
> Best Regards,
> Bernd
>
> On Wednesday, 16 March 2016 22:01:36 UTC+1, Konrad Malawski wrote:
>>
>> Hi there Bernd,
>> I think this is more of a Spring Security question... I don't really know 
>> if those strategies they provide work in such contexts.
>>
>> In general you could ask such question on a Spring group and explain that 
>> the context needs to survive being used
>> from one thread at a time, but it could be a different one each time.
>> Anything ThreadLocal based generally will not work (in any kind of async 
>> toolkits, not just Akka).
>>
>> -- 
>> Cheers,
>> Konrad 'ktoso’ Malawski
>> Akka  @ Lightbend 
>> 
>>
>> On 15 March 2016 at 01:21:07, Bernd G. (bernd...@gmail.com) wrote:
>>
>> Hello All,
>>
>> we have a small service that implements a REST API, and we use Akka to 
>> enable concurrency, for structure and readibility of our code. All works 
>> fine, except I'm struggling now with our security integration. We're using 
>> Spring as our 'container' framework and Spring Security to handle 
>> authentication and authorization. My question now is: How can I use
>>
>> String userId = 
>> SecurityContextHolder.getContext().getAuthentication().getName();
>>
>> in our actors? I know that the Spring security context is by default put 
>> into a ThreadLocal. One idea I had is to create an ExecutionContext and 
>> pass this to the Actor system create method, thus letting Spring create the 
>> threads, and using the security context passing strategy '
>> MODE_INHERITABLETHREADLOCAL', but I wanted to reach out first if anybody 
>> has done this thing already. Thanks in advance!
>>
>> --
>> >> 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: change of Tech Lead

['Ryan Tanner' via Akka User List]

Congrats Roland!

On Monday, March 7, 2016 at 10:42:32 AM UTC-7, rkuhn wrote:
>
> Dear fellow hakkers,
>
> as of today I am passing on the baton of Akka Tech Lead @ Lightbend to 
> Patrik Nordwall. Don’t worry, I will stay around and keep working on Akka, 
> but it will no longer be my day job come April: I am co-founding actyx 
> —a new start-up in Munich that aims at bringing 
> reactive design principles to the IT behind industrial manufacturing—where 
> I will build and lead the engineering organization. It was always my plan 
> to solve concrete customer challenges once I have collected enough 
> experience with building the tools, and while I had not yet started looking 
> for an opportunity I could also not pass this one up when it presented 
> itself.
>
> Akka will be in good hands with Patrik and the rest of the team, he is as 
> passionate about distributed systems as I am and he is a much more 
> disciplined coder—not to mention that he joined the Akka team before any 
> other current member including myself. I am very grateful that I had the 
> chance to be part of this amazing team for the past 4.5 years and I have no 
> desire to leave this awesome community anytime soon.
>
> Regards,
>
> Roland
>
>
> Lightbend – Reactive apps on the JVM.
> twitter: @rolandkuhn
> 
>
>

-- 
>>  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: A simple question?

['Ryan Tanner' via Akka User List]

Yes.

But without knowing more there's no way we can know if it's an appropriate 
choice or not.

On Wednesday, March 2, 2016 at 9:15:50 AM UTC-7, Oscar Gabriel Reyes Pupo 
wrote:
>
> Hello,
>
> I'm new in Akka. After reading some examples, I have a simple question, It 
> is suitable to use Akka for developing a concurrent application that only 
> runs on a single machine?
>
> Best
>
> Oscar Reyes
>

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