some random questions on infinispan

[jj_ames]

I'm evaluating infinispan for a new project and wanted to understand a couple of items. I'm having trouble finding out answers to these questions on the user guide and forums.

- In embedded mode, say I have 5 nodes, and one node is picking things up on a jms queue and saving to cache. I understand that when this item goes into the cache, infinispan will use a hashing algorithm to decide which nodes to store it in. Will the initial jms node also always keep it in memory (until expired or evicted)? Or will only the nodes that get selectd by the hashing algorithm have the object in local memory?

- when searching using lucene, do I need to always pre-flag the properties of an object by which I want to search? I know you can flag them, but is this only for indexing to make a search quicker, or does the search actually require the properties be flagged?

- also when searching, suppose I have an an object in the cache that has a hash of values. Can I search for keys (or values for that matter) in this hash using lucene or some other fast search means?

- suppose I have an application deployed on a number of nodes, and they are all registered as Listeners for cache entry events. Is there a way to make infinispan send the signal event to only a single Listener (perhaps one that does not have much load on the node, and/or has the cache entry locally).

- Suppose I have a single node listening for events, in asynchronous mode (so that the caller does NOT block until the Listener has finished processing). The event must get delegated to a separate thread by Infinispan under the hood. Are events on this Listener put on some sort of internal queue? Are there multiple threads that get delegated to? Is this configurable (when not using Jboss)? For example, if a cache entry Listener has not finished processing an event while something else is put into the cache, what happens to this event? Does another thread pick it up? Is it put in an internal queue? Is order maintained?

- Is it possible to use file store on separate hosts without a shared file system? does it make sense to do this? Or should be file store be shared among all nodes?

thanks in advance!

[sannegrinovero]

- In embedded mode, say I have 5 nodes, and one node is picking things up on a jms queue and saving to cache. I understand that when this item goes into the cache, infinispan will use a hashing algorithm to decide which nodes to store it in. Will the initial jms node also always keep it in memory (until expired or evicted)? Or will only the nodes that get selectd by the hashing algorithm have the object in local memory?

You're assuming you are in DIST mode. The node who wrote the entry initially will keep an entry only if L1 caching is enabled, otherwise won't store it.

- when searching using lucene, do I need to always pre-flag the properties of an object by which I want to search? I know you can flag them, but is this only for indexing to make a search quicker, or does the search actually require the properties be flagged?

To search using Lucene queries, it's a requirement: you won't find the entries otherwise. I need to clarify this in the docs, thanks! In other words, indexes are *not* meant to just "boost query performance" but are rather an essential functional requirement. Of course if the indexing cost is not acceptable you can also perform queries via Map/Reduce, which does not use the Lucene indexes and so doesn't require annotations.

- also when searching, suppose I have an an object in the cache that has a hash of values. Can I search for keys (or values for that matter) in this hash using lucene or some other fast search means?

I'm not sure I understood what you want to do. I'd suggest to make an example in a dedicated thread. Not sure if it's relevant, but as long as you can encode it - even defining a custom @FieldBridge implementation - then you can search it via Lucene.

- suppose I have an application deployed on a number of nodes, and they are all registered as Listeners for cache entry events. Is there a way to make infinispan send the signal event to only a single Listener (perhaps one that does not have much load on the node, and/or has the cache entry locally).

It won't be load-aware. The event will only be fired on nodes who have the entry locally. Personally I think Listeners are a bit limited, if they are not powerfull enough you can write a custom interceptor: all core functionality is implemented as interceptors, which makes it easy to extend & replace any very internal behaviour. For example, the Lucene indexer is a custom interceptor which is self-registered using service discovery if infinispan-query.jar is on the classpath.

- Suppose I have a single node listening for events, in asynchronous mode (so that the caller does NOT block until the Listener has finished processing). The event must get delegated to a separate thread by Infinispan under the hood. Are events on this Listener put on some sort of internal queue? Are there multiple threads that get delegated to? Is this configurable (when not using Jboss)? For example, if a cache entry Listener has not finished processing an event while something else is put into the cache, what happens to this event? Does another thread pick it up? Is it put in an internal queue? Is order maintained?

There is a dedicated Executor for this, so events will be processed by this executor in parallel, unless all cores are busy in which case they will be put in a queue. JBoss is not needed for this nor any other feature: no code depends on the application server (the application server depends on Infinispan).

- Is it possible to use file store on separate hosts without a shared file system? does it make sense to do this? Or should be file store be shared among all nodes?

Each CacheStore can be configured as "shared" or not, Infinispan will behave differently depending on this common configuration attribute: for example if it's shared only one owner will write a new entry, otherwise each owner will write to its own CacheStore instance. So this applies to the Filesystem CacheStore too; be aware that CacheStore implementations are not (yet) optimized for high performance.