We are currently constrained by the environment our client runs in (i.e. WAS 6) and would love to use search and provide the application with near realtime search.

So far, Infinispan looks good. We are able to get it running with minimal effort using the default configurations.

I do have 2 questions though:

1) Is it possible to have Infinispan running standalone on separate server (with java 6) while still serving HSearch clients running on an older version of java (java5)? From the docs, it seems I can boot infinispan up as a standalone and have clients interacting with it.

2) If #1 is possible, what configurations are needed in HSearch? The defaults seem to have each client kick of infinispan at startup time and join existing clients to form a data grid. Can I have HSearch clients still work transparently (the way they do when each client kicks off infinispan at start up) with such a configuration? If not, what level of customization is needed on my part?

Thanks.

Hi ronotica,
yes Infinispan can run "standalone", but the current Search integration is not designed to connect remotely.

To really use Infinispan remotely you could adapt the Lucene Directory to use Hotrod (that's the name of the Infinispan client); this is likely easy to do, but I'm afraid that performance will be very disappointing. the overhead would be comparable to downloading a large chunk of your index every time a query is performed. I'd definitely avoid this approach.

You could have an Hibernate Search application run on the same JVM as Infinispan, containing your entities and mapping as well, and expose a search service via EJB Remoting / REST / wathever.
You would still have Hibernate Search on your WAS application running on Java5 listen to Hibernate events, and send the index updates using the JMS back-end provided by Hibernate Search to the Infinispan server(s).
You'll only have to run the queries in custom way, via the remoting layer of your choice. Some coding might be needed here for optimal performance: I'd suggest you to make sure the remote node does not return entities but primary keys, and then you load the entities inside your WAS server by loading them via the received primary keys.
So basically this would reuse large parts of Search, including the mapping, the event detection, and querybuilder, filtering, projection capabilities. The little layer actually performing your queries would need some glue code to be remoted.

In theory you could implement just a ReaderProvider (it's one of the extension points in Search you can easily replace via configuration) which returns Remote readers to Search, and it will use them transparently. That would give you the best integration as the application can be totally unaware of what happens, and later you can reconfigure it when finally able to switch to Java6 .. but I have no clue about how this could perform. It doesn't sound right to me, but I know that some people do have mocks for remote IndexReaders, there's even some tooling in Lucene itself to build such devices via RMI.

Regards,
Sanne

Thanks for the detailed description of the options. From reading the infinispan docs, I see REST is also on the table when using client/server mode. Is it possible this can be achieved via REST as opposed to using hotrod which you advise against? Is that route also sub-optimal?

I'll like to hear you thoughts on that.

BTW, I have no idea how that will fit into search (indexing documents, updates, deletes, etc)

Also, is supporting the client/server architecture on the road map for search in the near future?

You can "get" values via REST from Infinispan, but in the case of the index as I mentioned above this would imply you download the full index locally just to run a Query. you could as well use rsync to copy files then.. I'd not explore this direction.

For your special case of not being able to join Infinispan directly I'd explore one of the other options I explained.


something cool is on the roadmap, we plan to be able to run the search distributing it to the remote nodes, so you can actually have two(more) nodes deal with parts of the query, and then merge results back: send the query to the nodes, not the index to your server.
I'm afraid this will require Infinispan bits on each node (the invoker as well), at least in the first prototypes.

We'll first have to deal with https://issues.jboss.org/browse/ISPN-200, then support it transparently via Hibernate Search.

OK, thanks. I was under the assumption Hotrod and REST handled things differently hence the question... I guess not.

If time permits, I'll definitely explore the options you outlined and if possible, donate it

Cheers