Re: Persistent Store example fails with NPE

[Denis Magda]

Well, merged the fix to the branch with the donation and closed the ticket:
https://issues.apache.org/jira/browse/IGNITE-5295 


—
Denis

> On May 26, 2017, at 1:25 PM, Denis Magda  wrote:
> 
> As I see from the AffinityFunction implementations, client nodes are not used 
> there that implies there is no way to deploy replicated and partitioned 
> caches there.
> 
> —
> Denis
> 
>> On May 26, 2017, at 12:19 PM, Dmitriy Setrakyan  
>> wrote:
>> 
>> On Fri, May 26, 2017 at 12:17 PM, Denis Magda  wrote:
>> 
>>> Local and near caches can be configured on clients. But you can still
>>> define replicated and partitioned ones in the clients’ configuration and
>>> they will be simply ignored. I want us to do the same for the persistent
>>> store (simply ignore it if it’s defined in a client’s configuration).
>>> 
>> 
>> Denis, are you absolutely 100% sure that there is no way to configure
>> normal cache on the client nodes? If yes, then I agree with you.
>> 
>> 
>>> Sounds reasonable?
>>> 
>>> 
>>> —
>>> Denis
>>> 
 On May 26, 2017, at 12:14 PM, Dmitriy Setrakyan 
>>> wrote:
 
 On Fri, May 26, 2017 at 11:59 AM, Denis Magda  wrote:
 
> Exactly, you can specify caches in the configuration of both clients and
> servers BUT the caches will be deployed on the servers only.
> This is why it’s absolutely fine to use a single configuration (with
> caches defined) for all your cluster nodes because Ignite can
>>> automatically
> figure out what doesn’t make sense for clients and what’s not.
> 
 
 Agree. But it is still possible to configure caches on the client side,
 right? All I want is for us to remain consistent and provide identical
 behavior with persistence enabled.
 
 
> 
> —
> Denis
> 
>> On May 26, 2017, at 11:46 AM, Dmitriy Setrakyan  wrote:
>> 
>> Denis,
>> 
>> I think I misunderstand the issue. How do we do it for caches? Caches
>>> are
>> only supposed to be enabled on the servers by default. Do we require a
>> different configuration file for clients and servers for the caches?
>> 
>> D.
>> 
>> On Fri, May 26, 2017 at 11:41 AM, Denis Magda 
>>> wrote:
>> 
>>> I tend to use a single XML configuration for all my cluster nodes
> (servers
>>> and clients). Presently, I forced to create and maintain at least 2.
> This
>>> is the first concern. The second concern is if persistence store has
>>> no
>>> effect for the client node why not simply ignore it and not make the
> user
>>> to set MemoryConfiguration explicitly if the goal is to use a single
>>> XML
>>> config.
>>> 
>>> —
>>> Denis
>>> 
 On May 26, 2017, at 11:33 AM, Dmitriy Setrakyan <
>>> dsetrak...@apache.org
>> 
>>> wrote:
 
 On Fri, May 26, 2017 at 11:29 AM, Denis Magda >> > wrote:
 
>> Can we just fix the exception
>> message to clearly state that client mode requires all explicit
>> configuration for such and such functionality?
> 
> I don’t like this. It will require me as a user:
> 
> * have a separate configuration for clients ALL the times.
> * initialize the memory bean explicitly which looks like a hack and
> workaround
> 
> 
> 
> 
> 
> 
> 
 Denis,
 
 Why would you even have a use case for a persistence configuration on
> the
 client side? What happened in your case was a mistake and you should
> have
 received a proper exception. I am simply suggesting that in the odd
> case
 that someone does need it, we provide proper error message explaining
 exactly what needs to be done. Why not?
 
 
>> On May 26, 2017, at 11:02 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org
 
> wrote:
>> 
>> I don't like ignoring any configuration, but I do agree that
>>> enabling
>> persistence on the client side seems odd. Can we just fix the
> exception
>> message to clearly state that client mode requires all explicit
>> configuration for such and such functionality?
>> 
>> D.
>> 
>> On Fri, May 26, 2017 at 10:34 AM, Sergey Chugunov <
> sergey.chugu...@gmail.com
>>> wrote:
>> 
>>> Denis,
>>> 
>>> Thanks for quick reply,
>>> 
>>> I made a change and tested it with your example, everything looks
>>> fine.
>>> 
>>> Pull request is open and available at [1]
>>> 
>>> [1] 

Re: Persistent Store example fails with NPE

[Denis Magda]

As I see from the AffinityFunction implementations, client nodes are not used 
there that implies there is no way to deploy replicated and partitioned caches 
there.

—
Denis

> On May 26, 2017, at 12:19 PM, Dmitriy Setrakyan  wrote:
> 
> On Fri, May 26, 2017 at 12:17 PM, Denis Magda  wrote:
> 
>> Local and near caches can be configured on clients. But you can still
>> define replicated and partitioned ones in the clients’ configuration and
>> they will be simply ignored. I want us to do the same for the persistent
>> store (simply ignore it if it’s defined in a client’s configuration).
>> 
> 
> Denis, are you absolutely 100% sure that there is no way to configure
> normal cache on the client nodes? If yes, then I agree with you.
> 
> 
>> Sounds reasonable?
>> 
>> 
>> —
>> Denis
>> 
>>> On May 26, 2017, at 12:14 PM, Dmitriy Setrakyan 
>> wrote:
>>> 
>>> On Fri, May 26, 2017 at 11:59 AM, Denis Magda  wrote:
>>> 
 Exactly, you can specify caches in the configuration of both clients and
 servers BUT the caches will be deployed on the servers only.
 This is why it’s absolutely fine to use a single configuration (with
 caches defined) for all your cluster nodes because Ignite can
>> automatically
 figure out what doesn’t make sense for clients and what’s not.
 
>>> 
>>> Agree. But it is still possible to configure caches on the client side,
>>> right? All I want is for us to remain consistent and provide identical
>>> behavior with persistence enabled.
>>> 
>>> 
 
 —
 Denis
 
> On May 26, 2017, at 11:46 AM, Dmitriy Setrakyan >> 
 wrote:
> 
> Denis,
> 
> I think I misunderstand the issue. How do we do it for caches? Caches
>> are
> only supposed to be enabled on the servers by default. Do we require a
> different configuration file for clients and servers for the caches?
> 
> D.
> 
> On Fri, May 26, 2017 at 11:41 AM, Denis Magda 
>> wrote:
> 
>> I tend to use a single XML configuration for all my cluster nodes
 (servers
>> and clients). Presently, I forced to create and maintain at least 2.
 This
>> is the first concern. The second concern is if persistence store has
>> no
>> effect for the client node why not simply ignore it and not make the
 user
>> to set MemoryConfiguration explicitly if the goal is to use a single
>> XML
>> config.
>> 
>> —
>> Denis
>> 
>>> On May 26, 2017, at 11:33 AM, Dmitriy Setrakyan <
>> dsetrak...@apache.org
> 
>> wrote:
>>> 
>>> On Fri, May 26, 2017 at 11:29 AM, Denis Magda > > wrote:
>>> 
> Can we just fix the exception
> message to clearly state that client mode requires all explicit
> configuration for such and such functionality?
 
 I don’t like this. It will require me as a user:
 
 * have a separate configuration for clients ALL the times.
 * initialize the memory bean explicitly which looks like a hack and
 workaround
 
 
 
 
 
 
 
>>> Denis,
>>> 
>>> Why would you even have a use case for a persistence configuration on
 the
>>> client side? What happened in your case was a mistake and you should
 have
>>> received a proper exception. I am simply suggesting that in the odd
 case
>>> that someone does need it, we provide proper error message explaining
>>> exactly what needs to be done. Why not?
>>> 
>>> 
> On May 26, 2017, at 11:02 AM, Dmitriy Setrakyan <
 dsetrak...@apache.org
>>> 
 wrote:
> 
> I don't like ignoring any configuration, but I do agree that
>> enabling
> persistence on the client side seems odd. Can we just fix the
 exception
> message to clearly state that client mode requires all explicit
> configuration for such and such functionality?
> 
> D.
> 
> On Fri, May 26, 2017 at 10:34 AM, Sergey Chugunov <
 sergey.chugu...@gmail.com
>> wrote:
> 
>> Denis,
>> 
>> Thanks for quick reply,
>> 
>> I made a change and tested it with your example, everything looks
>> fine.
>> 
>> Pull request is open and available at [1]
>> 
>> [1] https://github.com/apache/ignite/pull/2016
>> 
>> On Fri, May 26, 2017 at 8:25 PM, Denis Magda 
>> wrote:
>> 
 I would suggest on the first iteration to simply ignore
 persistence
 configuration on client nodes.
 If client node finds persistence configuration on startup it
>> will
>>> printout
 warning message to log and proceed 

Re: Persistent Store example fails with NPE

[Dmitriy Setrakyan]

On Fri, May 26, 2017 at 12:17 PM, Denis Magda  wrote:

> Local and near caches can be configured on clients. But you can still
> define replicated and partitioned ones in the clients’ configuration and
> they will be simply ignored. I want us to do the same for the persistent
> store (simply ignore it if it’s defined in a client’s configuration).
>

Denis, are you absolutely 100% sure that there is no way to configure
normal cache on the client nodes? If yes, then I agree with you.


> Sounds reasonable?
>
>
> —
> Denis
>
> > On May 26, 2017, at 12:14 PM, Dmitriy Setrakyan 
> wrote:
> >
> > On Fri, May 26, 2017 at 11:59 AM, Denis Magda  wrote:
> >
> >> Exactly, you can specify caches in the configuration of both clients and
> >> servers BUT the caches will be deployed on the servers only.
> >> This is why it’s absolutely fine to use a single configuration (with
> >> caches defined) for all your cluster nodes because Ignite can
> automatically
> >> figure out what doesn’t make sense for clients and what’s not.
> >>
> >
> > Agree. But it is still possible to configure caches on the client side,
> > right? All I want is for us to remain consistent and provide identical
> > behavior with persistence enabled.
> >
> >
> >>
> >> —
> >> Denis
> >>
> >>> On May 26, 2017, at 11:46 AM, Dmitriy Setrakyan  >
> >> wrote:
> >>>
> >>> Denis,
> >>>
> >>> I think I misunderstand the issue. How do we do it for caches? Caches
> are
> >>> only supposed to be enabled on the servers by default. Do we require a
> >>> different configuration file for clients and servers for the caches?
> >>>
> >>> D.
> >>>
> >>> On Fri, May 26, 2017 at 11:41 AM, Denis Magda 
> wrote:
> >>>
>  I tend to use a single XML configuration for all my cluster nodes
> >> (servers
>  and clients). Presently, I forced to create and maintain at least 2.
> >> This
>  is the first concern. The second concern is if persistence store has
> no
>  effect for the client node why not simply ignore it and not make the
> >> user
>  to set MemoryConfiguration explicitly if the goal is to use a single
> XML
>  config.
> 
>  —
>  Denis
> 
> > On May 26, 2017, at 11:33 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> >>>
>  wrote:
> >
> > On Fri, May 26, 2017 at 11:29 AM, Denis Magda   > wrote:
> >
> >>> Can we just fix the exception
> >>> message to clearly state that client mode requires all explicit
> >>> configuration for such and such functionality?
> >>
> >> I don’t like this. It will require me as a user:
> >>
> >> * have a separate configuration for clients ALL the times.
> >> * initialize the memory bean explicitly which looks like a hack and
> >> workaround
> >>
> >> 
> >> 
> >> 
> >> 
> >>
> >>
> > Denis,
> >
> > Why would you even have a use case for a persistence configuration on
> >> the
> > client side? What happened in your case was a mistake and you should
> >> have
> > received a proper exception. I am simply suggesting that in the odd
> >> case
> > that someone does need it, we provide proper error message explaining
> > exactly what needs to be done. Why not?
> >
> >
> >>> On May 26, 2017, at 11:02 AM, Dmitriy Setrakyan <
> >> dsetrak...@apache.org
> >
> >> wrote:
> >>>
> >>> I don't like ignoring any configuration, but I do agree that
> enabling
> >>> persistence on the client side seems odd. Can we just fix the
> >> exception
> >>> message to clearly state that client mode requires all explicit
> >>> configuration for such and such functionality?
> >>>
> >>> D.
> >>>
> >>> On Fri, May 26, 2017 at 10:34 AM, Sergey Chugunov <
> >> sergey.chugu...@gmail.com
>  wrote:
> >>>
>  Denis,
> 
>  Thanks for quick reply,
> 
>  I made a change and tested it with your example, everything looks
>  fine.
> 
>  Pull request is open and available at [1]
> 
>  [1] https://github.com/apache/ignite/pull/2016
> 
>  On Fri, May 26, 2017 at 8:25 PM, Denis Magda 
>  wrote:
> 
> >> I would suggest on the first iteration to simply ignore
> >> persistence
> >> configuration on client nodes.
> >> If client node finds persistence configuration on startup it
> will
> > printout
> >> warning message to log and proceed without persistence.
> >
> > +1 for this. Otherwise, it looks like a dirty hack when I need to
> >> add
> >> an
> > empty MemoryConfiguration to a client config file. Plus, it
> >> requires
>  us
>  to
> > create different configuration files for servers and clients
> which
>  has
> 

Re: Persistent Store example fails with NPE

[Denis Magda]

Local and near caches can be configured on clients. But you can still define 
replicated and partitioned ones in the clients’ configuration and they will be 
simply ignored. I want us to do the same for the persistent store (simply 
ignore it if it’s defined in a client’s configuration).

Sounds reasonable?


—
Denis

> On May 26, 2017, at 12:14 PM, Dmitriy Setrakyan  wrote:
> 
> On Fri, May 26, 2017 at 11:59 AM, Denis Magda  wrote:
> 
>> Exactly, you can specify caches in the configuration of both clients and
>> servers BUT the caches will be deployed on the servers only.
>> This is why it’s absolutely fine to use a single configuration (with
>> caches defined) for all your cluster nodes because Ignite can automatically
>> figure out what doesn’t make sense for clients and what’s not.
>> 
> 
> Agree. But it is still possible to configure caches on the client side,
> right? All I want is for us to remain consistent and provide identical
> behavior with persistence enabled.
> 
> 
>> 
>> —
>> Denis
>> 
>>> On May 26, 2017, at 11:46 AM, Dmitriy Setrakyan 
>> wrote:
>>> 
>>> Denis,
>>> 
>>> I think I misunderstand the issue. How do we do it for caches? Caches are
>>> only supposed to be enabled on the servers by default. Do we require a
>>> different configuration file for clients and servers for the caches?
>>> 
>>> D.
>>> 
>>> On Fri, May 26, 2017 at 11:41 AM, Denis Magda  wrote:
>>> 
 I tend to use a single XML configuration for all my cluster nodes
>> (servers
 and clients). Presently, I forced to create and maintain at least 2.
>> This
 is the first concern. The second concern is if persistence store has no
 effect for the client node why not simply ignore it and not make the
>> user
 to set MemoryConfiguration explicitly if the goal is to use a single XML
 config.
 
 —
 Denis
 
> On May 26, 2017, at 11:33 AM, Dmitriy Setrakyan >> 
 wrote:
> 
> On Fri, May 26, 2017 at 11:29 AM, Denis Magda > wrote:
> 
>>> Can we just fix the exception
>>> message to clearly state that client mode requires all explicit
>>> configuration for such and such functionality?
>> 
>> I don’t like this. It will require me as a user:
>> 
>> * have a separate configuration for clients ALL the times.
>> * initialize the memory bean explicitly which looks like a hack and
>> workaround
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> Denis,
> 
> Why would you even have a use case for a persistence configuration on
>> the
> client side? What happened in your case was a mistake and you should
>> have
> received a proper exception. I am simply suggesting that in the odd
>> case
> that someone does need it, we provide proper error message explaining
> exactly what needs to be done. Why not?
> 
> 
>>> On May 26, 2017, at 11:02 AM, Dmitriy Setrakyan <
>> dsetrak...@apache.org
> 
>> wrote:
>>> 
>>> I don't like ignoring any configuration, but I do agree that enabling
>>> persistence on the client side seems odd. Can we just fix the
>> exception
>>> message to clearly state that client mode requires all explicit
>>> configuration for such and such functionality?
>>> 
>>> D.
>>> 
>>> On Fri, May 26, 2017 at 10:34 AM, Sergey Chugunov <
>> sergey.chugu...@gmail.com
 wrote:
>>> 
 Denis,
 
 Thanks for quick reply,
 
 I made a change and tested it with your example, everything looks
 fine.
 
 Pull request is open and available at [1]
 
 [1] https://github.com/apache/ignite/pull/2016
 
 On Fri, May 26, 2017 at 8:25 PM, Denis Magda 
 wrote:
 
>> I would suggest on the first iteration to simply ignore
>> persistence
>> configuration on client nodes.
>> If client node finds persistence configuration on startup it will
> printout
>> warning message to log and proceed without persistence.
> 
> +1 for this. Otherwise, it looks like a dirty hack when I need to
>> add
>> an
> empty MemoryConfiguration to a client config file. Plus, it
>> requires
 us
 to
> create different configuration files for servers and clients which
 has
>> to
> be optional by default.
> 
> —
> Denis
> 
>> On May 26, 2017, at 9:50 AM, Sergey Chugunov <
 sergey.chugu...@gmail.com>
> wrote:
>> 
>> Moreover, enabling persistence on client node is very risky and
>> may
 lead
> to
>> many tricky cases.
>> 
>> I would suggest on the first iteration to simply ignore
>> persistence
>> 

Re: Persistent Store example fails with NPE

[Dmitriy Setrakyan]

On Fri, May 26, 2017 at 11:59 AM, Denis Magda  wrote:

> Exactly, you can specify caches in the configuration of both clients and
> servers BUT the caches will be deployed on the servers only.
> This is why it’s absolutely fine to use a single configuration (with
> caches defined) for all your cluster nodes because Ignite can automatically
> figure out what doesn’t make sense for clients and what’s not.
>

Agree. But it is still possible to configure caches on the client side,
right? All I want is for us to remain consistent and provide identical
behavior with persistence enabled.


>
> —
> Denis
>
> > On May 26, 2017, at 11:46 AM, Dmitriy Setrakyan 
> wrote:
> >
> > Denis,
> >
> > I think I misunderstand the issue. How do we do it for caches? Caches are
> > only supposed to be enabled on the servers by default. Do we require a
> > different configuration file for clients and servers for the caches?
> >
> > D.
> >
> > On Fri, May 26, 2017 at 11:41 AM, Denis Magda  wrote:
> >
> >> I tend to use a single XML configuration for all my cluster nodes
> (servers
> >> and clients). Presently, I forced to create and maintain at least 2.
> This
> >> is the first concern. The second concern is if persistence store has no
> >> effect for the client node why not simply ignore it and not make the
> user
> >> to set MemoryConfiguration explicitly if the goal is to use a single XML
> >> config.
> >>
> >> —
> >> Denis
> >>
> >>> On May 26, 2017, at 11:33 AM, Dmitriy Setrakyan  >
> >> wrote:
> >>>
> >>> On Fri, May 26, 2017 at 11:29 AM, Denis Magda  >> > wrote:
> >>>
> > Can we just fix the exception
> > message to clearly state that client mode requires all explicit
> > configuration for such and such functionality?
> 
>  I don’t like this. It will require me as a user:
> 
>  * have a separate configuration for clients ALL the times.
>  * initialize the memory bean explicitly which looks like a hack and
>  workaround
> 
>  
>   
>   
>  
> 
> 
> >>> Denis,
> >>>
> >>> Why would you even have a use case for a persistence configuration on
> the
> >>> client side? What happened in your case was a mistake and you should
> have
> >>> received a proper exception. I am simply suggesting that in the odd
> case
> >>> that someone does need it, we provide proper error message explaining
> >>> exactly what needs to be done. Why not?
> >>>
> >>>
> > On May 26, 2017, at 11:02 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> >>>
>  wrote:
> >
> > I don't like ignoring any configuration, but I do agree that enabling
> > persistence on the client side seems odd. Can we just fix the
> exception
> > message to clearly state that client mode requires all explicit
> > configuration for such and such functionality?
> >
> > D.
> >
> > On Fri, May 26, 2017 at 10:34 AM, Sergey Chugunov <
>  sergey.chugu...@gmail.com
> >> wrote:
> >
> >> Denis,
> >>
> >> Thanks for quick reply,
> >>
> >> I made a change and tested it with your example, everything looks
> >> fine.
> >>
> >> Pull request is open and available at [1]
> >>
> >> [1] https://github.com/apache/ignite/pull/2016
> >>
> >> On Fri, May 26, 2017 at 8:25 PM, Denis Magda 
> >> wrote:
> >>
>  I would suggest on the first iteration to simply ignore
> persistence
>  configuration on client nodes.
>  If client node finds persistence configuration on startup it will
> >>> printout
>  warning message to log and proceed without persistence.
> >>>
> >>> +1 for this. Otherwise, it looks like a dirty hack when I need to
> add
>  an
> >>> empty MemoryConfiguration to a client config file. Plus, it
> requires
> >> us
> >> to
> >>> create different configuration files for servers and clients which
> >> has
>  to
> >>> be optional by default.
> >>>
> >>> —
> >>> Denis
> >>>
>  On May 26, 2017, at 9:50 AM, Sergey Chugunov <
> >> sergey.chugu...@gmail.com>
> >>> wrote:
> 
>  Moreover, enabling persistence on client node is very risky and
> may
> >> lead
> >>> to
>  many tricky cases.
> 
>  I would suggest on the first iteration to simply ignore
> persistence
>  configuration on client nodes.
>  If client node finds persistence configuration on startup it will
> >>> printout
>  warning message to log and proceed without persistence.
> 
>  Supporting persistence on client nodes definitely requires more
> >>> thoughtful
>  discussion and may be added in the future.
> 
>  Thanks,
>  Sergey.
> 
>  On Fri, May 26, 2017 at 7:28 PM, Sergey Chugunov <
> >>> 

Re: Persistent Store example fails with NPE

[Denis Magda]

Exactly, you can specify caches in the configuration of both clients and 
servers BUT the caches will be deployed on the servers only. 
This is why it’s absolutely fine to use a single configuration (with caches 
defined) for all your cluster nodes because Ignite can automatically figure out 
what doesn’t make sense for clients and what’s not.

—
Denis

> On May 26, 2017, at 11:46 AM, Dmitriy Setrakyan  wrote:
> 
> Denis,
> 
> I think I misunderstand the issue. How do we do it for caches? Caches are
> only supposed to be enabled on the servers by default. Do we require a
> different configuration file for clients and servers for the caches?
> 
> D.
> 
> On Fri, May 26, 2017 at 11:41 AM, Denis Magda  wrote:
> 
>> I tend to use a single XML configuration for all my cluster nodes (servers
>> and clients). Presently, I forced to create and maintain at least 2. This
>> is the first concern. The second concern is if persistence store has no
>> effect for the client node why not simply ignore it and not make the user
>> to set MemoryConfiguration explicitly if the goal is to use a single XML
>> config.
>> 
>> —
>> Denis
>> 
>>> On May 26, 2017, at 11:33 AM, Dmitriy Setrakyan 
>> wrote:
>>> 
>>> On Fri, May 26, 2017 at 11:29 AM, Denis Magda > > wrote:
>>> 
> Can we just fix the exception
> message to clearly state that client mode requires all explicit
> configuration for such and such functionality?
 
 I don’t like this. It will require me as a user:
 
 * have a separate configuration for clients ALL the times.
 * initialize the memory bean explicitly which looks like a hack and
 workaround
 
 
  
  
 
 
 
>>> Denis,
>>> 
>>> Why would you even have a use case for a persistence configuration on the
>>> client side? What happened in your case was a mistake and you should have
>>> received a proper exception. I am simply suggesting that in the odd case
>>> that someone does need it, we provide proper error message explaining
>>> exactly what needs to be done. Why not?
>>> 
>>> 
> On May 26, 2017, at 11:02 AM, Dmitriy Setrakyan >> 
 wrote:
> 
> I don't like ignoring any configuration, but I do agree that enabling
> persistence on the client side seems odd. Can we just fix the exception
> message to clearly state that client mode requires all explicit
> configuration for such and such functionality?
> 
> D.
> 
> On Fri, May 26, 2017 at 10:34 AM, Sergey Chugunov <
 sergey.chugu...@gmail.com
>> wrote:
> 
>> Denis,
>> 
>> Thanks for quick reply,
>> 
>> I made a change and tested it with your example, everything looks
>> fine.
>> 
>> Pull request is open and available at [1]
>> 
>> [1] https://github.com/apache/ignite/pull/2016
>> 
>> On Fri, May 26, 2017 at 8:25 PM, Denis Magda 
>> wrote:
>> 
 I would suggest on the first iteration to simply ignore persistence
 configuration on client nodes.
 If client node finds persistence configuration on startup it will
>>> printout
 warning message to log and proceed without persistence.
>>> 
>>> +1 for this. Otherwise, it looks like a dirty hack when I need to add
 an
>>> empty MemoryConfiguration to a client config file. Plus, it requires
>> us
>> to
>>> create different configuration files for servers and clients which
>> has
 to
>>> be optional by default.
>>> 
>>> —
>>> Denis
>>> 
 On May 26, 2017, at 9:50 AM, Sergey Chugunov <
>> sergey.chugu...@gmail.com>
>>> wrote:
 
 Moreover, enabling persistence on client node is very risky and may
>> lead
>>> to
 many tricky cases.
 
 I would suggest on the first iteration to simply ignore persistence
 configuration on client nodes.
 If client node finds persistence configuration on startup it will
>>> printout
 warning message to log and proceed without persistence.
 
 Supporting persistence on client nodes definitely requires more
>>> thoughtful
 discussion and may be added in the future.
 
 Thanks,
 Sergey.
 
 On Fri, May 26, 2017 at 7:28 PM, Sergey Chugunov <
>>> sergey.chugu...@gmail.com>
 wrote:
 
> Denis,
> 
> I see from example that you're trying to start a client node with
> persistence configuration specified and you're saying that Ignite
 must
> provide default MemoryConfiguration.
> 
> But that contradicts with decision we all agreed on in the
>>> discussion[1]:
> if user wants to do something unusual on client nodes like storing
>> cache
> partitions (or in this 

Re: Persistent Store example fails with NPE

[Denis Magda]

I tend to use a single XML configuration for all my cluster nodes (servers and 
clients). Presently, I forced to create and maintain at least 2. This is the 
first concern. The second concern is if persistence store has no effect for the 
client node why not simply ignore it and not make the user to set 
MemoryConfiguration explicitly if the goal is to use a single XML config.

—
Denis

> On May 26, 2017, at 11:33 AM, Dmitriy Setrakyan  wrote:
> 
> On Fri, May 26, 2017 at 11:29 AM, Denis Magda  > wrote:
> 
>>> Can we just fix the exception
>>> message to clearly state that client mode requires all explicit
>>> configuration for such and such functionality?
>> 
>> I don’t like this. It will require me as a user:
>> 
>> * have a separate configuration for clients ALL the times.
>> * initialize the memory bean explicitly which looks like a hack and
>> workaround
>> 
>> 
>>   
>>   
>> 
>> 
>> 
> Denis,
> 
> Why would you even have a use case for a persistence configuration on the
> client side? What happened in your case was a mistake and you should have
> received a proper exception. I am simply suggesting that in the odd case
> that someone does need it, we provide proper error message explaining
> exactly what needs to be done. Why not?
> 
> 
>>> On May 26, 2017, at 11:02 AM, Dmitriy Setrakyan 
>> wrote:
>>> 
>>> I don't like ignoring any configuration, but I do agree that enabling
>>> persistence on the client side seems odd. Can we just fix the exception
>>> message to clearly state that client mode requires all explicit
>>> configuration for such and such functionality?
>>> 
>>> D.
>>> 
>>> On Fri, May 26, 2017 at 10:34 AM, Sergey Chugunov <
>> sergey.chugu...@gmail.com
 wrote:
>>> 
 Denis,
 
 Thanks for quick reply,
 
 I made a change and tested it with your example, everything looks fine.
 
 Pull request is open and available at [1]
 
 [1] https://github.com/apache/ignite/pull/2016
 
 On Fri, May 26, 2017 at 8:25 PM, Denis Magda  wrote:
 
>> I would suggest on the first iteration to simply ignore persistence
>> configuration on client nodes.
>> If client node finds persistence configuration on startup it will
> printout
>> warning message to log and proceed without persistence.
> 
> +1 for this. Otherwise, it looks like a dirty hack when I need to add
>> an
> empty MemoryConfiguration to a client config file. Plus, it requires us
 to
> create different configuration files for servers and clients which has
>> to
> be optional by default.
> 
> —
> Denis
> 
>> On May 26, 2017, at 9:50 AM, Sergey Chugunov <
 sergey.chugu...@gmail.com>
> wrote:
>> 
>> Moreover, enabling persistence on client node is very risky and may
 lead
> to
>> many tricky cases.
>> 
>> I would suggest on the first iteration to simply ignore persistence
>> configuration on client nodes.
>> If client node finds persistence configuration on startup it will
> printout
>> warning message to log and proceed without persistence.
>> 
>> Supporting persistence on client nodes definitely requires more
> thoughtful
>> discussion and may be added in the future.
>> 
>> Thanks,
>> Sergey.
>> 
>> On Fri, May 26, 2017 at 7:28 PM, Sergey Chugunov <
> sergey.chugu...@gmail.com>
>> wrote:
>> 
>>> Denis,
>>> 
>>> I see from example that you're trying to start a client node with
>>> persistence configuration specified and you're saying that Ignite
>> must
>>> provide default MemoryConfiguration.
>>> 
>>> But that contradicts with decision we all agreed on in the
> discussion[1]:
>>> if user wants to do something unusual on client nodes like storing
 cache
>>> partitions (or in this case persisting stuff) he/she *must *provide
 all
>>> necessary configuration explicitly.
>>> 
>>> Server node with the same persistence configuration (and without
> explicit
>>> memory configuration) starts just fine.
>>> 
>>> [1] http://apache-ignite-developers.2346864.n4.nabble.
>>> com/Question-local-cache-on-client-nodes-tt15950.html
>>> 
>>> Thanks,
>>> Sergey.
>>> 
>>> On Fri, May 26, 2017 at 7:03 PM, Denis Magda 
 wrote:
>>> 
 Sergey,
 
 The issue vanishes as soon as I add the following to the
 configuration:
 
 
  
  
 
 
 My point is that we just need to create a MemoryConfiguration
> implicitly
 if it’s not defined (no any warnings or extra messages). It’s a
 responsibility of our platform to generate a default configuration
>> if
> it’s
 not set explicitly.
 
 —
 Denis
 

Re: Persistent Store example fails with NPE

[Dmitriy Setrakyan]

On Fri, May 26, 2017 at 11:29 AM, Denis Magda  wrote:

> > Can we just fix the exception
> > message to clearly state that client mode requires all explicit
> > configuration for such and such functionality?
>
> I don’t like this. It will require me as a user:
>
> * have a separate configuration for clients ALL the times.
> * initialize the memory bean explicitly which looks like a hack and
> workaround
>
> 
>
>
> 
>
>
Denis,

Why would you even have a use case for a persistence configuration on the
client side? What happened in your case was a mistake and you should have
received a proper exception. I am simply suggesting that in the odd case
that someone does need it, we provide proper error message explaining
exactly what needs to be done. Why not?


> > On May 26, 2017, at 11:02 AM, Dmitriy Setrakyan 
> wrote:
> >
> > I don't like ignoring any configuration, but I do agree that enabling
> > persistence on the client side seems odd. Can we just fix the exception
> > message to clearly state that client mode requires all explicit
> > configuration for such and such functionality?
> >
> > D.
> >
> > On Fri, May 26, 2017 at 10:34 AM, Sergey Chugunov <
> sergey.chugu...@gmail.com
> >> wrote:
> >
> >> Denis,
> >>
> >> Thanks for quick reply,
> >>
> >> I made a change and tested it with your example, everything looks fine.
> >>
> >> Pull request is open and available at [1]
> >>
> >> [1] https://github.com/apache/ignite/pull/2016
> >>
> >> On Fri, May 26, 2017 at 8:25 PM, Denis Magda  wrote:
> >>
>  I would suggest on the first iteration to simply ignore persistence
>  configuration on client nodes.
>  If client node finds persistence configuration on startup it will
> >>> printout
>  warning message to log and proceed without persistence.
> >>>
> >>> +1 for this. Otherwise, it looks like a dirty hack when I need to add
> an
> >>> empty MemoryConfiguration to a client config file. Plus, it requires us
> >> to
> >>> create different configuration files for servers and clients which has
> to
> >>> be optional by default.
> >>>
> >>> —
> >>> Denis
> >>>
>  On May 26, 2017, at 9:50 AM, Sergey Chugunov <
> >> sergey.chugu...@gmail.com>
> >>> wrote:
> 
>  Moreover, enabling persistence on client node is very risky and may
> >> lead
> >>> to
>  many tricky cases.
> 
>  I would suggest on the first iteration to simply ignore persistence
>  configuration on client nodes.
>  If client node finds persistence configuration on startup it will
> >>> printout
>  warning message to log and proceed without persistence.
> 
>  Supporting persistence on client nodes definitely requires more
> >>> thoughtful
>  discussion and may be added in the future.
> 
>  Thanks,
>  Sergey.
> 
>  On Fri, May 26, 2017 at 7:28 PM, Sergey Chugunov <
> >>> sergey.chugu...@gmail.com>
>  wrote:
> 
> > Denis,
> >
> > I see from example that you're trying to start a client node with
> > persistence configuration specified and you're saying that Ignite
> must
> > provide default MemoryConfiguration.
> >
> > But that contradicts with decision we all agreed on in the
> >>> discussion[1]:
> > if user wants to do something unusual on client nodes like storing
> >> cache
> > partitions (or in this case persisting stuff) he/she *must *provide
> >> all
> > necessary configuration explicitly.
> >
> > Server node with the same persistence configuration (and without
> >>> explicit
> > memory configuration) starts just fine.
> >
> > [1] http://apache-ignite-developers.2346864.n4.nabble.
> > com/Question-local-cache-on-client-nodes-tt15950.html
> >
> > Thanks,
> > Sergey.
> >
> > On Fri, May 26, 2017 at 7:03 PM, Denis Magda 
> >> wrote:
> >
> >> Sergey,
> >>
> >> The issue vanishes as soon as I add the following to the
> >> configuration:
> >>
> >> 
> >>   
> >>   
> >> 
> >>
> >> My point is that we just need to create a MemoryConfiguration
> >>> implicitly
> >> if it’s not defined (no any warnings or extra messages). It’s a
> >> responsibility of our platform to generate a default configuration
> if
> >>> it’s
> >> not set explicitly.
> >>
> >> —
> >> Denis
> >>
> >>> On May 26, 2017, at 8:46 AM, Sergey Chugunov <
> >>> sergey.chugu...@gmail.com>
> >> wrote:
> >>>
> >>> Hi Denis,
> >>>
> >>> What is the expected behavior in that case? Bug doesn't suggest
> any.
> >>>
> >>> From my point of view it would be better to throw an exception on
> >> startup
> >>> with meaningful message than to silently create a default
> >>> MemoryConfiguration under the cover.
> >>>
> >>> Thanks,
> >>> Sergey.
> >>>
> >>> On Fri, May 26, 2017 at 4:00 AM, Denis Magda 
> 

Re: Persistent Store example fails with NPE

[Denis Magda]

> Can we just fix the exception
> message to clearly state that client mode requires all explicit
> configuration for such and such functionality?

I don’t like this. It will require me as a user:

* have a separate configuration for clients ALL the times.
* initialize the memory bean explicitly which looks like a hack and workaround


   
   


—
Denis

> On May 26, 2017, at 11:02 AM, Dmitriy Setrakyan  wrote:
> 
> I don't like ignoring any configuration, but I do agree that enabling
> persistence on the client side seems odd. Can we just fix the exception
> message to clearly state that client mode requires all explicit
> configuration for such and such functionality?
> 
> D.
> 
> On Fri, May 26, 2017 at 10:34 AM, Sergey Chugunov > wrote:
> 
>> Denis,
>> 
>> Thanks for quick reply,
>> 
>> I made a change and tested it with your example, everything looks fine.
>> 
>> Pull request is open and available at [1]
>> 
>> [1] https://github.com/apache/ignite/pull/2016
>> 
>> On Fri, May 26, 2017 at 8:25 PM, Denis Magda  wrote:
>> 
 I would suggest on the first iteration to simply ignore persistence
 configuration on client nodes.
 If client node finds persistence configuration on startup it will
>>> printout
 warning message to log and proceed without persistence.
>>> 
>>> +1 for this. Otherwise, it looks like a dirty hack when I need to add an
>>> empty MemoryConfiguration to a client config file. Plus, it requires us
>> to
>>> create different configuration files for servers and clients which has to
>>> be optional by default.
>>> 
>>> —
>>> Denis
>>> 
 On May 26, 2017, at 9:50 AM, Sergey Chugunov <
>> sergey.chugu...@gmail.com>
>>> wrote:
 
 Moreover, enabling persistence on client node is very risky and may
>> lead
>>> to
 many tricky cases.
 
 I would suggest on the first iteration to simply ignore persistence
 configuration on client nodes.
 If client node finds persistence configuration on startup it will
>>> printout
 warning message to log and proceed without persistence.
 
 Supporting persistence on client nodes definitely requires more
>>> thoughtful
 discussion and may be added in the future.
 
 Thanks,
 Sergey.
 
 On Fri, May 26, 2017 at 7:28 PM, Sergey Chugunov <
>>> sergey.chugu...@gmail.com>
 wrote:
 
> Denis,
> 
> I see from example that you're trying to start a client node with
> persistence configuration specified and you're saying that Ignite must
> provide default MemoryConfiguration.
> 
> But that contradicts with decision we all agreed on in the
>>> discussion[1]:
> if user wants to do something unusual on client nodes like storing
>> cache
> partitions (or in this case persisting stuff) he/she *must *provide
>> all
> necessary configuration explicitly.
> 
> Server node with the same persistence configuration (and without
>>> explicit
> memory configuration) starts just fine.
> 
> [1] http://apache-ignite-developers.2346864.n4.nabble.
> com/Question-local-cache-on-client-nodes-tt15950.html
> 
> Thanks,
> Sergey.
> 
> On Fri, May 26, 2017 at 7:03 PM, Denis Magda 
>> wrote:
> 
>> Sergey,
>> 
>> The issue vanishes as soon as I add the following to the
>> configuration:
>> 
>> 
>>   
>>   
>> 
>> 
>> My point is that we just need to create a MemoryConfiguration
>>> implicitly
>> if it’s not defined (no any warnings or extra messages). It’s a
>> responsibility of our platform to generate a default configuration if
>>> it’s
>> not set explicitly.
>> 
>> —
>> Denis
>> 
>>> On May 26, 2017, at 8:46 AM, Sergey Chugunov <
>>> sergey.chugu...@gmail.com>
>> wrote:
>>> 
>>> Hi Denis,
>>> 
>>> What is the expected behavior in that case? Bug doesn't suggest any.
>>> 
>>> From my point of view it would be better to throw an exception on
>> startup
>>> with meaningful message than to silently create a default
>>> MemoryConfiguration under the cover.
>>> 
>>> Thanks,
>>> Sergey.
>>> 
>>> On Fri, May 26, 2017 at 4:00 AM, Denis Magda 
>>> wrote:
>>> 
 Igniters,
 
 I’ve just added the first Persistent Store example to the branch
>> that
 fosters the donation:
 https://github.com/apache/ignite/tree/ignite-5267/
 examples/src/main/java/org/apache/ignite/examples/persistentstore
 
 However, the example fails with an NPE if a MemoryConfiguration is
>>> not
 defined explicitly:
 https://issues.apache.org/jira/browse/IGNITE-5295
 
 Please those who are involved in the store development fix the
>> issue
>>> by
 the end of tomorrow. I want to complete with the technical
>> documentation
 

Re: Persistent Store example fails with NPE

[Dmitriy Setrakyan]

I don't like ignoring any configuration, but I do agree that enabling
persistence on the client side seems odd. Can we just fix the exception
message to clearly state that client mode requires all explicit
configuration for such and such functionality?

D.

On Fri, May 26, 2017 at 10:34 AM, Sergey Chugunov  wrote:

> Denis,
>
> Thanks for quick reply,
>
> I made a change and tested it with your example, everything looks fine.
>
> Pull request is open and available at [1]
>
> [1] https://github.com/apache/ignite/pull/2016
>
> On Fri, May 26, 2017 at 8:25 PM, Denis Magda  wrote:
>
> > > I would suggest on the first iteration to simply ignore persistence
> > > configuration on client nodes.
> > > If client node finds persistence configuration on startup it will
> > printout
> > > warning message to log and proceed without persistence.
> >
> > +1 for this. Otherwise, it looks like a dirty hack when I need to add an
> > empty MemoryConfiguration to a client config file. Plus, it requires us
> to
> > create different configuration files for servers and clients which has to
> > be optional by default.
> >
> > —
> > Denis
> >
> > > On May 26, 2017, at 9:50 AM, Sergey Chugunov <
> sergey.chugu...@gmail.com>
> > wrote:
> > >
> > > Moreover, enabling persistence on client node is very risky and may
> lead
> > to
> > > many tricky cases.
> > >
> > > I would suggest on the first iteration to simply ignore persistence
> > > configuration on client nodes.
> > > If client node finds persistence configuration on startup it will
> > printout
> > > warning message to log and proceed without persistence.
> > >
> > > Supporting persistence on client nodes definitely requires more
> > thoughtful
> > > discussion and may be added in the future.
> > >
> > > Thanks,
> > > Sergey.
> > >
> > > On Fri, May 26, 2017 at 7:28 PM, Sergey Chugunov <
> > sergey.chugu...@gmail.com>
> > > wrote:
> > >
> > >> Denis,
> > >>
> > >> I see from example that you're trying to start a client node with
> > >> persistence configuration specified and you're saying that Ignite must
> > >> provide default MemoryConfiguration.
> > >>
> > >> But that contradicts with decision we all agreed on in the
> > discussion[1]:
> > >> if user wants to do something unusual on client nodes like storing
> cache
> > >> partitions (or in this case persisting stuff) he/she *must *provide
> all
> > >> necessary configuration explicitly.
> > >>
> > >> Server node with the same persistence configuration (and without
> > explicit
> > >> memory configuration) starts just fine.
> > >>
> > >> [1] http://apache-ignite-developers.2346864.n4.nabble.
> > >> com/Question-local-cache-on-client-nodes-tt15950.html
> > >>
> > >> Thanks,
> > >> Sergey.
> > >>
> > >> On Fri, May 26, 2017 at 7:03 PM, Denis Magda 
> wrote:
> > >>
> > >>> Sergey,
> > >>>
> > >>> The issue vanishes as soon as I add the following to the
> configuration:
> > >>>
> > >>> 
> > >>>
> > >>>
> > >>> 
> > >>>
> > >>> My point is that we just need to create a MemoryConfiguration
> > implicitly
> > >>> if it’s not defined (no any warnings or extra messages). It’s a
> > >>> responsibility of our platform to generate a default configuration if
> > it’s
> > >>> not set explicitly.
> > >>>
> > >>> —
> > >>> Denis
> > >>>
> >  On May 26, 2017, at 8:46 AM, Sergey Chugunov <
> > sergey.chugu...@gmail.com>
> > >>> wrote:
> > 
> >  Hi Denis,
> > 
> >  What is the expected behavior in that case? Bug doesn't suggest any.
> > 
> >  From my point of view it would be better to throw an exception on
> > >>> startup
> >  with meaningful message than to silently create a default
> >  MemoryConfiguration under the cover.
> > 
> >  Thanks,
> >  Sergey.
> > 
> >  On Fri, May 26, 2017 at 4:00 AM, Denis Magda 
> > wrote:
> > 
> > > Igniters,
> > >
> > > I’ve just added the first Persistent Store example to the branch
> that
> > > fosters the donation:
> > > https://github.com/apache/ignite/tree/ignite-5267/
> > > examples/src/main/java/org/apache/ignite/examples/persistentstore
> > >
> > > However, the example fails with an NPE if a MemoryConfiguration is
> > not
> > > defined explicitly:
> > > https://issues.apache.org/jira/browse/IGNITE-5295
> > >
> > > Please those who are involved in the store development fix the
> issue
> > by
> > > the end of tomorrow. I want to complete with the technical
> > >>> documentation
> > > referring to a workable example.
> > >
> > > —
> > > Denis
> > >>>
> > >>>
> > >>
> >
> >
>

Re: Persistent Store example fails with NPE

[Sergey Chugunov]

Denis,

Thanks for quick reply,

I made a change and tested it with your example, everything looks fine.

Pull request is open and available at [1]

[1] https://github.com/apache/ignite/pull/2016

On Fri, May 26, 2017 at 8:25 PM, Denis Magda  wrote:

> > I would suggest on the first iteration to simply ignore persistence
> > configuration on client nodes.
> > If client node finds persistence configuration on startup it will
> printout
> > warning message to log and proceed without persistence.
>
> +1 for this. Otherwise, it looks like a dirty hack when I need to add an
> empty MemoryConfiguration to a client config file. Plus, it requires us to
> create different configuration files for servers and clients which has to
> be optional by default.
>
> —
> Denis
>
> > On May 26, 2017, at 9:50 AM, Sergey Chugunov 
> wrote:
> >
> > Moreover, enabling persistence on client node is very risky and may lead
> to
> > many tricky cases.
> >
> > I would suggest on the first iteration to simply ignore persistence
> > configuration on client nodes.
> > If client node finds persistence configuration on startup it will
> printout
> > warning message to log and proceed without persistence.
> >
> > Supporting persistence on client nodes definitely requires more
> thoughtful
> > discussion and may be added in the future.
> >
> > Thanks,
> > Sergey.
> >
> > On Fri, May 26, 2017 at 7:28 PM, Sergey Chugunov <
> sergey.chugu...@gmail.com>
> > wrote:
> >
> >> Denis,
> >>
> >> I see from example that you're trying to start a client node with
> >> persistence configuration specified and you're saying that Ignite must
> >> provide default MemoryConfiguration.
> >>
> >> But that contradicts with decision we all agreed on in the
> discussion[1]:
> >> if user wants to do something unusual on client nodes like storing cache
> >> partitions (or in this case persisting stuff) he/she *must *provide all
> >> necessary configuration explicitly.
> >>
> >> Server node with the same persistence configuration (and without
> explicit
> >> memory configuration) starts just fine.
> >>
> >> [1] http://apache-ignite-developers.2346864.n4.nabble.
> >> com/Question-local-cache-on-client-nodes-tt15950.html
> >>
> >> Thanks,
> >> Sergey.
> >>
> >> On Fri, May 26, 2017 at 7:03 PM, Denis Magda  wrote:
> >>
> >>> Sergey,
> >>>
> >>> The issue vanishes as soon as I add the following to the configuration:
> >>>
> >>> 
> >>>
> >>>
> >>> 
> >>>
> >>> My point is that we just need to create a MemoryConfiguration
> implicitly
> >>> if it’s not defined (no any warnings or extra messages). It’s a
> >>> responsibility of our platform to generate a default configuration if
> it’s
> >>> not set explicitly.
> >>>
> >>> —
> >>> Denis
> >>>
>  On May 26, 2017, at 8:46 AM, Sergey Chugunov <
> sergey.chugu...@gmail.com>
> >>> wrote:
> 
>  Hi Denis,
> 
>  What is the expected behavior in that case? Bug doesn't suggest any.
> 
>  From my point of view it would be better to throw an exception on
> >>> startup
>  with meaningful message than to silently create a default
>  MemoryConfiguration under the cover.
> 
>  Thanks,
>  Sergey.
> 
>  On Fri, May 26, 2017 at 4:00 AM, Denis Magda 
> wrote:
> 
> > Igniters,
> >
> > I’ve just added the first Persistent Store example to the branch that
> > fosters the donation:
> > https://github.com/apache/ignite/tree/ignite-5267/
> > examples/src/main/java/org/apache/ignite/examples/persistentstore
> >
> > However, the example fails with an NPE if a MemoryConfiguration is
> not
> > defined explicitly:
> > https://issues.apache.org/jira/browse/IGNITE-5295
> >
> > Please those who are involved in the store development fix the issue
> by
> > the end of tomorrow. I want to complete with the technical
> >>> documentation
> > referring to a workable example.
> >
> > —
> > Denis
> >>>
> >>>
> >>
>
>

Re: Persistent Store example fails with NPE

[Denis Magda]

> I would suggest on the first iteration to simply ignore persistence
> configuration on client nodes.
> If client node finds persistence configuration on startup it will printout
> warning message to log and proceed without persistence.

+1 for this. Otherwise, it looks like a dirty hack when I need to add an empty 
MemoryConfiguration to a client config file. Plus, it requires us to create 
different configuration files for servers and clients which has to be optional 
by default.

—
Denis

> On May 26, 2017, at 9:50 AM, Sergey Chugunov  
> wrote:
> 
> Moreover, enabling persistence on client node is very risky and may lead to
> many tricky cases.
> 
> I would suggest on the first iteration to simply ignore persistence
> configuration on client nodes.
> If client node finds persistence configuration on startup it will printout
> warning message to log and proceed without persistence.
> 
> Supporting persistence on client nodes definitely requires more thoughtful
> discussion and may be added in the future.
> 
> Thanks,
> Sergey.
> 
> On Fri, May 26, 2017 at 7:28 PM, Sergey Chugunov 
> wrote:
> 
>> Denis,
>> 
>> I see from example that you're trying to start a client node with
>> persistence configuration specified and you're saying that Ignite must
>> provide default MemoryConfiguration.
>> 
>> But that contradicts with decision we all agreed on in the discussion[1]:
>> if user wants to do something unusual on client nodes like storing cache
>> partitions (or in this case persisting stuff) he/she *must *provide all
>> necessary configuration explicitly.
>> 
>> Server node with the same persistence configuration (and without explicit
>> memory configuration) starts just fine.
>> 
>> [1] http://apache-ignite-developers.2346864.n4.nabble.
>> com/Question-local-cache-on-client-nodes-tt15950.html
>> 
>> Thanks,
>> Sergey.
>> 
>> On Fri, May 26, 2017 at 7:03 PM, Denis Magda  wrote:
>> 
>>> Sergey,
>>> 
>>> The issue vanishes as soon as I add the following to the configuration:
>>> 
>>> 
>>>
>>>
>>> 
>>> 
>>> My point is that we just need to create a MemoryConfiguration implicitly
>>> if it’s not defined (no any warnings or extra messages). It’s a
>>> responsibility of our platform to generate a default configuration if it’s
>>> not set explicitly.
>>> 
>>> —
>>> Denis
>>> 
 On May 26, 2017, at 8:46 AM, Sergey Chugunov 
>>> wrote:
 
 Hi Denis,
 
 What is the expected behavior in that case? Bug doesn't suggest any.
 
 From my point of view it would be better to throw an exception on
>>> startup
 with meaningful message than to silently create a default
 MemoryConfiguration under the cover.
 
 Thanks,
 Sergey.
 
 On Fri, May 26, 2017 at 4:00 AM, Denis Magda  wrote:
 
> Igniters,
> 
> I’ve just added the first Persistent Store example to the branch that
> fosters the donation:
> https://github.com/apache/ignite/tree/ignite-5267/
> examples/src/main/java/org/apache/ignite/examples/persistentstore
> 
> However, the example fails with an NPE if a MemoryConfiguration is not
> defined explicitly:
> https://issues.apache.org/jira/browse/IGNITE-5295
> 
> Please those who are involved in the store development fix the issue by
> the end of tomorrow. I want to complete with the technical
>>> documentation
> referring to a workable example.
> 
> —
> Denis
>>> 
>>> 
>> 

Re: Persistent Store example fails with NPE

[Sergey Chugunov]

Moreover, enabling persistence on client node is very risky and may lead to
many tricky cases.

I would suggest on the first iteration to simply ignore persistence
configuration on client nodes.
If client node finds persistence configuration on startup it will printout
warning message to log and proceed without persistence.

Supporting persistence on client nodes definitely requires more thoughtful
discussion and may be added in the future.

Thanks,
Sergey.

On Fri, May 26, 2017 at 7:28 PM, Sergey Chugunov 
wrote:

> Denis,
>
> I see from example that you're trying to start a client node with
> persistence configuration specified and you're saying that Ignite must
> provide default MemoryConfiguration.
>
> But that contradicts with decision we all agreed on in the discussion[1]:
> if user wants to do something unusual on client nodes like storing cache
> partitions (or in this case persisting stuff) he/she *must *provide all
> necessary configuration explicitly.
>
> Server node with the same persistence configuration (and without explicit
> memory configuration) starts just fine.
>
> [1] http://apache-ignite-developers.2346864.n4.nabble.
> com/Question-local-cache-on-client-nodes-tt15950.html
>
> Thanks,
> Sergey.
>
> On Fri, May 26, 2017 at 7:03 PM, Denis Magda  wrote:
>
>> Sergey,
>>
>> The issue vanishes as soon as I add the following to the configuration:
>>
>> 
>> 
>> 
>> 
>>
>> My point is that we just need to create a MemoryConfiguration implicitly
>> if it’s not defined (no any warnings or extra messages). It’s a
>> responsibility of our platform to generate a default configuration if it’s
>> not set explicitly.
>>
>> —
>> Denis
>>
>> > On May 26, 2017, at 8:46 AM, Sergey Chugunov 
>> wrote:
>> >
>> > Hi Denis,
>> >
>> > What is the expected behavior in that case? Bug doesn't suggest any.
>> >
>> > From my point of view it would be better to throw an exception on
>> startup
>> > with meaningful message than to silently create a default
>> > MemoryConfiguration under the cover.
>> >
>> > Thanks,
>> > Sergey.
>> >
>> > On Fri, May 26, 2017 at 4:00 AM, Denis Magda  wrote:
>> >
>> >> Igniters,
>> >>
>> >> I’ve just added the first Persistent Store example to the branch that
>> >> fosters the donation:
>> >> https://github.com/apache/ignite/tree/ignite-5267/
>> >> examples/src/main/java/org/apache/ignite/examples/persistentstore
>> >>
>> >> However, the example fails with an NPE if a MemoryConfiguration is not
>> >> defined explicitly:
>> >> https://issues.apache.org/jira/browse/IGNITE-5295
>> >>
>> >> Please those who are involved in the store development fix the issue by
>> >> the end of tomorrow. I want to complete with the technical
>> documentation
>> >> referring to a workable example.
>> >>
>> >> —
>> >> Denis
>>
>>
>

Re: Persistent Store example fails with NPE

[Sergey Chugunov]

Denis,

I see from example that you're trying to start a client node with
persistence configuration specified and you're saying that Ignite must
provide default MemoryConfiguration.

But that contradicts with decision we all agreed on in the discussion[1]:
if user wants to do something unusual on client nodes like storing cache
partitions (or in this case persisting stuff) he/she *must *provide all
necessary configuration explicitly.

Server node with the same persistence configuration (and without explicit
memory configuration) starts just fine.

[1]
http://apache-ignite-developers.2346864.n4.nabble.com/Question-local-cache-on-client-nodes-tt15950.html

Thanks,
Sergey.

On Fri, May 26, 2017 at 7:03 PM, Denis Magda  wrote:

> Sergey,
>
> The issue vanishes as soon as I add the following to the configuration:
>
> 
> 
> 
> 
>
> My point is that we just need to create a MemoryConfiguration implicitly
> if it’s not defined (no any warnings or extra messages). It’s a
> responsibility of our platform to generate a default configuration if it’s
> not set explicitly.
>
> —
> Denis
>
> > On May 26, 2017, at 8:46 AM, Sergey Chugunov 
> wrote:
> >
> > Hi Denis,
> >
> > What is the expected behavior in that case? Bug doesn't suggest any.
> >
> > From my point of view it would be better to throw an exception on startup
> > with meaningful message than to silently create a default
> > MemoryConfiguration under the cover.
> >
> > Thanks,
> > Sergey.
> >
> > On Fri, May 26, 2017 at 4:00 AM, Denis Magda  wrote:
> >
> >> Igniters,
> >>
> >> I’ve just added the first Persistent Store example to the branch that
> >> fosters the donation:
> >> https://github.com/apache/ignite/tree/ignite-5267/
> >> examples/src/main/java/org/apache/ignite/examples/persistentstore
> >>
> >> However, the example fails with an NPE if a MemoryConfiguration is not
> >> defined explicitly:
> >> https://issues.apache.org/jira/browse/IGNITE-5295
> >>
> >> Please those who are involved in the store development fix the issue by
> >> the end of tomorrow. I want to complete with the technical documentation
> >> referring to a workable example.
> >>
> >> —
> >> Denis
>
>

Re: Persistent Store example fails with NPE

[Denis Magda]

Sergey,

The issue vanishes as soon as I add the following to the configuration:






My point is that we just need to create a MemoryConfiguration implicitly if 
it’s not defined (no any warnings or extra messages). It’s a responsibility of 
our platform to generate a default configuration if it’s not set explicitly.

—
Denis

> On May 26, 2017, at 8:46 AM, Sergey Chugunov  
> wrote:
> 
> Hi Denis,
> 
> What is the expected behavior in that case? Bug doesn't suggest any.
> 
> From my point of view it would be better to throw an exception on startup
> with meaningful message than to silently create a default
> MemoryConfiguration under the cover.
> 
> Thanks,
> Sergey.
> 
> On Fri, May 26, 2017 at 4:00 AM, Denis Magda  wrote:
> 
>> Igniters,
>> 
>> I’ve just added the first Persistent Store example to the branch that
>> fosters the donation:
>> https://github.com/apache/ignite/tree/ignite-5267/
>> examples/src/main/java/org/apache/ignite/examples/persistentstore
>> 
>> However, the example fails with an NPE if a MemoryConfiguration is not
>> defined explicitly:
>> https://issues.apache.org/jira/browse/IGNITE-5295
>> 
>> Please those who are involved in the store development fix the issue by
>> the end of tomorrow. I want to complete with the technical documentation
>> referring to a workable example.
>> 
>> —
>> Denis

Re: Persistent Store example fails with NPE

[Sergey Chugunov]

Hi Denis,

What is the expected behavior in that case? Bug doesn't suggest any.

>From my point of view it would be better to throw an exception on startup
with meaningful message than to silently create a default
MemoryConfiguration under the cover.

Thanks,
Sergey.

On Fri, May 26, 2017 at 4:00 AM, Denis Magda  wrote:

> Igniters,
>
> I’ve just added the first Persistent Store example to the branch that
> fosters the donation:
> https://github.com/apache/ignite/tree/ignite-5267/
> examples/src/main/java/org/apache/ignite/examples/persistentstore
>
> However, the example fails with an NPE if a MemoryConfiguration is not
> defined explicitly:
> https://issues.apache.org/jira/browse/IGNITE-5295
>
> Please those who are involved in the store development fix the issue by
> the end of tomorrow. I want to complete with the technical documentation
> referring to a workable example.
>
> —
> Denis

Persistent Store example fails with NPE

[Denis Magda]

Igniters,

I’ve just added the first Persistent Store example to the branch that fosters 
the donation:
https://github.com/apache/ignite/tree/ignite-5267/examples/src/main/java/org/apache/ignite/examples/persistentstore

However, the example fails with an NPE if a MemoryConfiguration is not defined 
explicitly:
https://issues.apache.org/jira/browse/IGNITE-5295

Please those who are involved in the store development fix the issue by the end 
of tomorrow. I want to complete with the technical documentation referring to a 
workable example.

—
Denis