Re: Message grid failure due to userVersion setting

[Ilya Kasnacheev]

Hello!

I think we should just wait for someone to tackle IGNITE-7905
 (or actively contribute
for a chance).

Regards,
-- 
Ilya Kasnacheev


вт, 18 сент. 2018 г. в 21:59, Dave Harvey :

> Thanks Ilya,
>
> As I understand  this a bit more, it seems like IGNITE-7905
>  is really the same
> basic flaw in user version not working as documented. Ignite-7905
> reproduction is simply to set a non-zero userVersion in a ignite.xml (
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/DeploymentMode.html),
> and then
>
> // Connect to the cluster.Ignite ignite = Ignition.start();
> // Activate the cluster. Automatic topology initialization occurs // only if 
> you manually activate the cluster for the very first time. 
> ignite.cluster().active(true);
>
>
> The activation then throws an exception on the server, because the server
> already has the same built-in Ignite class.
>
> As I understand the documentation, since the built in Ignite class is not
> excluded, it should not even consider peer class loading because the class
> exists locally.It should just use the local class.
>
> -DH
>
> On Tue, Sep 18, 2018 at 9:00 AM Ilya Kasnacheev 
> wrote:
>
>> Hello!
>>
>> I'm not familiar with these areas very much, but if you had a reproducer
>> project I could take a look.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> пн, 17 сент. 2018 г. в 19:32, Dave Harvey :
>>
>>> I probably did not explain this clearly.  When sending a message from
>>> server to client using the message grid, from a context unrelated to any
>>> client call, the server, as you would expect uses its installed libraries,
>>> and userVersion 0.For some reason, when the client receives this
>>> message, it require that the user version match it's current user version.
>>>
>>> The use case is we have a stable set of libraries on the server, and the
>>> server wants to send a topic based message to the client, using only the
>>> type "String".   Unrelated to this, the client is using the compute grid,
>>> where P2P is used, but that is interfering with basic functionality.
>>> This,  IGNITE-7905  ,
>>> and the paucity  of  results when I google for "ignite userVersion"  makes
>>> it clear that shooting down classes in CONTINUOUS mode with userVersion is
>>> not completely thought through.  We certainly never want to set a
>>> userVersion on the servers.
>>>
>>> The documentation for P2P says:
>>> "
>>>
>>>1. Ignite will check if class is available on local classpath (i.e.
>>>if it was loaded at system startup), and if it was, it will be returned. 
>>> No
>>>class loading from a peer node will take place in this case."
>>>
>>> Clearly, java.lang.String is on the local class path.So it seems
>>> like a user version mismatch should not be a reason to reject a class that
>>> is on the local classpath.
>>>
>>> On Mon, Sep 17, 2018 at 11:01 AM Ilya Kasnacheev <
>>> ilya.kasnach...@gmail.com> wrote:
>>>
 Hello!

 I think that Ignite cannot unload old version of code, unless it is
 loaded with something like URI deployment module.
 Version checking is there but server can't get rid of old code if it's
 on classpath.

 Regards,
 --
 Ilya Kasnacheev


 пн, 17 сент. 2018 г. в 16:47, Dave Harvey :

> We have a client that uses the compute grid and message grid, as well
> as the discovery API.  It communicates with a server plugin.   The cluster
> is configured for CONTINUOUS peer class loading.  In order to force the
> proper code to be loaded for the compute tasks, we change the user 
> version,
> e.g., to 2.
>
> If the server sends the client a message on the message grid, using
> java.lang.string, the client fails because the user version sent for
> java.lang.string is 0, but the client insists on 2.
>
> How is this supposed to work?   Our expectation was that the message
> grid should not be affected by peer class loading settings.
>
>
>
>
> *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 Click 

Re: Message grid failure due to userVersion setting

[Dave Harvey]

Thanks Ilya,

As I understand  this a bit more, it seems like IGNITE-7905
 is really the same
basic flaw in user version not working as documented. Ignite-7905
reproduction is simply to set a non-zero userVersion in a ignite.xml (
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/DeploymentMode.html),
and then

// Connect to the cluster.Ignite ignite = Ignition.start();
// Activate the cluster. Automatic topology initialization occurs //
only if you manually activate the cluster for the very first time.
ignite.cluster().active(true);


The activation then throws an exception on the server, because the server
already has the same built-in Ignite class.

As I understand the documentation, since the built in Ignite class is not
excluded, it should not even consider peer class loading because the class
exists locally.It should just use the local class.

-DH

On Tue, Sep 18, 2018 at 9:00 AM Ilya Kasnacheev 
wrote:

> Hello!
>
> I'm not familiar with these areas very much, but if you had a reproducer
> project I could take a look.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 17 сент. 2018 г. в 19:32, Dave Harvey :
>
>> I probably did not explain this clearly.  When sending a message from
>> server to client using the message grid, from a context unrelated to any
>> client call, the server, as you would expect uses its installed libraries,
>> and userVersion 0.For some reason, when the client receives this
>> message, it require that the user version match it's current user version.
>>
>> The use case is we have a stable set of libraries on the server, and the
>> server wants to send a topic based message to the client, using only the
>> type "String".   Unrelated to this, the client is using the compute grid,
>> where P2P is used, but that is interfering with basic functionality.
>> This,  IGNITE-7905  ,
>> and the paucity  of  results when I google for "ignite userVersion"  makes
>> it clear that shooting down classes in CONTINUOUS mode with userVersion is
>> not completely thought through.  We certainly never want to set a
>> userVersion on the servers.
>>
>> The documentation for P2P says:
>> "
>>
>>1. Ignite will check if class is available on local classpath (i.e.
>>if it was loaded at system startup), and if it was, it will be returned. 
>> No
>>class loading from a peer node will take place in this case."
>>
>> Clearly, java.lang.String is on the local class path.So it seems like
>> a user version mismatch should not be a reason to reject a class that is on
>> the local classpath.
>>
>> On Mon, Sep 17, 2018 at 11:01 AM Ilya Kasnacheev <
>> ilya.kasnach...@gmail.com> wrote:
>>
>>> Hello!
>>>
>>> I think that Ignite cannot unload old version of code, unless it is
>>> loaded with something like URI deployment module.
>>> Version checking is there but server can't get rid of old code if it's
>>> on classpath.
>>>
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>>
>>>
>>> пн, 17 сент. 2018 г. в 16:47, Dave Harvey :
>>>
 We have a client that uses the compute grid and message grid, as well
 as the discovery API.  It communicates with a server plugin.   The cluster
 is configured for CONTINUOUS peer class loading.  In order to force the
 proper code to be loaded for the compute tasks, we change the user version,
 e.g., to 2.

 If the server sends the client a message on the message grid, using
 java.lang.string, the client fails because the user version sent for
 java.lang.string is 0, but the client insists on 2.

 How is this supposed to work?   Our expectation was that the message
 grid should not be affected by peer class loading settings.




 *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 Click Here
 .

>>>
>>
>> *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 

Re: Message grid failure due to userVersion setting

[Ilya Kasnacheev]

Hello!

I'm not familiar with these areas very much, but if you had a reproducer
project I could take a look.

Regards,
-- 
Ilya Kasnacheev


пн, 17 сент. 2018 г. в 19:32, Dave Harvey :

> I probably did not explain this clearly.  When sending a message from
> server to client using the message grid, from a context unrelated to any
> client call, the server, as you would expect uses its installed libraries,
> and userVersion 0.For some reason, when the client receives this
> message, it require that the user version match it's current user version.
>
> The use case is we have a stable set of libraries on the server, and the
> server wants to send a topic based message to the client, using only the
> type "String".   Unrelated to this, the client is using the compute grid,
> where P2P is used, but that is interfering with basic functionality.
> This,  IGNITE-7905  ,
> and the paucity  of  results when I google for "ignite userVersion"  makes
> it clear that shooting down classes in CONTINUOUS mode with userVersion is
> not completely thought through.  We certainly never want to set a
> userVersion on the servers.
>
> The documentation for P2P says:
> "
>
>1. Ignite will check if class is available on local classpath (i.e. if
>it was loaded at system startup), and if it was, it will be returned. No
>class loading from a peer node will take place in this case."
>
> Clearly, java.lang.String is on the local class path.So it seems like
> a user version mismatch should not be a reason to reject a class that is on
> the local classpath.
>
> On Mon, Sep 17, 2018 at 11:01 AM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com> wrote:
>
>> Hello!
>>
>> I think that Ignite cannot unload old version of code, unless it is
>> loaded with something like URI deployment module.
>> Version checking is there but server can't get rid of old code if it's on
>> classpath.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> пн, 17 сент. 2018 г. в 16:47, Dave Harvey :
>>
>>> We have a client that uses the compute grid and message grid, as well as
>>> the discovery API.  It communicates with a server plugin.   The cluster is
>>> configured for CONTINUOUS peer class loading.  In order to force the proper
>>> code to be loaded for the compute tasks, we change the user version, e.g.,
>>> to 2.
>>>
>>> If the server sends the client a message on the message grid, using
>>> java.lang.string, the client fails because the user version sent for
>>> java.lang.string is 0, but the client insists on 2.
>>>
>>> How is this supposed to work?   Our expectation was that the message
>>> grid should not be affected by peer class loading settings.
>>>
>>>
>>>
>>>
>>> *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 Click Here
>>> .
>>>
>>
>
> *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 Click Here
> .
>

Re: Message grid failure due to userVersion setting

[Dave Harvey]

I probably did not explain this clearly.  When sending a message from
server to client using the message grid, from a context unrelated to any
client call, the server, as you would expect uses its installed libraries,
and userVersion 0.For some reason, when the client receives this
message, it require that the user version match it's current user version.

The use case is we have a stable set of libraries on the server, and the
server wants to send a topic based message to the client, using only the
type "String".   Unrelated to this, the client is using the compute grid,
where P2P is used, but that is interfering with basic functionality.
This,  IGNITE-7905  ,
and the paucity  of  results when I google for "ignite userVersion"  makes
it clear that shooting down classes in CONTINUOUS mode with userVersion is
not completely thought through.  We certainly never want to set a
userVersion on the servers.

The documentation for P2P says:
"

   1. Ignite will check if class is available on local classpath (i.e. if
   it was loaded at system startup), and if it was, it will be returned. No
   class loading from a peer node will take place in this case."

Clearly, java.lang.String is on the local class path.So it seems like a
user version mismatch should not be a reason to reject a class that is on
the local classpath.

On Mon, Sep 17, 2018 at 11:01 AM Ilya Kasnacheev 
wrote:

> Hello!
>
> I think that Ignite cannot unload old version of code, unless it is loaded
> with something like URI deployment module.
> Version checking is there but server can't get rid of old code if it's on
> classpath.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 17 сент. 2018 г. в 16:47, Dave Harvey :
>
>> We have a client that uses the compute grid and message grid, as well as
>> the discovery API.  It communicates with a server plugin.   The cluster is
>> configured for CONTINUOUS peer class loading.  In order to force the proper
>> code to be loaded for the compute tasks, we change the user version, e.g.,
>> to 2.
>>
>> If the server sends the client a message on the message grid, using
>> java.lang.string, the client fails because the user version sent for
>> java.lang.string is 0, but the client insists on 2.
>>
>> How is this supposed to work?   Our expectation was that the message grid
>> should not be affected by peer class loading settings.
>>
>>
>>
>>
>> *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 Click Here
>> .
>>
>

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: Message grid failure due to userVersion setting

[Ilya Kasnacheev]

Hello!

I think that Ignite cannot unload old version of code, unless it is loaded
with something like URI deployment module.
Version checking is there but server can't get rid of old code if it's on
classpath.

Regards,
-- 
Ilya Kasnacheev


пн, 17 сент. 2018 г. в 16:47, Dave Harvey :

> We have a client that uses the compute grid and message grid, as well as
> the discovery API.  It communicates with a server plugin.   The cluster is
> configured for CONTINUOUS peer class loading.  In order to force the proper
> code to be loaded for the compute tasks, we change the user version, e.g.,
> to 2.
>
> If the server sends the client a message on the message grid, using
> java.lang.string, the client fails because the user version sent for
> java.lang.string is 0, but the client insists on 2.
>
> How is this supposed to work?   Our expectation was that the message grid
> should not be affected by peer class loading settings.
>
>
>
>
> *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 Click Here
> .
>

Message grid failure due to userVersion setting

[Dave Harvey]

We have a client that uses the compute grid and message grid, as well as
the discovery API.  It communicates with a server plugin.   The cluster is
configured for CONTINUOUS peer class loading.  In order to force the proper
code to be loaded for the compute tasks, we change the user version, e.g.,
to 2.

If the server sends the client a message on the message grid, using
java.lang.string, the client fails because the user version sent for
java.lang.string is 0, but the client insists on 2.

How is this supposed to work?   Our expectation was that the message grid
should not be affected by peer class loading settings.

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.