Emmanuel, I don't think we have any plans in place. I agree with you - we should at least provide hooks for these classloaders and possibly implement a certain simple approach as a proof-of-concept/tutorial for others to hook in their own mechanism of class loading. We can reference Evangelos' approach as one example of how this could be done.
Vladimir On 2014-10-16, 5:23 AM, Emmanuel Bernard wrote: > Hi all, > > I know this has been discussed in the past (by Tristan I think), but I don’t > know how concrete the plans have come since then. > > One major issue with all the distributed execution code interfaces we have is > that it requires to have in the classpath of each node both the > implementation of these interfaces and the class files corresponding to the > key and value being processed. My understanding is that this is true of the > distexec, Map / Reduce and (clustered) listener. > > Evangelos from the LEADS project sort of worked around this problem by > creating specialized versions of his distexec that loads the necessary JARs > from the grid itself (in a set of keys) and creates a classloader that > references these JARs. In a sequence, it conceptually looks like that: > > - have the generic classloader distexec version in the each of grid nodes > classpath at start time > - when a new remote execution is required, load each necessary JAR in a > specific key in a specific cache > - the generic distexec basically receives the necessary keys, load each jar > and create a classloader out of them > - the generic distexec load and launch the specific code that needs to be > executed (based on the fqcn of the code to execute) from the created > classloader > > There are a few problems with that including: > - it requires a lot of manual work from the user > - big JARs make the key / value per JAR logic explode a bit. The algorithms > LEADS use have 300 MB sized JARs > - god know what security leak this can lead to > > So I wondered if we have a better alternative and plans and if there was a > wiki page discussing the needs and potential approaches. > As an intermediary step we could make this approach a tutorial or side > classes that people can borrow from for each of the use cases. > > Emmanuel > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
