I was trying to demonstrate changing classes on a client node so that classes
on servers get replaced with new code, but the symptoms make me believe that
I don't understand the rules at all.  

The deployment mode is SHARED.   I read the instructions and creates an
ignite.xml with a different userVersion.

and install this on the client node in order to force the cause previously
loaded code versions to be reloaded.   But instead, I get this failure even
if I restart both server and client.


Caused by: class org.apache.ignite.IgniteDeploymentException: Task was not
deployed or was redeployed since task execution
[taskName=org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor$ClientChangeGlobalStateComputeRequest,
taskClsName=org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor$ClientChangeGlobalStateComputeRequest,
codeVer=3, clsLdrId=ff87e49a161-695076b6-c96f-40ec-beb6-9897f3210dee,
seqNum=1518963947775, depMode=SHARED, dep=null]

        at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1160)

        at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1913)

        at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)

        at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)

        at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)

        at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)

        at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

        at java.lang.Thread.run(Thread.java:748)

which seems to be due to "codeVer=3".   I can change the 3 to 0, and it goes
back to working.


The original problem I had was I changed a field in a static statistics
class deployed as part of a [Data]StreamReciever from Long to AtomicLong,
and the BinaryObject schema merging complained about this.  So I renamed the
field, but kept getting the same error with the old field name, so I assumed
that the code was not getting replaced on the server, because I needed to
communicate that the version changed.      The error was being thrown as
part of responding to a call for statistics.     Because we are in SHARED
mode, as I read this now, restarting the client should have been sufficient
to replace the code.   So perhaps instead something has remembered the
intermediate schema that could not be merged? I would have assumed that the
intermediate unmerged schema would have been discarded.   




--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Reply via email to