Hi Artem,
Thanks for your investigation! I will then eagerly wait for the resolution
of this bug.
Unfortunately the workarounds you suggested probably are not applicable to
my main use case for Ignite, unless I misunderstood them.
Here's my main use case (only for the development environment):
I'd like the developers to be able to quickly verify/test their custom
ad-hoc code on CPU-intensive computations (for this I can dedicate a couple
of powerful multi-core, huge RAM machines). Therefore I assume that
peerClassLoading is a must. I just want their modified/new classes to be
immediately running on the cluster, whenever they run their tests.
I tried the CONTINUOUS deployment mode as you suggested. Unfortunately, in
this deployment mode, once the class is deployed on the server node, it
seems that any changes in the class code on the client node will not be
seen on the server. To test this I repeated the same "steps to reproduce"
from my previous mail, with the CONTINUOUS deployment mode on both the
server and the client node. As you wrote, in this mode the 2nd client test
passed. Then I changed the Task class on the client node to write a
different message to the console, eg:
System.err.println("task called 2");
When the test runs, the new message is printed only on the client node, but
the server node still has the old version of the class and prints out the
old, obsolete message. Then I tried to change the serialVersionUID of the
class to somehow "force" the redeployment on the class but this caused a
problem on the client side, when attempting to fill the queue (please see
below for stack trace). This is especially strange because the queue was
empty, so how come the old serialVersionUID prevents filling the queue? I
thought that maybe the queue, even though empty, preserved some internal
state and this caused the problem. To check this I tried to call "close" on
the queue (if exists), and then recreating it again before filling:
IgniteQueue<Task> queue = ignite.queue("myTaskQueue", 0, null);
if (queue != null)
{
queue.close();
}
queue = ignite.queue("myTaskQueue", 0, new CollectionConfiguration());
queue.clear();
queue.addAll(Collections.nCopies(100, new Task()));
Any hints/suggestions?
Thanks!
-Mateusz
And here's the stack trace of the problem when attempting to fill the queue
(I think you could easily reproduce it on your side):
Exception in thread "main" class org.apache.ignite.IgniteException: Failed
to find class with given class loader for unmarshalling (make sure same
version of all classes are available on all nodes or enable
peer-class-loading):
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CacheClassLoader@545d1fea
at
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:881)
at
org.apache.ignite.internal.processors.datastructures.GridAtomicCacheQueueImpl.addAll(GridAtomicCacheQueueImpl.java:186)
at
org.apache.ignite.internal.processors.datastructures.GridCacheQueueProxy.addAll(GridCacheQueueProxy.java:146)
at ignitetest.Test.main(Test.java:31)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to find
class with given class loader for unmarshalling (make sure same version of
all classes are available on all nodes or enable peer-class-loading):
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CacheClassLoader@545d1fea
at
org.apache.ignite.marshaller.optimized.OptimizedMarshaller.unmarshal(OptimizedMarshaller.java:246)
at
org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.unmarshal(IgniteCacheObjectProcessorImpl.java:101)
at
org.apache.ignite.internal.processors.cache.portable.CacheObjectPortableProcessorImpl.unmarshal(CacheObjectPortableProcessorImpl.java:730)
at
org.apache.ignite.internal.processors.cache.CacheObjectImpl.finishUnmarshal(CacheObjectImpl.java:104)
at
org.apache.ignite.internal.processors.cache.GridCacheMessage.finishUnmarshalCacheObjects(GridCacheMessage.java:534)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateRequest.finishUnmarshal(GridNearAtomicUpdateRequest.java:578)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1034)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:269)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
at
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
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.ClassNotFoundException: Optimized stream class
checksum mismatch (is same version of marshalled class present on all
nodes?) [expected=1, actual=2, cls=class ignitetest.Task]
at
org.apache.ignite.marshaller.optimized.OptimizedClassDescriptor.verifyChecksum(OptimizedClassDescriptor.java:824)
at
org.apache.ignite.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:806)
at
org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:315)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:365)
at
org.apache.ignite.marshaller.optimized.OptimizedMarshaller.unmarshal(OptimizedMarshaller.java:240)
... 16 more
On Fri, Oct 30, 2015 at 6:02 PM, Artem Shutak <[email protected]> wrote:
> Mateusz,
>
> I reproduced the issue and filed a bug:
> https://issues.apache.org/jira/browse/IGNITE-1823. You can track a
> progress
> of the issue there. Also you are welcome to fix it by yourself and provide
> a
> patch.
>
> I can suggest you next workarounds:
> - Use another DeploymentMode. For example in this case Ignite works fine
> with CONTINUOUS deployment mode.
> - Don't use peer class loading and add jars with custom tasks to classpath
> of server nodes.
>
> Thanks,
> Artem.
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Distributed-queue-problem-with-peerClassLoading-enabled-tp1762p1787.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>
