[infinispan-dev] support for extending Infinispan

Galder Zamarreño galder at redhat.com
Tue Sep 14 06:44:17 EDT 2010


On Sep 14, 2010, at 12:22 PM, Mircea Markus wrote:

> 
> On 13 Sep 2010, at 19:14, Sanne Grinovero wrote:
> 
>> I'd also love to see some capability to send my own command;
>> I'm thinking about having a single IndexWriter always open, and
>> delegate work to it from other nodes, or in other cases distribute the
>> search request to the remote nodes instead of downloading the needed
>> index segment (a common problem with Lucene is to have enough memory
>> to perform a sort operation on huge result sets).
> If you only need to do an RPC and not go through the interceptor chain that's  possible with current code base. Take a look at ClusteredGetCommand, it dies just that.
>> 
>> A "distributable" IndexWriter would be great for Search, and latest
>> Lucene as some new APIs which could help with this, but I'm not in a
>> position to be able to tell which commands I need; I would need to
>> experiment a bit with it, and would love to be able to play with the
>> commands in a flexible way - currently it looks hard and I desisted
>> from investigation.
>> 
>> Maybe it could be possible to reserve some command numbers for
>> experiments? Or allow pluggable invocations?
> This is another issue that a generic command would solve - one wouldn't have to bother keeping new command IDs unique.

Hmmm, why?

>> I'd especially love an API to send a specific method with parameters
>> (like RMI) to the node owning a specific key - last time I mentioned
>> this need Bela mentioned a new sort of multiplexer to reuse the
>> JGroups channel, but at that time this was yet to be written.
>> A super cool feature would be for example to start Hibernate Search's
>> JGroups backend on the same channel as Infinispan, having for example
>> all data sent to the one machine having a specific key.
>> 
>> Another extensibility I wish I had is to be able to plug my own
>> marshaller/externalizer (also had a thread about it).
>> 
>> Sanne
>> 
>> 2010/9/13 Manik Surtani <manik at jboss.org>:
>>> 
>>> On 13 Sep 2010, at 17:19, Mircea Markus wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I've been working on an POC for continuous-query in ISPN. This runs on top of Drools, and is a independent mvn module.
>>>> One of the things I needed to do was broadcasting remote commands and make them available in the interceptor chain. As Infinispan does only support a fixed number of Commands and I cannot  (and don't want to) add a new command as I am in a different module, I hacked the PutKeyValue: on special key values, my interceptors know that  they should handle it. This way, PutKeyValue is not a put per se, but a way to facilitate RPC and an ugly hack :)
>>> 
>>> What "command" is this, what do you need to be able to broadcast?
>>> 
>>>> I was thinking that a GenericCommand that would contain a Map of parameters would be handy for this scenario. Also a method on the visitor, visitGenericCommand. This would allow integration projects (like cq) to be done nicely. If this sounds appealing I can detail..
>>> 
>>> -1.  This sounds like it opens a huge can of worms, making things hard to maintain and open to abuse.  Commands should be very specific and properly typed.
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Manik Surtani
>>> manik at jboss.org
>>> Lead, Infinispan
>>> Lead, JBoss Cache
>>> http://www.infinispan.org
>>> http://www.jbosscache.org
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache




More information about the infinispan-dev mailing list