Re: Issues trying to force redeployment in shared mode

[David Harvey]

   1. I had created IGNITE-7905 for this interaction with userVersion and
   perhaps only ignite.Activate() issued from the client.  I think it deals
   with the code for Activate() using nested classes.  The server decided that
   it already had a version of the ignite code loaded, and wasn't going to
   accept a different version from the client.   My intent was to shoot down
   only my code.   When I stopped trying to activate the cluster from the
   client, this symptom disappeared.And in 2.4 the need to try to activate
   the cluster from the client went away.
   2. -DH
   3.
  


On Thu, Mar 22, 2018 at 12:00 PM, ilya.kasnacheev  wrote:

> Hello Dave!
>
> I suggest filling an issue agains Apache Ignite JIRA with this scenario and
> suggestions about how it should work after fix. Test case would be awesome.
>
> Regards,
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast Ltd, an innovator in Software as a Service 
(SaaS) for business. Providing a safer and more useful place for your human 
generated data. Specializing in; Security, archiving and compliance. To find 
out more visit the Mimecast website.

Re: Issues trying to force redeployment in shared mode

[ilya.kasnacheev]

Hello Dave!

I suggest filling an issue agains Apache Ignite JIRA with this scenario and
suggestions about how it should work after fix. Test case would be awesome.

Regards,



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

Re: Issues trying to force redeployment in shared mode

[Jim Rutt]

Unsubscribe


On Tue, Feb 20, 2018 at 1:09 PM Dave Harvey  wrote:

> I've done some additional testing.  By shutting down another (the last)
> client node that was running independent code, I was able to purge the bad
> version of my code from the servers, while leaving the userVersion at "0".
> Apparently in this case, the client nodes are "master" nodes.  (The
> deployment modes documentation uses the terms "master" and "workers"
> without
> defining them, so you are left to guess which nodes are master and how they
> become one.  Because they sent a closure?   Because some class was actually
> loaded from them?).
>
> Running from Eclipse with a local vanilla 2.3 docker image as a single
> server,  changing the userVersion ignite.xml from "0" to "1" on the client
> causes the error:  "Caused by: class
> org.apache.ignite.IgniteDeploymentException: Task was not deployed or was
> redeployed since task execution" , even if the server was just restarted.
> It starts working again of the user version changes back to "0".
>
> That is, /changing the userVersion on the client causes the client not to
> be
> able to talk to the server./  Since server will cache the userVersion on
> the
> first access, there doesn't seem to be a path to get the client's code to
> redeploy except by shutting down all clients, or by shutting down all
> servers.
>
>
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>
-- 
Jim Rutt
JPR Ventures

Re: Issues trying to force redeployment in shared mode

[Dave Harvey]

I've done some additional testing.  By shutting down another (the last)
client node that was running independent code, I was able to purge the bad
version of my code from the servers, while leaving the userVersion at "0".  
Apparently in this case, the client nodes are "master" nodes.  (The
deployment modes documentation uses the terms "master" and "workers" without
defining them, so you are left to guess which nodes are master and how they
become one.  Because they sent a closure?   Because some class was actually
loaded from them?).

Running from Eclipse with a local vanilla 2.3 docker image as a single
server,  changing the userVersion ignite.xml from "0" to "1" on the client
causes the error:  "Caused by: class
org.apache.ignite.IgniteDeploymentException: Task was not deployed or was
redeployed since task execution" , even if the server was just restarted. 
It starts working again of the user version changes back to "0".

That is, /changing the userVersion on the client causes the client not to be
able to talk to the server./  Since server will cache the userVersion on the
first access, there doesn't seem to be a path to get the client's code to
redeploy except by shutting down all clients, or by shutting down all
servers.






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

Issues trying to force redeployment in shared mode

[Dave Harvey]

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/