October 2014 - infinispan-dev - Jboss List Archives

JAR distribution once the grid has been deployed

by Emmanuel Bernard

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

11 years, 1 month

3
2
0 / 0

Infinispan HotRod C++ Client 7.0.0.CR2 released!

by Ion Savin

Hi all, Infinispan HotRod C++ Client 7.0.0.CR2 is now available! Thanks to everyone involved for the changes and bug reports contributed! Release details on http://blog.infinispan.org/2014/10/infinispan-hotrod-c-client-700cr2.html -- Ion Savin

11 years, 2 months

1
0
0 / 0

ClassNotFoundException infinispan-embedded-7.0.0.CR2.jar

by Andreas Kruthoff

Hi I was running a cache in distributed mode and suddenly got the following ClassNotFoundException (see below). My classapth: infinispan-embedded-7.0.0.CR2.jar jboss-transaction-api_1.1_spec-1.0.1.Final.jar Am I missing something? Exception in thread "main" org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.start() throws java.lang.Exception on object of type StateTransferManagerImpl at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170) at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869) at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638) at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627) at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530) at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216) at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:764) at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:584) at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:539) at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:416) at ch.nexustelecom.lbd.engine.ImsiCache.init(ImsiCache.java:49) at ch.nexustelecom.dexclient.engine.DefaultDexClientEngine.init(DefaultDexClientEngine.java:120) at ch.nexustelecom.dexclient.DexClient.initClient(DexClient.java:169) at ch.nexustelecom.dexclient.tool.DexClientManager.startup(DexClientManager.java:196) at ch.nexustelecom.dexclient.tool.DexClientManager.main(DexClientManager.java:83) Caused by: org.infinispan.commons.CacheException: java.lang.ClassNotFoundException: org.infinispan.partionhandling.impl.AvailabilityMode at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:655) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:176) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:536) at org.infinispan.topology.LocalTopologyManagerImpl.executeOnCoordinator(LocalTopologyManagerImpl.java:388) at org.infinispan.topology.LocalTopologyManagerImpl.join(LocalTopologyManagerImpl.java:102) at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:108) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) ... 14 more Caused by: java.lang.ClassNotFoundException: org.infinispan.partionhandling.impl.AvailabilityMode at java.net.URLClassLoader$1.run(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:131) at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:112) at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:1002) at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1239) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) at org.infinispan.topology.CacheStatusResponse$Externalizer.readObject(CacheStatusResponse.java:76) at org.infinispan.topology.CacheStatusResponse$Externalizer.readObject(CacheStatusResponse.java:62) at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:424) at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:221) at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:148) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) at org.infinispan.remoting.responses.SuccessfulResponse$Externalizer.readObject(SuccessfulResponse.java:79) at org.infinispan.remoting.responses.SuccessfulResponse$Externalizer.readObject(SuccessfulResponse.java:64) at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:424) at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:221) at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:148) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:135) at org.infinispan.marshall.core.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:101) at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:80) at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:28) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:250) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:674) at org.jgroups.JChannel.up(JChannel.java:733) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:146) at org.jgroups.protocols.RSVP.up(RSVP.java:190) at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) at org.jgroups.protocols.FlowControl.up(FlowControl.java:390) at org.jgroups.protocols.FlowControl.up(FlowControl.java:379) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1042) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1034) at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:752) at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:399) at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:610) at org.jgroups.protocols.BARRIER.up(BARRIER.java:152) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297) at org.jgroups.protocols.MERGE3.up(MERGE3.java:288) at org.jgroups.protocols.Discovery.up(Discovery.java:277) at org.jgroups.protocols.TP.passMessageUp(TP.java:1568) at org.jgroups.protocols.TP$MyHandler.run(TP.java:1787) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) This email and any attachment may contain confidential information which is intended for use only by the addressee(s) named above. If you received this email by mistake, please notify the sender immediately, and delete the email from your system. You are prohibited from copying, disseminating or otherwise using the email or any attachment.

11 years, 2 months

3
2
0 / 0

Should JMX size stat consider expired entries?

by Galder Zamarreño

Hi all, The reason [1] was failing was due a set of circumstances that essentially meant that JMX size statistic was counting expired entries. We had a brief discussion on IRC and there’s some divergence on how precise JMX size stat should be [2]. I’m OK with expired entries being counted since that means that size is fast to retrieve that way. If you need to start calculating if each entry is expired…etc, it would slow it down. However, if we go down that route, we need to change all tests that rely on JMX size stat for their assertions. There’s quite a few of those in the Server integration testsuite, e.g. AbstractRemoteCacheIT. Thoughts? [1] https://issues.jboss.org/browse/ISPN-4813 [2] https://gist.github.com/galderz/62ae5120f5ac50ceabef -- Galder Zamarreño galder(a)redhat.com twitter.com/galderz

11 years, 2 months

1
0
0 / 0

Retro-weaving Java8 bytecode to Java7 compatibility (and Java6!)

by Sanne Grinovero

I just found this project: https://github.com/orfjackal/retrolambda I have no idea how reliable the output code could be, maybe someone would be interested to explore the option? Sanne

11 years, 2 months

1
0
0 / 0

Infinispan 7.1 plan

by Tristan Tarrant

Hi guys, with the imminent release of 7.0.0.CR2 we are reaching the end of this release cycle. There have been a ton of improvements (maybe too many) and a lot of time has passed since the previous version (maybe to much). Following up on my previous e-mail about future plans, here's a recap of a plan which I believe will allow us to move at a much quicker pace: For the next minor releases I would like to suggest the following strategy: - use a 3 month timebox where we strive to maintain master in an "always releasable" state - complex feature work will need to happen onto dedicated feature branches, using the usual GitHub pull-request workflow - only when a feature is complete (code, tests, docs, reviewed, CI-checked) it will be merged back into master - if a feature is running late it will be postponed to the following minor release so as not to hinder other development I am also going to suggest dropping the cherry-picking approach and going with git merge. In order to achieve this we need CI to be always in top form with 0 failures in master. This will allow merging a PR directly from GitHub's interface. We obviously need to trust our tools and our existing code base. This is the plan for 7.1.0: 13 November 7.1.0.Alpha1 18 December 7.1.0.Beta1 15 January 7.1.0.CR1 30 January 7.1.0.Final Tristan

11 years, 2 months

11
25
0 / 0

Analysis of infinispan-6.0.2 dependency on JDK-Internal APIs

by Rory O'Donnell Oracle, Dublin Ireland

Hi Galder, As part of the preparations for JDK 9, Oracle’s engineers have been analyzing open source projects like yours to understand usage. One area of concern involves identifying compatibility problems, such as reliance on JDK-internal APIs. Our engineers have already prepared guidance on migrating some of the more common usage patterns of JDK-internal APIs to supported public interfaces. The list is on the OpenJDK wiki [0], along with instructions on how to run the jdeps analysis tool yourself . As part of the ongoing development of JDK 9, I would like to encourage migration from JDK-internal APIs towards the supported Java APIs. I have prepared a report for your project rele ase infinispan-6.0.2 based on the jdeps output. The report is attached to this e-mail. For anything where your migration path is unclear, I would appreciate comments on the JDK-internal API usage patterns in the attached jdeps report - in particular comments elaborating on the rationale for them - either to me or on this mailing list. Finding suitable replacements for unsupported interfaces is not always straightforward, which is why I am reaching out to you early in the JDK 9 development cycle so you can give feedback about new APIs that may be needed to facilitate this exercise. Thank you in advance for any efforts and feedback helping us make JDK 9 better. Rgds,Rory [0] https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

11 years, 2 months

3
5
0 / 0

On ParserRegistry and classloaders

by Sanne Grinovero

I see the ParserRegistry was changed quite a bit; in Infinispan 6 it allowed to specify a different classloader for some operations, now it only takes a classloader during construction time. For WildFly/JBoss users, it is quite common that the configuration file we want parsed is not in the same classloader that the ParserRegistry needs to lookup its own parser components (as its design uses the ServiceLoader to discover components of the parser). This is especially true when Infinispan is not used by the application directly but via another module (so I guess also critical for capedwarf). I initially though to workaround the problem using a "wrapping classloader" so that I could pass a single CL instance which would try both the deployment classloader and the Infinispan's module classloader, but - besides this being suboptimal - it doesn't work as I'm violating isolation between modules: I can get exposed to an Infinispan 6 module which contains also Parser components, which get loaded as a service but are not compatible (different class definition). I'll need these changes in the ParserRegistry reverted please. Happy to send a pull myself, but before I attempt to patch it myself could someone explain what the goal was? thanks, Sanne

11 years, 2 months

4
11
0 / 0

Infinispan 7.0.0.CR2 released!

by Gustavo Fernandes

Dear all, We are proud to announce the second release candidate for Infinispan 7.0 Release details on http://blog.infinispan.org/2014/10/infinispan-7.html Thanks everyone for their contributions! Cheers, Gustavo

11 years, 2 months

1
0
0 / 0

Early Access builds for JDK 9 b35 and JDK 8u40 b10 are available on java.net

by Rory O'Donnell

Hi Galder, Early Access build for JDK 9 b35 <https://jdk9.java.net/download/> is available on java.net, summary of changes are listed here <http://www.java.net/download/jdk9/changes/jdk9-b35.html> Early Access build for JDK 8u40 b10 <http://jdk8.java.net/download.html> is available on java.net, summary of changes are listed here. <http://www.java.net/download/jdk8u40/changes/jdk8u40-b10.html> Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

11 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-dev October 2014