Agents and Collections (lists, hashmap's etc)

[Antony Stubbs]

What's the best practice for using Agents with collections like lists and hashmaps? I.e. the complication being when you return the list, but adding an item to the list can cause a concurrent modification exception. One possibility is instead of returning the list, return a copy. But I don't think Agent supports that as is? Same question I suppose for any type that isn't a primitive - i.e. a model object like "User".

[Derek Williams]

On Fri, Jun 29, 2012 at 11:55 AM, Antony Stubbs <antony...@gmail.com> wrote:

What's the best practice for using Agents with collections like lists and hashmaps? I.e. the complication being when you return the list, but adding an item to the list can cause a concurrent modification exception. One possibility is instead of returning the list, return a copy. But I don't think Agent supports that as is? Same question I suppose for any type that isn't a primitive - i.e. a model object like "User". 

The best practice is to avoid mutable collections or other mutable objects with Agents. You are probably using Java, so this might be more difficult since the use of mutable objects is much more common there.

It might be possible for Akka to support a custom method for modifying the value before returning it? It's been a while since I've looked at the Agent code.

--

Derek Williams

[Antony Stubbs]

I suppose the other option is to create the copy when changing/setting
it's value, instead of when returning it.

But what about model objects? Same thing I suppose.

> --
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to
> akka-user+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/akka-user?hl=en.

[Kane Lai]

However, won't it be slow if we are to copy a large object (e.g. HashMap)? What's the recommended way to handle such kind of large state using Akka? Akka Agent? STM? or I am even thinking using a separate embedded in-memory DB, but seems it's overkilled...

I've searched lots of places in the internet but seems nothing is found...

[√iktor Ҡlang]

Any decent immutable collection does structual sharing.

What's your access-pattern like?

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/groups/opt_out.

--

Cheers,

√

———————

Viktor Klang

Chief Architect - Typesafe

Twitter: @viktorklang

[Kane Lai]

Hi,

I'm writing a program to process some commands from an external party. Those commands act against some phone numbers. One actor is used to read the commands from files line-by-line. Then it issues the commands one by one (in Akka messages) to another actor. That actor will perform a series of operations according to the command it receives. The operations involves calling some external SOAP APIs and checking/updating some states in the program. I'm using separate actors to handle different SOAP APIs. Up to now, everything seems clear to me.

Then the problem is, I need to maintain a large state in the program in the format of HashMap<String, MyData>, where MyData is a POJO containing a few fields, and the size of the map could be as large as 1 million. So I'm wondering how I should keep such a large state in Akka while allowing simultaneous insert/delete of records by other actors. It mostly won't perform well if I copy the whole object. What is the recommended way of doing such kind of thing? I'm thinking, if I use an embedded in-memory key-value store, and allow my actor to access it, I can let the IMDB handle the concurrency stuff and let multiple instances of the actor to access the data. However, does Akka have some easier ways to do it? Any suggestion is highly appreciated. Thanks!

Kane

You received this message because you are subscribed to a topic in the Google Groups "Akka User List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/klyQ-S60K18/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.

[Justin du coeur]

Catching up on this list, I don't see any replies to this one yet, so I'll take a crack at it:

On Mon, Mar 3, 2014 at 1:00 PM, Kane Lai <kaneh...@gmail.com> wrote:

Then the problem is, I need to maintain a large state in the program in the format of HashMap<String, MyData>, where MyData is a POJO containing a few fields, and the size of the map could be as large as 1 million. So I'm wondering how I should keep such a large state in Akka while allowing simultaneous insert/delete of records by other actors. It mostly won't perform well if I copy the whole object.

I'm not clear on every detail of what you're trying to do, but suffice it to say, my app's fairly similar conceptually.  The key is Victor's point about structural sharing.  Making a "copy" of a HashMap actually just returns a tiny tweak of the previous value, so the time it takes is more or less constant regardless of the Map's size.  Think of the HashMap as being essentially a stack of states that are each adding or removing a little information.

This is true of pretty much all of the immutable data types, including case classes.  In general, when you "copy" one of these data types, you're really just adding a new node on top of the previous state, so it's algorithmically pretty fast.

(Obviously, in cases where you are *really* copying the data, such as sending it as a message from an Actor to an Actor on another system, that can get expensive.  But that's true regardless of the data structure, and is to be avoided if possible.)

A bigger concern is your comment "while allowing simultaneous insert/delete of records by other actors".  Keep in mind that the most important principle of good Akka is keeping your data well-isolated.  This table should probably be encapsulated inside a single Actor, which does very little aside from providing access to its information.  Those other actors should be making their changes through this one...