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/
