Spring module - change dependencies to Uber Jars
by Sebastian Laskawiec
Hey!
I'm currently trying to solve a tricky class loading issue connected to
Spring, CDI and Uber Jars. Here's the scenario:
- Remote Uber Jar contains CDI module
- Our Hot Rod client use newer version of JBoss Logging which is present
in Wildfly/EAP modules
- However EAP and Wildfly will load (and make available for deployment)
their own version of JBoss Logging [1]
- The easiest fix for this is to relocate JBoss Logging package in
Uber Jar
- Spring module requires some classes from Infinispan Common and they in
turn need BasicLogger from JBoss Logging
- If we relocate JBoss Logging and will try to use Uber Jar with
Spring - we will end up with classloading issue [2]
So it seems the best approach is to make Spring depend on Uber Jars instead
of "small ones". Of course, users who use small jars will probably be
affected by this change (they would have to either accept using Uber Jars
or exclude them in their poms and add dependencies manually).
Is anyone against this solution? JIRA tracking ticket: [3].
Thanks
Sebastian
[1] Scenario with Weld enabled WAR
https://docs.jboss.org/author/display/AS7/Implicit+module+dependencies+fo...
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1266831#c7
[3] https://issues.jboss.org/browse/ISPN-6132
7 years, 4 months
jdk8backported package
by Radim Vansa
Hi,
although we're on Java 8, there's still the package
org.infinispan.*.jdk8backported in our codebase. Is there any plan (and
possibility) to remove these and use implementation provided by runtime?
Or have we tweaked them too much, so shall we rather rename them?
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
7 years, 8 months
Lambda Serialization
by William Burns
I wanted to propose a pretty simple way of making the lambdas serializable
by default that I stumbled upon while working on another issue.
I noticed that in the method resolution of the compiler it does some nice
things [1]. To be more specific when you have 2 methods with the same name
but vary by argument types, it will attempt to pick the most "specific"
one. Specific in this case you can think of if I can cast one argument
type to the other but it can't be cast to this type, then this one is most
specific.
Here is an example, given the following class
interface SerializableFunction<T, R> extends Serializable, Function<T, R>
The stream interface already defines:
Stream map(Function<? super T, ? extends R> mapper);
But we could add this to the CacheStream interface
CacheStream map(SerializableFunction<? super T, ? extends R> mapper);
In this case you have 2 different map methods accessible from your
CacheStream instance. When passing a lambda the Java compiler will
automatically choose the most specific one (in this case the
SerializableFunction one since Function can't be cast to
SerializableFunction). This will then make the lambda automatically
Serializable. In this way nothing special has to be done (ie. explicit
cast) to make the instance Serializable.
This allows anyone using our Cache interface to immediately get lambdas
that are Serializable when using Streams.
The main problem however would be ambiguity because the Serialization would
only be applied assuming you are using a defined class of CacheStream etc.
Also this means there are 2 methods (but that seems fine to me), so it
could cause a bit of confusion. The non serialization method is still
helpful if people want to their own Externalizer, since their
implementation doesn't have to implement Serializable then.
What do you guys think? It seems like a decent compromise to me.
- Will
[1]
https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.5
8 years, 1 month
HotRod exec operation tight coupling with JBoss Marshaller
by Galder Zamarreño
Hi all,
While implement `exec` operation for the JS client, I've encountered an issue with how the exec parameters and return types are marshalled.
The essence of the problem is that the server marshalls these objects instead of having the client drive how these are marshalled. As a result of this, for a JS or C++ client to be able to use `exec` with default configuration, they need to understand JBoss Marshaller format, which is not good.
I'm not sure this would have been unavoidable due to the characteristics of `exec` but I wanted to see if we can find a good way to solve or get around this issue. Long term, we need better encoding handling both for incoming and returning types, but the question is whether we can find a way to better solve this until then. Here are some options:
- For the C++ client, Vittorio has part implemented the JBoss Marshaller format [1], but I'm kinda reluctant to go down this path since that creates a lot of work for us as the number of types that can be discovered in a JBoss Marshaller format byte array are quite considerable [2]. We're bound to miss one of those and since clients could execute any script, the chances are high IMO...
- An alternative would be for the JS/C++ clients to only support exec when the marshaller is one that enables compatibility mode. The idea here is that for compatibility mode to work, all clients involved are going to be set up with a marshaller that can work for all of them. Working on such marshaller is time better spent than on implementing the JBoss Marshaller format. We had a separate discussion on this topic in another dev thread...
Any other ideas someone might have?
Cheers,
[1] https://github.com/infinispan/cpp-client/blob/master/include/infinispan/h...
[2] https://github.com/jboss-remoting/jboss-marshalling/blob/master/river/src...
--
Galder Zamarreño
Infinispan, Red Hat
8 years, 1 month
Compatibility mode vs TaskContext#getCache
by Michal Szynkiewicz
Hi,
Based on TaskManager used for scripting tasks, I have implemented
deployable server (Java) tasks.
Having cache configured this way: [1], Anna has written a test which checks
if keys and values in the cache need marshalling or not and reported that
this doesn't work as expected.
After some investigation I found out, that if I acquire cache via
cacheManager (e.g.
taskContext.getCache().get().getCacheManager().getCache()), the instance
operates on proper values (in other words, keys and values don't need
marshalling/unmarshalling).
In the case of taskContext.getCache().get(), keys and values need to be
processed by Marshaller.
The cache behind both seems to be the same, a value put in one of them is
visible in both.
I would really appreciate some tips how to solve it.
The test uses RemoteCacheManager#getCache().execute(...) to execute the
task.
Thanks,
Michał
[1]
https://github.com/infinispan/infinispan/blob/master/server/integration/t...
8 years, 1 month
Hot Rod encoding
by Galder Zamarreño
Hi all,
As I write the Javascript client for Hot Rod, and Vittorio writes the C++ client, the question the encoding of the byte arrays has popped up.
The reason why encoding matters is mainly because of compatibility mode. How does a Hot Rod client know how it should transform something a REST client set?
To be able to answer this question correctly, the Hot Rod client needs to know the type of the data.
Although we could consider adding encoding information to the Hot Rod protocol long term, in the short term this question might already been answered by Protostream.
Protostream based marshaller adds encoding to the byte arrays by adding information of what the type of that is written, whether raw type or complex. Protostream is based around Protobuf which works well as medium for compatibility mode.
So, in essence, if we want get different clients working together, the simplest thing to do is to implement the Protostream marshaller in each client lang, and they should work together without probs.
This option has the downside that by limiting our compatibility marshalling to Protostream, how would a standard REST client would understand this format? They'd need to have a way to understand Protostream...
Another option would be to setlle on UTF-8 String as compatibility medium and get the languages to convert types into JSON UTF-8 String. I think this would work better for REST-based clients. Also, AFAIK protobuf objects can be transformed into JSON, so if there's already a protostream marshaller available, that can be used to transform to JSON.
Down the line we might want to add encoding to Hot Rod or switch to a technology where encoding is sorted out for us, e.g. HTTP-based protocols...
Thoughts?
Cheers,
--
Galder Zamarreño
Infinispan, Red Hat
8 years, 1 month
Problems with Wildfly 10 Final Clustering
by Christian Beikov
Hello,
I am having problems with clustering since switching to Wildfly 10 Final
and it seems to be related to Infinispan.
I am starting a cluster with 2 nodes, the first one starts up, but the
second one fails to start with some exceptions about ClassCastExceptions
that happen during initial state transfer.
Is this a known issue? Maybe a version incompatibility or something?
Here is the stacktrace I get:
2016-02-18 14:58:02,093 ERROR [org.jboss.msc.service.fail]
(ServerService Thread Pool -- 69) MSC000001: Failed to start service
jboss.infinispan.ejb.dist: org.jboss.msc.service.StartException in
service jboss.infinispan.ejb.dist:
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.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: 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:172)
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:218)
at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:850)
at
org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
at
org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
at
org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
at
org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:117)
at
org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:112)
at
org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
at
org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
... 4 more
Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received
exception from f794f53da998, see cause for remote stack trace
at
org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:747)
at
org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$80(JGroupsTransport.java:589)
at
java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
at
java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
at
java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
at
java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
at
org.infinispan.remoting.transport.jgroups.SingleResponseFuture.futureDone(SingleResponseFuture.java:30)
at org.jgroups.blocks.Request.checkCompletion(Request.java:169)
at
org.jgroups.blocks.UnicastRequest.receiveResponse(UnicastRequest.java:83)
at
org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:398)
at
org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:250)
at
org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:684)
at org.jgroups.JChannel.up(JChannel.java:738)
at
org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:119)
at org.jgroups.stack.Protocol.up(Protocol.java:374)
at org.jgroups.protocols.FORK.up(FORK.java:114)
at
org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:146)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:394)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1045)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
at
org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064)
at
org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:652)
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.up(FD.java:260)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310)
at org.jgroups.protocols.MERGE3.up(MERGE3.java:285)
at org.jgroups.protocols.Discovery.up(Discovery.java:295)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
at org.jgroups.protocols.TP$MyHandler.run(TP.java:1796)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassCastException:
java.util.concurrent.ConcurrentLinkedDeque cannot be cast to java.util.List
at
org.infinispan.distribution.ch.impl.DefaultConsistentHash$Externalizer.doReadObject(DefaultConsistentHash.java:378)
at
org.infinispan.distribution.ch.impl.DefaultConsistentHash$Externalizer.doReadObject(DefaultConsistentHash.java:352)
at
org.infinispan.commons.marshall.InstanceReusingAdvancedExternalizer.readObject(InstanceReusingAdvancedExternalizer.java:102)
at
org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:470)
at
org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:231)
at
org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:149)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:354)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at
org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at
org.infinispan.topology.CacheTopology$Externalizer.doReadObject(CacheTopology.java:201)
at
org.infinispan.topology.CacheTopology$Externalizer.doReadObject(CacheTopology.java:186)
at
org.infinispan.commons.marshall.InstanceReusingAdvancedExternalizer.readObject(InstanceReusingAdvancedExternalizer.java:102)
at
org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:470)
at
org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:231)
at
org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:149)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:354)
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:72)
at
org.infinispan.topology.CacheStatusResponse$Externalizer.readObject(CacheStatusResponse.java:60)
at
org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:470)
at
org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:231)
at
org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:149)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:354)
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:92)
at
org.infinispan.remoting.responses.SuccessfulResponse$Externalizer.readObject(SuccessfulResponse.java:77)
at
org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:470)
at
org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:231)
at
org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:149)
at
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:354)
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:134)
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.jboss.as.clustering.infinispan.ChannelTransport$1.objectFromBuffer(ChannelTransport.java:57)
at
org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
... 26 more
Regards,
Christian
8 years, 2 months
