[infinispan-dev] [ISPN-125] Reading part of dynamic externalizer mappings

[Manik Surtani]

Classpath scanning is fugly.  I ran into issues here where you cannot  
just assume that the classpath is built up of a directory of classes  
or a jar.  VFS comes to mind.

Sending out an FQCN the first time an ID is used won't work.  A and B  
are in a cluster, the first time A has to marshall a class it includes  
the FQCN.  B receives this fine.  B then dies and restarts.  It won't  
get anymore FQCN info from A.

On 16 Jul 2009, at 17:10, Galder Zamarreno wrote:

> Hi,
>
> Re: https://jira.jboss.org/jira/browse/ISPN-125
>
> I've been thinking more about this and I don't have the reading part
> very clear. At runtime, it's very easy to check the externalizer map  
> to
> see if there's externalizer for class A and if there isn't any,  
> inspect
> the class for @Marshallable annotation, instantiate the A's  
> Externalizer
> class and add it to the map.
>
> However, the reading part is a fairly difficult problem to crack cos  
> all
> you'd get would be an Id which you'd need to map back to an  
> Externalizer
> that will be used for reading. However, how does the reader know  
> what's
> the mapping Id to Externalizer mapping?
>
> One option, rather brutal, would be to look up the entire classpath  
> for
> a class containing a @Marshallable with the index you're after.
>
> Another option would be that the 1st time someone writes an instance  
> of
> that class A, it adds a String form of the fully qualified class  
> name to
> the wire. So, the reader can check the externalizer map and if the id
> not present, read the class name and resolve it and add the mapping.
> However, this breaks the moment you have two different nodes sending a
> class for the 1st time. They would both add the class name but only  
> the
> 1st one to arrive would resolve the class name correctly, the 2nd time
> it arrives on the node, cos the mapping would already be there, it  
> would
> read the object directly, failing cos there's also the class name on  
> the
> wire.
>
> Anyone has any other ideas?
>
> It's worth bearing in mind that adding this dynamic behaviour adds
> complexity the code and it forces previously non-concurrent  
> collections
> to be concurrent, hence performance will degrade compared to the  
> current
> solution. It's worth keeping in mind that users will always be able to
> implement their j.i.Externalizable, which will be less performant than
> our internal solution but might be reasonable enough.
>
> One thing is for sure here, the indexes need to be tied down and I'm
> already working on it.
> -- 
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> http://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org