About peer class loading

classic Classic list List threaded Threaded
9 messages Options
tcostasouza tcostasouza
Reply | Threaded
Open this post in threaded view
|

About peer class loading

Hello there,

I'm building a POC infrastructure based on Ignite and I'm currently deciding if peer class loading in a production environment is a good idea or not.

If it's not enabled, the suggested strategy is to copy the jars do every single onde. So, my question is if Ignite monitors it's libs folder and update it's classpath at runtime or do I need to restart the node.

Regards
Ognen Duzlevski Ognen Duzlevski
Reply | Threaded
Open this post in threaded view
|

Re: About peer class loading

On Wed, May 27, 2015 at 9:31 AM, tcostasouza <[hidden email]> wrote:
Hello there,

I'm building a POC infrastructure based on Ignite and I'm currently deciding
if peer class loading in a production environment is a good idea or not.

If it's not enabled, the suggested strategy is to copy the jars do every
single onde. So, my question is if Ignite monitors it's libs folder and
update it's classpath at runtime or do I need to restart the node.

You can test this easily and as far as I can see it does not monitor the ignite/lib for changes and it does not to automatic reloads. This is one question that kind of screws it all up for production - imagine having a large cluster that needs to be brought down and restarted after you copied the jar around, each time you deploy a new version of an application.

Ognen 
tcostasouza tcostasouza
Reply | Threaded
Open this post in threaded view
|

Re: About peer class loading

Hello Ognen,

That's the exactly situation I'm trying to avoid.

One strategy that I'm planning to test is, for each physical cluster node, fire up a new ignite node with the updated code and the take down the old one. Effectively doing a rolling update of the cluster.

But it's hard to tell what would be the effects in application runtime. One thing for sure, the new code must be backward compatible with the old one, or else, bad things will follow.

Regards


On Wed, May 27, 2015, 12:53 Ognen Duzlevski [via Apache Ignite Users] <[hidden email]> wrote:
On Wed, May 27, 2015 at 9:31 AM, tcostasouza <[hidden email]> wrote:
Hello there,

I'm building a POC infrastructure based on Ignite and I'm currently deciding
if peer class loading in a production environment is a good idea or not.

If it's not enabled, the suggested strategy is to copy the jars do every
single onde. So, my question is if Ignite monitors it's libs folder and
update it's classpath at runtime or do I need to restart the node.

You can test this easily and as far as I can see it does not monitor the ignite/lib for changes and it does not to automatic reloads. This is one question that kind of screws it all up for production - imagine having a large cluster that needs to be brought down and restarted after you copied the jar around, each time you deploy a new version of an application.

Ognen 



If you reply to this email, your message will be added to the discussion below:
http://apache-ignite-users.70518.x6.nabble.com/About-peer-class-loading-tp416p417.html
To unsubscribe from About peer class loading, click here.
NAML
Ognen Duzlevski Ognen Duzlevski
Reply | Threaded
Open this post in threaded view
|

Re: About peer class loading

On Wed, May 27, 2015 at 11:02 AM, tcostasouza <[hidden email]> wrote:

Hello Ognen,

That's the exactly situation I'm trying to avoid.

One strategy that I'm planning to test is, for each physical cluster node, fire up a new ignite node with the updated code and the take down the old one. Effectively doing a rolling update of the cluster.

But it's hard to tell what would be the effects in application runtime. One thing for sure, the new code must be backward compatible with the old one, or else, bad things will follow.


Yeah, one issue will be the mix of old and new classes in the cache as you are "rolling". Especially if you have two different versions of the same class.
dsetrakyan dsetrakyan
Reply | Threaded
Open this post in threaded view
|

Re: About peer class loading

This post was updated on .
If you enable peer class loading, you can use either SHARED or CONTINUOUS deployment modes in cache. In either mode Ignite will automatically deploy your classes without having to copy jars into the lib folder.

In SHARED mode, once Ignite detects that all client nodes have left, it will clear up all the caches. This mode is useful during the development.

In CONTINUOUS mode Ignite will not clear caches once the clients have left, but in this case it is up to the user to ensure that class definitions don't change throughout the life time of the cluster.

Unfortunately, both of these modes will require you to restart the cluster if you change your data classes. The reason for that is that Ignite does not allow to have classes from different class loaders residing in the same cache.
tcostasouza tcostasouza
Reply | Threaded
Open this post in threaded view
|

Re: About peer class loading

Hello Dmitryi,

Can Ignite cache work with dynamic structures (e.g. maps and lists) and still be able to run queries?

BTW, does Ignite supports insert/update SQL?

Regards
dsetrakyan dsetrakyan
Reply | Threaded
Open this post in threaded view
|

Re: About peer class loading


On Wed, May 27, 2015 at 11:53 PM, tcostasouza <[hidden email]> wrote:
Can Ignite cache work with dynamic structures (e.g. maps and lists) and
still be able to run queries?

Yes for predicate-based queries. As far as SQL, my initial guess would be No, but I could be wrong. Can someone else confirm this?
 
BTW, does Ignite supports insert/update SQL?

Only read-only SQL queries are supported (SQL-99 compliant). For inserts and updates you should use standard key-value API.
hueb1 hueb1
Reply | Threaded
Open this post in threaded view
|

Re: About peer class loading

In reply to this post by dsetrakyan
Let's say I have a running Ignite Service that instantiates instances of an interface via the Class.forName(..) method, where the name of the implementing class is read from a configuration file that exists in a distributed cache.  Upon initial deployment of the Ignite Service all implementations of the interface exists in the same jar.  Now I have a new implementation of the service in a different jar file.  What's the best approach to ensure the next time Class.forName(..) gets called with that new implementing class name, the class gets picked up?  Would it require me to start a new Ignite Service node with that new jar copied into the lib folder?
kcheng.mvp kcheng.mvp
Reply | Threaded
Open this post in threaded view
|

Re: About peer class loading