Re: Deprecate\remove REBALANCE_OBJECT_LOADED cache event
+1 for removing, but... Is it suitable to remove some API not at major release? On Fri, Aug 2, 2019 at 11:32 AM Maxim Muzafarov wrote: > Igniters, > > I've created a ticket [1]. > > [1] https://issues.apache.org/jira/browse/IGNITE-12035 > > On Thu, 1 Aug 2019 at 10:55, Pavel Kovalenko wrote: > > > > Hello Maxim, > > > > Thank you for researching this. > > It seems those events can be used as an interceptor for the rebalance > > process to make some extra actions after the entry is rebalanced. > > However, I don't see any real usages despite tests. Most likely > > functionality that used such rebalance events no longer exists. > > I see no reasons to have it anymore. > > +1 for removing in 2.8 > > > > > > ср, 31 июл. 2019 г. в 20:54, Maxim Muzafarov : > > > > > Igniters, > > > > > > > > > I've faced with EVT_CACHE_REBALANCE_OBJECT_LOADED [1] and > > > EVT_CACHE_REBALANCE_OBJECT_UNLOADED [2] cache events and not fully > > > understand their general purpose. Hope someone from the community can > > > clarify to me the initial idea of adding these events. > > > > > > The first - it seems to me that these events are completely Ignite > > > internal thing. Why the user should be able to subscribe to such > > > events? (not related to tracking cache keys metrics). Once the data is > > > loaded to cache, I see no reasons to notifying the user about moving > > > cache keys from one node to another if the cluster topology changed. > > > It's up to Ignites mission to keep data consistency in any cases. > > > > > > The second - I haven't found any real usages on GitHub\Google of these > > > events. Most of the examples are related to our community members and > > > Ignites documentation. > > > > > > The third - Correct me if I am wrong, but subscribing for Ignites > > > events can have a strong influence on the cluster performance. So > > > fewer events available to users the better performance will be. > > > > > > > > > I think these events can be easily removed in the next 2.8 release. > > > WDYT? Am I missing something? > > > > > > [1] > > > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/events/EventType.html#EVT_CACHE_REBALANCE_OBJECT_LOADED > > > [2] > > > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/events/EventType.html#EVT_CACHE_REBALANCE_OBJECT_UNLOADED > > > >
Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)
IGNITE-12507 (Persistence files are stored to temp dir) has definitely be added the scope and treated one of the main release drivers. Dmitry, please let us know once the release wiki page is ready so that we can finalize the timelines based on chosen scope. - Denis On Mon, Aug 12, 2019 at 7:12 PM Dmitriy Pavlov wrote: > Hi, > > Thanks to everyone, who participated in the discussion. > > I would like to wait also fix for > https://issues.apache.org/jira/browse/IGNITE-12057 > > and discussion results for that issue: > > https://lists.apache.org/thread.html/498a14b3971950a45ef57f45cc23d2438ce1afba000b586e230927bf@%3Cdev.ignite.apache.org%3E > > > Since some issues are still open, we'll probably move some dates forward, > but it seems we managed to discuss scope before scope freeze. > > I consider now the scope is frozen - no new feature can be added to the > scope of 2.7.6. We're entering the rampdown phase. > > Sincerely, > Dmitriy Pavlov > > See https://cwiki.apache.org/confluence/display/IGNITE/Release+Process for > more details. > > пн, 12 авг. 2019 г. в 16:37, Zhenya Stanilovsky >: > > > Hi al,, i also suggest to append [1], cause it could produce > > CorruptedTreeException in some scenario. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12061 > > > > > > > > > > >Hi all, > > >Can we include https://issues.apache.org/jira/browse/IGNITE-12060 ? > > This is > > >a https://issues.apache.org/jira/browse/IGNITE-11953 > > > > > >On Fri, Aug 9, 2019 at 10:04 AM Nikolay Izhikov < nizhi...@apache.org > > > wrote: > > > > > >> Hello, Deni. > > >> > > >> > Nickolay, could you check if that's a quick upgrade? > > >> > > >> Yes, I will take a look. > > >> > > >> > > >> В Чт, 08/08/2019 в 11:08 -0700, Denis Magda пишет: > > >> > Dmitry, > > >> > > > >> > Please add this BTree corruption fix to the scope: > > >> > https://issues.apache.org/jira/browse/IGNITE-11953 > > >> > > > >> > Plus, I would upgrade our Spark integration to version 2.4 as long > as > > 2.3 > > >> > goes with limitations reported by our users: > > >> > https://issues.apache.org/jira/browse/IGNITE-12054 > > >> > > > >> > Nickolay, could you check if that's a quick upgrade? > > >> > > > >> > - > > >> > Denis > > >> > > > >> > > > >> > On Thu, Aug 8, 2019 at 10:40 AM Dmitriy Pavlov < dpav...@apache.org > > > > >> wrote: > > >> > > > >> > > Hi Ivan, Ilya, Igniters, > > >> > > > > >> > > > > >> > > > > >> > > I would like this release would be as minimal as possible. > > >> > > > > >> > > > > >> > > > > >> > > According to dates proposed we could freeze scope at 12.08, 4 days > > is > > >> more > > >> > > than enough to stand up and say, ‘Hey, I have an urgent fix’. But > > it is > > >> > > also ok for me if we decide to have more relaxed dates. > > >> > > > > >> > > > > >> > > > > >> > > For now, I suppose the following fixed should be cherry-picked: > > >> > > > > >> > > https://issues.apache.org/jira/browse/IGNITE-11767 (Blocker) > > >> > > GridDhtPartitionsFullMessage retains huge maps on heap in exchange > > >> history > > >> > > > > >> > > > > >> > > > > >> > > https://issues.apache.org/jira/browse/IGNITE-10451 (Major Bug) > > .NET: > > >> > > Persistence does not work with custom affinity function > > >> > > > > >> > > > > >> > > > > >> > > https://issues.apache.org/jira/browse/IGNITE-9562 (Critical Bug) > > >> Destroyed > > >> > > cache that resurrected on an old offline node breaks PME > > >> > > > > >> > > > > >> > > > > >> > > But I will continue to research JIRA. > > >> > > > > >> > > > > >> > > > > >> > > Sincerely, > > >> > > > > >> > > Dmitriy Pavlov > > >> > > > > >> > > > > >> > > чт, 8 авг. 2019 г. в 17:30, Павлухин Иван < vololo...@gmail.com > >: > > >> > > > > >> > > > > What's the scope for this release? > > >> > > > > > >> > > > Same question. > > >> > > > > > >> > > > On the other hand an idea of 2.7.6 release attracts me because > > having > > >> > > > a practice of doing frequent minor releases can help us to build > > >> > > > reliable and predictable release rails. > > >> > > > > > >> > > > чт, 8 авг. 2019 г. в 15:09, Ilya Kasnacheev < > > >> ilya.kasnach...@gmail.com >: > > >> > > > > > > >> > > > > Hello! > > >> > > > > > > >> > > > > What's the scope for this release? > > >> > > > > > > >> > > > > Regards, > > >> > > > > -- > > >> > > > > Ilya Kasnacheev > > >> > > > > > > >> > > > > > > >> > > > > чт, 8 авг. 2019 г. в 15:07, Dmitriy Pavlov < > dpav...@apache.org > > >: > > >> > > > > > > >> > > > > > Hi Apache Ignite Developers, > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > We seem to be on the same page about 2.8 release, but we’ve > > >> started > > >> > > > > >> > > new > > >> > > > > > practice - minor releases, the first release was 2.7.5. > > >> > > > > >> > > Unfortunately, > > >> > > > > > there is a couple of issues still not fixed in that release, > > so I > > >> > > > > >> > > would > > >> > > > > > like to propose to prepare one more minor release for Apache >
Re: Replacing default work dir from tmp to current dir
Both ways are right because there is probability that user home isn't
defined in system.
So we should try resolve user dir and fail if it can't be resolved.
On Mon, Aug 12, 2019 at 7:04 PM Ivan Rakov wrote:
>
> Choosing the smallest of two evils, I'll agree with user.dir.
> Being able to run without preset env variables is strong benefit for
> Ignite as a product.
>
> Best Regards,
> Ivan Rakov
>
> On 12.08.2019 19:02, Denis Magda wrote:
> > +1 for the user.dir as a default one.
> >
> > Denis
> >
> > On Monday, August 12, 2019, Dmitriy Pavlov wrote:
> >
> >> +1 to user home directory. A number of open source products create their
> >> dirs there. For me, it is a kind of expected behavior.
> >>
> >> Ivan mentioned an important point: binary meta & marshaller. We should
> >> update documentation and stop require PDS dir setup, but require home setup
> >> (for older versions of Ignite, it is relevant anyway).
> >>
> >> пн, 12 авг. 2019 г. в 18:49, Pavel Tupitsyn :
> >>
> >>> Hi Ivan,
> >>>
> fail Ignite node in case neither IGNITE_HOME
> >>> nor IgniteConfiguration#igniteWorkDir is set
> >>> I strongly disagree, this is bad usability.
> >>> Ignition.start() should work without any extra configuration as is it
> >> right
> >>> now.
> >>>
> >>> Let's come up with reasonable defaults instead, user dir sounds good to
> >> me.
> >>> On Mon, Aug 12, 2019 at 6:45 PM Stephen Darlington <
> >>> stephen.darling...@gridgain.com> wrote:
> >>>
> Yes, when data is a stake, fail early is the absolutely the right thing
> >>> to
> do.
>
> Regards,
> Stephen
>
> > On 12 Aug 2019, at 16:37, Ivan Rakov wrote:
> >
> > Hi Anton,
> >
> > Actually, the issue is even more unpleasant.
> >
> > Official Ignite documentation says that it's possible to configure
> >> path
> where your persistence files will be stored:
> https://apacheignite.readme.io/docs/distributed-persistent-store
> > However, even if you have set all path options (storage, WAL, WAL
> archive), Ignite will still store crucial metadata in resolved work
> directory (java.io.tmpdir by default). Example is binary metadata
> >> files,
> absence of which can make your data unavailable.
> > I propose to fail Ignite node in case neither IGNITE_HOME nor
> IgniteConfiguration#igniteWorkDir is set. It's better to let user know
> about missing configuration options during startup than let OS corrupt
> storage by cleaning temp dirs.
> > Thoughts?
> >
> > Best Regards,
> > Ivan Rakov
> >
> > On 12.08.2019 18:10, Anton Kalashnikov wrote:
> >> Hello, Igniters.
> >>
> >> Currently, in the case, when work directory wasn't set by user
> >> ignite
> can resolve it to tmp directory which leads to some problem - tmp
> >>> directory
> can be cleared at some unexpected moment by operation system and
> >>> different
> types of critical data would be lost(ex. binary_meta, persistance
> >> data).
> >> Looks like it is not expected behaviour and maybe it is better
> >> instead
> of tmp directory use the current working directory("user.dir")? Or any
> other idea?
> >> A little more details you can find in the ticket -
> https://issues.apache.org/jira/browse/IGNITE-12057
> >> --
> >> Best regards,
> >> Anton Kalashnikov
> >>
>
>
> >
Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)
Hi, Thanks to everyone, who participated in the discussion. I would like to wait also fix for https://issues.apache.org/jira/browse/IGNITE-12057 and discussion results for that issue: https://lists.apache.org/thread.html/498a14b3971950a45ef57f45cc23d2438ce1afba000b586e230927bf@%3Cdev.ignite.apache.org%3E Since some issues are still open, we'll probably move some dates forward, but it seems we managed to discuss scope before scope freeze. I consider now the scope is frozen - no new feature can be added to the scope of 2.7.6. We're entering the rampdown phase. Sincerely, Dmitriy Pavlov See https://cwiki.apache.org/confluence/display/IGNITE/Release+Process for more details. пн, 12 авг. 2019 г. в 16:37, Zhenya Stanilovsky : > Hi al,, i also suggest to append [1], cause it could produce > CorruptedTreeException in some scenario. > > > [1] https://issues.apache.org/jira/browse/IGNITE-12061 > > > > > > >Hi all, > >Can we include https://issues.apache.org/jira/browse/IGNITE-12060 ? > This is > >a https://issues.apache.org/jira/browse/IGNITE-11953 > > > >On Fri, Aug 9, 2019 at 10:04 AM Nikolay Izhikov < nizhi...@apache.org > > wrote: > > > >> Hello, Deni. > >> > >> > Nickolay, could you check if that's a quick upgrade? > >> > >> Yes, I will take a look. > >> > >> > >> В Чт, 08/08/2019 в 11:08 -0700, Denis Magda пишет: > >> > Dmitry, > >> > > >> > Please add this BTree corruption fix to the scope: > >> > https://issues.apache.org/jira/browse/IGNITE-11953 > >> > > >> > Plus, I would upgrade our Spark integration to version 2.4 as long as > 2.3 > >> > goes with limitations reported by our users: > >> > https://issues.apache.org/jira/browse/IGNITE-12054 > >> > > >> > Nickolay, could you check if that's a quick upgrade? > >> > > >> > - > >> > Denis > >> > > >> > > >> > On Thu, Aug 8, 2019 at 10:40 AM Dmitriy Pavlov < dpav...@apache.org > > >> wrote: > >> > > >> > > Hi Ivan, Ilya, Igniters, > >> > > > >> > > > >> > > > >> > > I would like this release would be as minimal as possible. > >> > > > >> > > > >> > > > >> > > According to dates proposed we could freeze scope at 12.08, 4 days > is > >> more > >> > > than enough to stand up and say, ‘Hey, I have an urgent fix’. But > it is > >> > > also ok for me if we decide to have more relaxed dates. > >> > > > >> > > > >> > > > >> > > For now, I suppose the following fixed should be cherry-picked: > >> > > > >> > > https://issues.apache.org/jira/browse/IGNITE-11767 (Blocker) > >> > > GridDhtPartitionsFullMessage retains huge maps on heap in exchange > >> history > >> > > > >> > > > >> > > > >> > > https://issues.apache.org/jira/browse/IGNITE-10451 (Major Bug) > .NET: > >> > > Persistence does not work with custom affinity function > >> > > > >> > > > >> > > > >> > > https://issues.apache.org/jira/browse/IGNITE-9562 (Critical Bug) > >> Destroyed > >> > > cache that resurrected on an old offline node breaks PME > >> > > > >> > > > >> > > > >> > > But I will continue to research JIRA. > >> > > > >> > > > >> > > > >> > > Sincerely, > >> > > > >> > > Dmitriy Pavlov > >> > > > >> > > > >> > > чт, 8 авг. 2019 г. в 17:30, Павлухин Иван < vololo...@gmail.com >: > >> > > > >> > > > > What's the scope for this release? > >> > > > > >> > > > Same question. > >> > > > > >> > > > On the other hand an idea of 2.7.6 release attracts me because > having > >> > > > a practice of doing frequent minor releases can help us to build > >> > > > reliable and predictable release rails. > >> > > > > >> > > > чт, 8 авг. 2019 г. в 15:09, Ilya Kasnacheev < > >> ilya.kasnach...@gmail.com >: > >> > > > > > >> > > > > Hello! > >> > > > > > >> > > > > What's the scope for this release? > >> > > > > > >> > > > > Regards, > >> > > > > -- > >> > > > > Ilya Kasnacheev > >> > > > > > >> > > > > > >> > > > > чт, 8 авг. 2019 г. в 15:07, Dmitriy Pavlov < dpav...@apache.org > >: > >> > > > > > >> > > > > > Hi Apache Ignite Developers, > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > We seem to be on the same page about 2.8 release, but we’ve > >> started > >> > > > >> > > new > >> > > > > > practice - minor releases, the first release was 2.7.5. > >> > > > >> > > Unfortunately, > >> > > > > > there is a couple of issues still not fixed in that release, > so I > >> > > > >> > > would > >> > > > > > like to propose to prepare one more minor release for Apache > >> Ignite. > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > I propose my candidacy to be release manager once again. > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > I could (of course with help from Peter Ivanov) do some > >> additional > >> > > > > >> > > > efforts > >> > > > > > to complete and improve process doc > >> > > > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > I propose (most optimistic) dates for release stages: > >> > > > > > > >> > > > > > Scope Freeze: August 12, 2019 > >> > > > > > > >> > > > > > Code
Re: Replacing default work dir from tmp to current dir
Choosing the smallest of two evils, I'll agree with user.dir.
Being able to run without preset env variables is strong benefit for
Ignite as a product.
Best Regards,
Ivan Rakov
On 12.08.2019 19:02, Denis Magda wrote:
+1 for the user.dir as a default one.
Denis
On Monday, August 12, 2019, Dmitriy Pavlov wrote:
+1 to user home directory. A number of open source products create their
dirs there. For me, it is a kind of expected behavior.
Ivan mentioned an important point: binary meta & marshaller. We should
update documentation and stop require PDS dir setup, but require home setup
(for older versions of Ignite, it is relevant anyway).
пн, 12 авг. 2019 г. в 18:49, Pavel Tupitsyn :
Hi Ivan,
fail Ignite node in case neither IGNITE_HOME
nor IgniteConfiguration#igniteWorkDir is set
I strongly disagree, this is bad usability.
Ignition.start() should work without any extra configuration as is it
right
now.
Let's come up with reasonable defaults instead, user dir sounds good to
me.
On Mon, Aug 12, 2019 at 6:45 PM Stephen Darlington <
stephen.darling...@gridgain.com> wrote:
Yes, when data is a stake, fail early is the absolutely the right thing
to
do.
Regards,
Stephen
On 12 Aug 2019, at 16:37, Ivan Rakov wrote:
Hi Anton,
Actually, the issue is even more unpleasant.
Official Ignite documentation says that it's possible to configure
path
where your persistence files will be stored:
https://apacheignite.readme.io/docs/distributed-persistent-store
However, even if you have set all path options (storage, WAL, WAL
archive), Ignite will still store crucial metadata in resolved work
directory (java.io.tmpdir by default). Example is binary metadata
files,
absence of which can make your data unavailable.
I propose to fail Ignite node in case neither IGNITE_HOME nor
IgniteConfiguration#igniteWorkDir is set. It's better to let user know
about missing configuration options during startup than let OS corrupt
storage by cleaning temp dirs.
Thoughts?
Best Regards,
Ivan Rakov
On 12.08.2019 18:10, Anton Kalashnikov wrote:
Hello, Igniters.
Currently, in the case, when work directory wasn't set by user
ignite
can resolve it to tmp directory which leads to some problem - tmp
directory
can be cleared at some unexpected moment by operation system and
different
types of critical data would be lost(ex. binary_meta, persistance
data).
Looks like it is not expected behaviour and maybe it is better
instead
of tmp directory use the current working directory("user.dir")? Or any
other idea?
A little more details you can find in the ticket -
https://issues.apache.org/jira/browse/IGNITE-12057
--
Best regards,
Anton Kalashnikov
Re: Replacing default work dir from tmp to current dir
+1 for the user.dir as a default one.
Denis
On Monday, August 12, 2019, Dmitriy Pavlov wrote:
> +1 to user home directory. A number of open source products create their
> dirs there. For me, it is a kind of expected behavior.
>
> Ivan mentioned an important point: binary meta & marshaller. We should
> update documentation and stop require PDS dir setup, but require home setup
> (for older versions of Ignite, it is relevant anyway).
>
> пн, 12 авг. 2019 г. в 18:49, Pavel Tupitsyn :
>
> > Hi Ivan,
> >
> > > fail Ignite node in case neither IGNITE_HOME
> > nor IgniteConfiguration#igniteWorkDir is set
> > I strongly disagree, this is bad usability.
> > Ignition.start() should work without any extra configuration as is it
> right
> > now.
> >
> > Let's come up with reasonable defaults instead, user dir sounds good to
> me.
> >
> > On Mon, Aug 12, 2019 at 6:45 PM Stephen Darlington <
> > stephen.darling...@gridgain.com> wrote:
> >
> > > Yes, when data is a stake, fail early is the absolutely the right thing
> > to
> > > do.
> > >
> > > Regards,
> > > Stephen
> > >
> > > > On 12 Aug 2019, at 16:37, Ivan Rakov wrote:
> > > >
> > > > Hi Anton,
> > > >
> > > > Actually, the issue is even more unpleasant.
> > > >
> > > > Official Ignite documentation says that it's possible to configure
> path
> > > where your persistence files will be stored:
> > > https://apacheignite.readme.io/docs/distributed-persistent-store
> > > > However, even if you have set all path options (storage, WAL, WAL
> > > archive), Ignite will still store crucial metadata in resolved work
> > > directory (java.io.tmpdir by default). Example is binary metadata
> files,
> > > absence of which can make your data unavailable.
> > > >
> > > > I propose to fail Ignite node in case neither IGNITE_HOME nor
> > > IgniteConfiguration#igniteWorkDir is set. It's better to let user know
> > > about missing configuration options during startup than let OS corrupt
> > > storage by cleaning temp dirs.
> > > >
> > > > Thoughts?
> > > >
> > > > Best Regards,
> > > > Ivan Rakov
> > > >
> > > > On 12.08.2019 18:10, Anton Kalashnikov wrote:
> > > >> Hello, Igniters.
> > > >>
> > > >> Currently, in the case, when work directory wasn't set by user
> ignite
> > > can resolve it to tmp directory which leads to some problem - tmp
> > directory
> > > can be cleared at some unexpected moment by operation system and
> > different
> > > types of critical data would be lost(ex. binary_meta, persistance
> data).
> > > >>
> > > >> Looks like it is not expected behaviour and maybe it is better
> instead
> > > of tmp directory use the current working directory("user.dir")? Or any
> > > other idea?
> > > >>
> > > >> A little more details you can find in the ticket -
> > > https://issues.apache.org/jira/browse/IGNITE-12057
> > > >> --
> > > >> Best regards,
> > > >> Anton Kalashnikov
> > > >>
> > >
> > >
> > >
> >
>
--
-
Denis
Re: Replacing default work dir from tmp to current dir
+1 to user home directory. A number of open source products create their
dirs there. For me, it is a kind of expected behavior.
Ivan mentioned an important point: binary meta & marshaller. We should
update documentation and stop require PDS dir setup, but require home setup
(for older versions of Ignite, it is relevant anyway).
пн, 12 авг. 2019 г. в 18:49, Pavel Tupitsyn :
> Hi Ivan,
>
> > fail Ignite node in case neither IGNITE_HOME
> nor IgniteConfiguration#igniteWorkDir is set
> I strongly disagree, this is bad usability.
> Ignition.start() should work without any extra configuration as is it right
> now.
>
> Let's come up with reasonable defaults instead, user dir sounds good to me.
>
> On Mon, Aug 12, 2019 at 6:45 PM Stephen Darlington <
> stephen.darling...@gridgain.com> wrote:
>
> > Yes, when data is a stake, fail early is the absolutely the right thing
> to
> > do.
> >
> > Regards,
> > Stephen
> >
> > > On 12 Aug 2019, at 16:37, Ivan Rakov wrote:
> > >
> > > Hi Anton,
> > >
> > > Actually, the issue is even more unpleasant.
> > >
> > > Official Ignite documentation says that it's possible to configure path
> > where your persistence files will be stored:
> > https://apacheignite.readme.io/docs/distributed-persistent-store
> > > However, even if you have set all path options (storage, WAL, WAL
> > archive), Ignite will still store crucial metadata in resolved work
> > directory (java.io.tmpdir by default). Example is binary metadata files,
> > absence of which can make your data unavailable.
> > >
> > > I propose to fail Ignite node in case neither IGNITE_HOME nor
> > IgniteConfiguration#igniteWorkDir is set. It's better to let user know
> > about missing configuration options during startup than let OS corrupt
> > storage by cleaning temp dirs.
> > >
> > > Thoughts?
> > >
> > > Best Regards,
> > > Ivan Rakov
> > >
> > > On 12.08.2019 18:10, Anton Kalashnikov wrote:
> > >> Hello, Igniters.
> > >>
> > >> Currently, in the case, when work directory wasn't set by user ignite
> > can resolve it to tmp directory which leads to some problem - tmp
> directory
> > can be cleared at some unexpected moment by operation system and
> different
> > types of critical data would be lost(ex. binary_meta, persistance data).
> > >>
> > >> Looks like it is not expected behaviour and maybe it is better instead
> > of tmp directory use the current working directory("user.dir")? Or any
> > other idea?
> > >>
> > >> A little more details you can find in the ticket -
> > https://issues.apache.org/jira/browse/IGNITE-12057
> > >> --
> > >> Best regards,
> > >> Anton Kalashnikov
> > >>
> >
> >
> >
>
Re: Replacing default work dir from tmp to current dir
Hi Ivan,
> fail Ignite node in case neither IGNITE_HOME
nor IgniteConfiguration#igniteWorkDir is set
I strongly disagree, this is bad usability.
Ignition.start() should work without any extra configuration as is it right
now.
Let's come up with reasonable defaults instead, user dir sounds good to me.
On Mon, Aug 12, 2019 at 6:45 PM Stephen Darlington <
stephen.darling...@gridgain.com> wrote:
> Yes, when data is a stake, fail early is the absolutely the right thing to
> do.
>
> Regards,
> Stephen
>
> > On 12 Aug 2019, at 16:37, Ivan Rakov wrote:
> >
> > Hi Anton,
> >
> > Actually, the issue is even more unpleasant.
> >
> > Official Ignite documentation says that it's possible to configure path
> where your persistence files will be stored:
> https://apacheignite.readme.io/docs/distributed-persistent-store
> > However, even if you have set all path options (storage, WAL, WAL
> archive), Ignite will still store crucial metadata in resolved work
> directory (java.io.tmpdir by default). Example is binary metadata files,
> absence of which can make your data unavailable.
> >
> > I propose to fail Ignite node in case neither IGNITE_HOME nor
> IgniteConfiguration#igniteWorkDir is set. It's better to let user know
> about missing configuration options during startup than let OS corrupt
> storage by cleaning temp dirs.
> >
> > Thoughts?
> >
> > Best Regards,
> > Ivan Rakov
> >
> > On 12.08.2019 18:10, Anton Kalashnikov wrote:
> >> Hello, Igniters.
> >>
> >> Currently, in the case, when work directory wasn't set by user ignite
> can resolve it to tmp directory which leads to some problem - tmp directory
> can be cleared at some unexpected moment by operation system and different
> types of critical data would be lost(ex. binary_meta, persistance data).
> >>
> >> Looks like it is not expected behaviour and maybe it is better instead
> of tmp directory use the current working directory("user.dir")? Or any
> other idea?
> >>
> >> A little more details you can find in the ticket -
> https://issues.apache.org/jira/browse/IGNITE-12057
> >> --
> >> Best regards,
> >> Anton Kalashnikov
> >>
>
>
>
Re: Replacing default work dir from tmp to current dir
Yes, when data is a stake, fail early is the absolutely the right thing to do.
Regards,
Stephen
> On 12 Aug 2019, at 16:37, Ivan Rakov wrote:
>
> Hi Anton,
>
> Actually, the issue is even more unpleasant.
>
> Official Ignite documentation says that it's possible to configure path where
> your persistence files will be stored:
> https://apacheignite.readme.io/docs/distributed-persistent-store
> However, even if you have set all path options (storage, WAL, WAL archive),
> Ignite will still store crucial metadata in resolved work directory
> (java.io.tmpdir by default). Example is binary metadata files, absence of
> which can make your data unavailable.
>
> I propose to fail Ignite node in case neither IGNITE_HOME nor
> IgniteConfiguration#igniteWorkDir is set. It's better to let user know about
> missing configuration options during startup than let OS corrupt storage by
> cleaning temp dirs.
>
> Thoughts?
>
> Best Regards,
> Ivan Rakov
>
> On 12.08.2019 18:10, Anton Kalashnikov wrote:
>> Hello, Igniters.
>>
>> Currently, in the case, when work directory wasn't set by user ignite can
>> resolve it to tmp directory which leads to some problem - tmp directory can
>> be cleared at some unexpected moment by operation system and different types
>> of critical data would be lost(ex. binary_meta, persistance data).
>>
>> Looks like it is not expected behaviour and maybe it is better instead of
>> tmp directory use the current working directory("user.dir")? Or any other
>> idea?
>>
>> A little more details you can find in the ticket -
>> https://issues.apache.org/jira/browse/IGNITE-12057
>> --
>> Best regards,
>> Anton Kalashnikov
>>
Re: Replacing default work dir from tmp to current dir
Hi Anton,
Actually, the issue is even more unpleasant.
Official Ignite documentation says that it's possible to configure path
where your persistence files will be stored:
https://apacheignite.readme.io/docs/distributed-persistent-store
However, even if you have set all path options (storage, WAL, WAL
archive), Ignite will still store crucial metadata in resolved work
directory (java.io.tmpdir by default). Example is binary metadata files,
absence of which can make your data unavailable.
I propose to fail Ignite node in case neither IGNITE_HOME nor
IgniteConfiguration#igniteWorkDir is set. It's better to let user know
about missing configuration options during startup than let OS corrupt
storage by cleaning temp dirs.
Thoughts?
Best Regards,
Ivan Rakov
On 12.08.2019 18:10, Anton Kalashnikov wrote:
Hello, Igniters.
Currently, in the case, when work directory wasn't set by user ignite can
resolve it to tmp directory which leads to some problem - tmp directory can be
cleared at some unexpected moment by operation system and different types of
critical data would be lost(ex. binary_meta, persistance data).
Looks like it is not expected behaviour and maybe it is better instead of tmp directory
use the current working directory("user.dir")? Or any other idea?
A little more details you can find in the ticket -
https://issues.apache.org/jira/browse/IGNITE-12057
--
Best regards,
Anton Kalashnikov
Replacing default work dir from tmp to current dir
Hello, Igniters.
Currently, in the case, when work directory wasn't set by user ignite can
resolve it to tmp directory which leads to some problem - tmp directory can be
cleared at some unexpected moment by operation system and different types of
critical data would be lost(ex. binary_meta, persistance data).
Looks like it is not expected behaviour and maybe it is better instead of tmp
directory use the current working directory("user.dir")? Or any other idea?
A little more details you can find in the ticket -
https://issues.apache.org/jira/browse/IGNITE-12057
--
Best regards,
Anton Kalashnikov
Re: Issue with the TC disk space
Made some cleaning. Later will upgrade disks (currently we're using really old and small ones). > On 12 Aug 2019, at 11:42, Павлухин Иван wrote: > > Folks, > > I asked about TC infrastructure problems before and did not get > answers. Does any of you know how to fix problems of that sort? Should > not the process be transparent for a community members? > > пн, 12 авг. 2019 г. в 11:00, Dmitriy Pavlov : >> >> I also see some issues with 2.7.6 testing. Hopefully, it would be fixed >> soon since it is a blocker for any activity for 2.7.6 >> >> пн, 12 авг. 2019 г. в 10:58, Nikolay Izhikov : >> >>> Hello, Igniters. >>> >>> Looks like TC has the issues with the free disk space [1] >>> >>> Can someone take a look? >>> >>> >>> ``` >>> [19:13:00]Free disk space requirement >>> [19:13:00][Free disk space requirement] Removing files to meet 3 GB of >>> free disk space required for directory /opt/buildagent/temp (only 122.05 MB >>> is free now). >>> [19:13:00][Free disk space requirement] Free disk space requirement of 3 >>> GB is met for directory /opt/buildagent/work/69588afcb2ab3382 (106.14 GB is >>> free) >>> [19:13:00][Free disk space requirement] Free disk space requirement of 3 >>> GB could not be met for directory /opt/buildagent/temp (only 123.32 MB is >>> free) >>> [19:13:00]Resolving artifact dependencies (4s) >>> [19:13:01][Resolving artifact dependencies] Destination directory >>> [/opt/buildagent/work/69588afcb2ab3382] cleaned >>> [19:13:01][Resolving artifact dependencies] Downloading files from >> Tests 2.4+ (Java 8/9/10/11) / ~Build Apache Ignite~, build #1084597 [id >>> 4482201]> for pattern [ignite.zip!** => ./] >>> [19:13:01][Resolving artifact dependencies] Downloading 1 artifact >>> [19:13:04][Resolving artifact dependencies] Failed to resolve artifact >>> dependency >> build #1084597 [id 4482201]>: Failed to download file >>> 'ignite.zip': No space left on device >>> (jetbrains.buildServer.artifacts.impl.SourcePathAwareResolvingFailedException) >>> [19:13:04]Failed to resolve artifacts from >> 8/9/10/11) / ~Build Apache Ignite~, build #1084597 [id 4482201]> >>> ``` >>> >>> [1] >>> https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=4483694&_focus=60 >>> > > > > -- > Best regards, > Ivan Pavlukhin
Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)
Hi al,, i also suggest to append [1], cause it could produce CorruptedTreeException in some scenario. [1] https://issues.apache.org/jira/browse/IGNITE-12061 > > >Hi all, >Can we include https://issues.apache.org/jira/browse/IGNITE-12060 ? This is >a https://issues.apache.org/jira/browse/IGNITE-11953 > >On Fri, Aug 9, 2019 at 10:04 AM Nikolay Izhikov < nizhi...@apache.org > wrote: > >> Hello, Deni. >> >> > Nickolay, could you check if that's a quick upgrade? >> >> Yes, I will take a look. >> >> >> В Чт, 08/08/2019 в 11:08 -0700, Denis Magda пишет: >> > Dmitry, >> > >> > Please add this BTree corruption fix to the scope: >> > https://issues.apache.org/jira/browse/IGNITE-11953 >> > >> > Plus, I would upgrade our Spark integration to version 2.4 as long as 2.3 >> > goes with limitations reported by our users: >> > https://issues.apache.org/jira/browse/IGNITE-12054 >> > >> > Nickolay, could you check if that's a quick upgrade? >> > >> > - >> > Denis >> > >> > >> > On Thu, Aug 8, 2019 at 10:40 AM Dmitriy Pavlov < dpav...@apache.org > >> wrote: >> > >> > > Hi Ivan, Ilya, Igniters, >> > > >> > > >> > > >> > > I would like this release would be as minimal as possible. >> > > >> > > >> > > >> > > According to dates proposed we could freeze scope at 12.08, 4 days is >> more >> > > than enough to stand up and say, ‘Hey, I have an urgent fix’. But it is >> > > also ok for me if we decide to have more relaxed dates. >> > > >> > > >> > > >> > > For now, I suppose the following fixed should be cherry-picked: >> > > >> > > https://issues.apache.org/jira/browse/IGNITE-11767 (Blocker) >> > > GridDhtPartitionsFullMessage retains huge maps on heap in exchange >> history >> > > >> > > >> > > >> > > https://issues.apache.org/jira/browse/IGNITE-10451 (Major Bug) .NET: >> > > Persistence does not work with custom affinity function >> > > >> > > >> > > >> > > https://issues.apache.org/jira/browse/IGNITE-9562 (Critical Bug) >> Destroyed >> > > cache that resurrected on an old offline node breaks PME >> > > >> > > >> > > >> > > But I will continue to research JIRA. >> > > >> > > >> > > >> > > Sincerely, >> > > >> > > Dmitriy Pavlov >> > > >> > > >> > > чт, 8 авг. 2019 г. в 17:30, Павлухин Иван < vololo...@gmail.com >: >> > > >> > > > > What's the scope for this release? >> > > > >> > > > Same question. >> > > > >> > > > On the other hand an idea of 2.7.6 release attracts me because having >> > > > a practice of doing frequent minor releases can help us to build >> > > > reliable and predictable release rails. >> > > > >> > > > чт, 8 авг. 2019 г. в 15:09, Ilya Kasnacheev < >> ilya.kasnach...@gmail.com >: >> > > > > >> > > > > Hello! >> > > > > >> > > > > What's the scope for this release? >> > > > > >> > > > > Regards, >> > > > > -- >> > > > > Ilya Kasnacheev >> > > > > >> > > > > >> > > > > чт, 8 авг. 2019 г. в 15:07, Dmitriy Pavlov < dpav...@apache.org >: >> > > > > >> > > > > > Hi Apache Ignite Developers, >> > > > > > >> > > > > > >> > > > > > >> > > > > > We seem to be on the same page about 2.8 release, but we’ve >> started >> > > >> > > new >> > > > > > practice - minor releases, the first release was 2.7.5. >> > > >> > > Unfortunately, >> > > > > > there is a couple of issues still not fixed in that release, so I >> > > >> > > would >> > > > > > like to propose to prepare one more minor release for Apache >> Ignite. >> > > > > > >> > > > > > >> > > > > > >> > > > > > I propose my candidacy to be release manager once again. >> > > > > > >> > > > > > >> > > > > > >> > > > > > I could (of course with help from Peter Ivanov) do some >> additional >> > > > >> > > > efforts >> > > > > > to complete and improve process doc >> > > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process >> > > > > > >> > > > > > >> > > > > > >> > > > > > I propose (most optimistic) dates for release stages: >> > > > > > >> > > > > > Scope Freeze: August 12, 2019 >> > > > > > >> > > > > > Code Freeze: August 15, 2019 >> > > > > > >> > > > > > Voting Date: August 22, 2019 >> > > > > > >> > > > > > Release Date: August 27, 2019 >> > > > > > >> > > > > > >> > > > > > WDYT? >> > > > > > >> > > > > > >> > > > > > If nobody minds, I will create branch 2.7.6 based on 2.7.5 and >> set up >> > > > >> > > > in >> > > > > > the TC Bot during the weekend. >> > > > > > >> > > > > > >> > > > > > >> > > > > > Sincerely, >> > > > > > >> > > > > > Dmitriy Pavlov >> > > > > > >> > > > >> > > > >> > > > >> > > > -- >> > > > Best regards, >> > > > Ivan Pavlukhin >> > > > >> -- Zhenya Stanilovsky
[jira] [Created] (IGNITE-12061) Silently fail while try to recreate already existing index with differ inline_size.
Stanilovsky Evgeny created IGNITE-12061: --- Summary: Silently fail while try to recreate already existing index with differ inline_size. Key: IGNITE-12061 URL: https://issues.apache.org/jira/browse/IGNITE-12061 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.7.5, 2.7, 2.5 Reporter: Stanilovsky Evgeny Assignee: Stanilovsky Evgeny INLINE_SIZE differ from previous value is not correctly sets. 1. create index idx0(c1, c2) 2. drop idx0 3. create index idx0(c1, c2) inline_size 100; inline_size remains the same, in this case default = 10. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
Re: Apache Ignite 2.7.6 (Time, Scope, and Release manager)
Hi all, Can we include https://issues.apache.org/jira/browse/IGNITE-12060? This is a https://issues.apache.org/jira/browse/IGNITE-11953 On Fri, Aug 9, 2019 at 10:04 AM Nikolay Izhikov wrote: > Hello, Deni. > > > Nickolay, could you check if that's a quick upgrade? > > Yes, I will take a look. > > > В Чт, 08/08/2019 в 11:08 -0700, Denis Magda пишет: > > Dmitry, > > > > Please add this BTree corruption fix to the scope: > > https://issues.apache.org/jira/browse/IGNITE-11953 > > > > Plus, I would upgrade our Spark integration to version 2.4 as long as 2.3 > > goes with limitations reported by our users: > > https://issues.apache.org/jira/browse/IGNITE-12054 > > > > Nickolay, could you check if that's a quick upgrade? > > > > - > > Denis > > > > > > On Thu, Aug 8, 2019 at 10:40 AM Dmitriy Pavlov > wrote: > > > > > Hi Ivan, Ilya, Igniters, > > > > > > > > > > > > I would like this release would be as minimal as possible. > > > > > > > > > > > > According to dates proposed we could freeze scope at 12.08, 4 days is > more > > > than enough to stand up and say, ‘Hey, I have an urgent fix’. But it is > > > also ok for me if we decide to have more relaxed dates. > > > > > > > > > > > > For now, I suppose the following fixed should be cherry-picked: > > > > > > https://issues.apache.org/jira/browse/IGNITE-11767 (Blocker) > > > GridDhtPartitionsFullMessage retains huge maps on heap in exchange > history > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-10451 (Major Bug) .NET: > > > Persistence does not work with custom affinity function > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-9562 (Critical Bug) > Destroyed > > > cache that resurrected on an old offline node breaks PME > > > > > > > > > > > > But I will continue to research JIRA. > > > > > > > > > > > > Sincerely, > > > > > > Dmitriy Pavlov > > > > > > > > > чт, 8 авг. 2019 г. в 17:30, Павлухин Иван : > > > > > > > > What's the scope for this release? > > > > > > > > Same question. > > > > > > > > On the other hand an idea of 2.7.6 release attracts me because having > > > > a practice of doing frequent minor releases can help us to build > > > > reliable and predictable release rails. > > > > > > > > чт, 8 авг. 2019 г. в 15:09, Ilya Kasnacheev < > ilya.kasnach...@gmail.com>: > > > > > > > > > > Hello! > > > > > > > > > > What's the scope for this release? > > > > > > > > > > Regards, > > > > > -- > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > чт, 8 авг. 2019 г. в 15:07, Dmitriy Pavlov : > > > > > > > > > > > Hi Apache Ignite Developers, > > > > > > > > > > > > > > > > > > > > > > > > We seem to be on the same page about 2.8 release, but we’ve > started > > > > > > new > > > > > > practice - minor releases, the first release was 2.7.5. > > > > > > Unfortunately, > > > > > > there is a couple of issues still not fixed in that release, so I > > > > > > would > > > > > > like to propose to prepare one more minor release for Apache > Ignite. > > > > > > > > > > > > > > > > > > > > > > > > I propose my candidacy to be release manager once again. > > > > > > > > > > > > > > > > > > > > > > > > I could (of course with help from Peter Ivanov) do some > additional > > > > > > > > efforts > > > > > > to complete and improve process doc > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process > > > > > > > > > > > > > > > > > > > > > > > > I propose (most optimistic) dates for release stages: > > > > > > > > > > > > Scope Freeze: August 12, 2019 > > > > > > > > > > > > Code Freeze: August 15, 2019 > > > > > > > > > > > > Voting Date: August 22, 2019 > > > > > > > > > > > > Release Date: August 27, 2019 > > > > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > > > > > > > If nobody minds, I will create branch 2.7.6 based on 2.7.5 and > set up > > > > > > > > in > > > > > > the TC Bot during the weekend. > > > > > > > > > > > > > > > > > > > > > > > > Sincerely, > > > > > > > > > > > > Dmitriy Pavlov > > > > > > > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Ivan Pavlukhin > > > > >
[jira] [Created] (IGNITE-12060) Incorrect row size calculation, lead to tree corruption.
Dmitriy Govorukhin created IGNITE-12060: --- Summary: Incorrect row size calculation, lead to tree corruption. Key: IGNITE-12060 URL: https://issues.apache.org/jira/browse/IGNITE-12060 Project: Ignite Issue Type: Bug Reporter: Dmitriy Govorukhin Assignee: Dmitriy Govorukhin Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12059) DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration fails
Eduard Shangareev created IGNITE-12059: -- Summary: DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration fails Key: IGNITE-12059 URL: https://issues.apache.org/jira/browse/IGNITE-12059 Project: Ignite Issue Type: Bug Reporter: Eduard Shangareev Assignee: Eduard Shangareev DiskPageCompressionConfigValidationTest.testIncorrectStaticCacheConfiguration fails because validation was removed in IGNITE-9562. Need to restore this validation. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
Re: SecurityTestSuite as a separate test suite at TC
Denis, Perhaps with javassist we can make classes dynamically without use of surefire-fork-count parameters. We already use javassist in ConfigVariationsTestSuiteBuilder#makeTestClass, but for a different purpose. P.S. I did not check it yet. пт, 9 авг. 2019 г. в 14:41, Denis Garus : > > Excuse me! I was wrong. > I try to find that parameter on Step 4: Run test suite. > One more time, thank you! > > пт, 9 авг. 2019 г. в 14:05, Petr Ivanov : > > > Why do you think I did not use it? > > > > > > On 9 Aug 2019, at 13:25, Denis Garus wrote: > > > > Great! > > Could you please add surefire-fork-count-1 to additional Maven command > > line parameters? > > It's crucial. > > > > Thank you! > > > > пт, 9 авг. 2019 г. в 12:42, Petr Ivanov : > > > >> Done [1] > >> > >> > >> [1] https://ci.ignite.apache.org/viewLog.html?buildId=4482200 > >> > >> On 9 Aug 2019, at 12:02, Denis Garus wrote: > >> > >> Sure! I created the task [1]. > >> > >> Thank you! > >> > >> 1. https://issues.apache.org/jira/browse/IGNITE-12055 > >> > >> пт, 9 авг. 2019 г. в 11:38, Petr Ivanov : > >> > >>> Hi, Denis! > >>> > >>> > >>> Could file a ticket with description, please? > >>> > >>> On 9 Aug 2019, at 11:35, Denis Garus wrote: > >>> > >>> Thanks all for the feedback! > >>> > >>> I think no one is against of proposal. > >>> > >>> Petr, could you please assist with wit separation of SecurityTestSuite? > >>> > >>> чт, 8 авг. 2019 г. в 14:43, Denis Garus : > >>> > Hello, Ivan! > > >> Could you please provide more details why do we need to run these > tests in forked JVM? > > Surefite documentation [1] says: > If forkCount=0, it's impossible to use the system class loader or a > plain old Java classpath; we have to use an isolated class loader. > > When using isolated class loader will cause compiler error: > package org.apache.ignite.lang does not exist > > We cannot compile the TestIgniteCallable class. > > 1. > https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html > > чт, 8 авг. 2019 г. в 09:44, Павлухин Иван : > > > Denis, > > > > Could you please provide more details why do we need to run these > > tests in forked JVM? > > > > Still, having separate security suite on TC sounds not bad. > > > > ср, 7 авг. 2019 г. в 09:35, Vyacheslav Daradur : > > > > > > Hi Denis. > > > > > > I think it is fine to extract security tests in a separate build > > plan on TC. > > > > > > BTW, if you are going to write a lot of Sandbox's tests pay attention > > > to 'extdata' module and an approach of P2P tests > > > (IgniteP2PSelfTestSuite) - this may help you to avoid Maven's > > > classloading issues. > > > > > > On Tue, Aug 6, 2019 at 3:25 PM Denis Garus > > wrote: > > > > > > > > Hello Igniters! > > > > > > > > I made the test DoPrivelegedOnRemoteNodeTest[1] > > (SecurityTestSuite) for the > > > > task "Sandbox for user-defined code" [2] > > > > that uses p2p deploy like the test > > > > ServiceHotRedeploymentViaDeploymentSpiTest [3] from > > > > IgniteServiceGridTestSuite. > > > > That test requires additional Maven command line parameter -P > > > > surefire-fork-count-1. > > > > The suite Basic 1 contains the SecurityTestSuite and many other > > test suites > > > > at TeamCity that do not need that additional Maven parameter. > > > > I suggest extracting SecurityTestSuite as a separate test suite to > > define > > > > additional Maven command line parameter for it. > > > > > > > > WDYT? > > > > > > > > > > > > 1. https://github.com/apache/ignite/pull/6707 > > > > 2. https://issues.apache.org/jira/browse/IGNITE-11410 > > > > 3. > > > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/service/ServiceHotRedeploymentViaDeploymentSpiTest.java > > > > > > > > > > > > -- > > > Best Regards, Vyacheslav D. > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > > > >>> > >> > > -- Best regards, Ivan Pavlukhin
Re: Replacing NodeFilter functionality with label approach
Folks, I feel that the picture still is not clear for the subject. Pavel K., could you please highlight problems related to user code in NodeFilter except classloading? Nikolay, could you please provide some examples when node filtering cannot be solved with label/regexp approach? чт, 8 авг. 2019 г. в 15:39, Pavel Tupitsyn : > > I agree that attribute-based filtering is enough. > > We should get rid of predicates in configuration as much as possible: > they introduce a lot of complexity for other platforms (.NET), among other > things mentioned above. > > On Thu, Aug 8, 2019 at 2:04 PM Pavel Kovalenko wrote: > > > Ivan, > > > > > And there is also one idea (I am not fan of it but still). Can we use > > > some kind of scripting for nodes filtering? In that case node filter > > > is represented by script string, e.g. javascript. > > > > I guess it can lead to the same situation as in Java NodeFilter's. We can't > > control what happens in a filter in this case. > > We can consider regex as an option instead of just labels. It's still > > string and can be validated on correctness during node start. > > But we still don't have any real examples that require more flexibility > > than labels have. > > > > вт, 6 авг. 2019 г. в 14:46, Павлухин Иван : > > > > > Alexey, > > > > > > It seems that a problem has a solution with using 2 attributes or 2 > > > labels. Is not it more clear than using custom code? > > > > > > Folks, > > > > > > > I don't think we should take "hard to implement" as an argument in this > > > discussion :) > > > Did not fully get the point. KISS principle is not true anymore? Or is > > > this discussion somehow special? I believe that every flexibility > > > handle should be critically justified. Would be great to justify > > > NodeFilter flexibility. > > > > > > > Filters based of hostname or ip address. > > > Is it a good idea to use IP address for node filtering? IP can be > > > changed for a node with persistence, does it mean that not relevant > > > data (according to a filter) should be cleared, does it work now? > > > > > > And there is also one idea (I am not fan of it but still). Can we use > > > some kind of scripting for nodes filtering? In that case node filter > > > is represented by script string, e.g. javascript. > > > > > > вт, 6 авг. 2019 г. в 12:22, Alexey Kukushkin > >: > > > > > > > > Pavel, > > > > > > > > Just a real example you asked for: we have a user attribute "ROLE_DC", > > > > which is a comma separated list like "wfe_a, as_a, db_a" (server role > > and > > > > data center designator) and we have node filters to deploy services and > > > > start caches on servers with specific role (like WFE) and sometimes > > > > specific role and DC (like WFE_A). The node filter splits the list and > > > uses > > > > a regular expression to match each segment. > > > > > > > > If you replace generic node filter with a user attribute filter then we > > > > still can achieve what we need by creating 3 user attributes (ROLE_DC, > > > > ROLE and DC) but we lose flexibility since now adding a new data center > > > > requires updating all cache and service configurations. With regex > > > matching > > > > we do not need to update the configurations since we still match all > > the > > > > roles in the new DC. > > > > > > > > So we would have a solution with user attributes filter but I we lose > > > some > > > > flexibility. > > > > > > > > -- > > > > Best regards, > > > > Alexey > > > > > > > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > -- Best regards, Ivan Pavlukhin
Re: Issue with the TC disk space
Folks, I asked about TC infrastructure problems before and did not get answers. Does any of you know how to fix problems of that sort? Should not the process be transparent for a community members? пн, 12 авг. 2019 г. в 11:00, Dmitriy Pavlov : > > I also see some issues with 2.7.6 testing. Hopefully, it would be fixed > soon since it is a blocker for any activity for 2.7.6 > > пн, 12 авг. 2019 г. в 10:58, Nikolay Izhikov : > > > Hello, Igniters. > > > > Looks like TC has the issues with the free disk space [1] > > > > Can someone take a look? > > > > > > ``` > > [19:13:00]Free disk space requirement > > [19:13:00][Free disk space requirement] Removing files to meet 3 GB of > > free disk space required for directory /opt/buildagent/temp (only 122.05 MB > > is free now). > > [19:13:00][Free disk space requirement] Free disk space requirement of 3 > > GB is met for directory /opt/buildagent/work/69588afcb2ab3382 (106.14 GB is > > free) > > [19:13:00][Free disk space requirement] Free disk space requirement of 3 > > GB could not be met for directory /opt/buildagent/temp (only 123.32 MB is > > free) > > [19:13:00]Resolving artifact dependencies (4s) > > [19:13:01][Resolving artifact dependencies] Destination directory > > [/opt/buildagent/work/69588afcb2ab3382] cleaned > > [19:13:01][Resolving artifact dependencies] Downloading files from > Tests 2.4+ (Java 8/9/10/11) / ~Build Apache Ignite~, build #1084597 [id > > 4482201]> for pattern [ignite.zip!** => ./] > > [19:13:01][Resolving artifact dependencies] Downloading 1 artifact > > [19:13:04][Resolving artifact dependencies] Failed to resolve artifact > > dependency > build #1084597 [id 4482201]>: Failed to download file > > 'ignite.zip': No space left on device > > (jetbrains.buildServer.artifacts.impl.SourcePathAwareResolvingFailedException) > > [19:13:04]Failed to resolve artifacts from > 8/9/10/11) / ~Build Apache Ignite~, build #1084597 [id 4482201]> > > ``` > > > > [1] > > https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=4483694&_focus=60 > > -- Best regards, Ivan Pavlukhin
Re: Issue with the TC disk space
I also see some issues with 2.7.6 testing. Hopefully, it would be fixed soon since it is a blocker for any activity for 2.7.6 пн, 12 авг. 2019 г. в 10:58, Nikolay Izhikov : > Hello, Igniters. > > Looks like TC has the issues with the free disk space [1] > > Can someone take a look? > > > ``` > [19:13:00]Free disk space requirement > [19:13:00][Free disk space requirement] Removing files to meet 3 GB of > free disk space required for directory /opt/buildagent/temp (only 122.05 MB > is free now). > [19:13:00][Free disk space requirement] Free disk space requirement of 3 > GB is met for directory /opt/buildagent/work/69588afcb2ab3382 (106.14 GB is > free) > [19:13:00][Free disk space requirement] Free disk space requirement of 3 > GB could not be met for directory /opt/buildagent/temp (only 123.32 MB is > free) > [19:13:00]Resolving artifact dependencies (4s) > [19:13:01][Resolving artifact dependencies] Destination directory > [/opt/buildagent/work/69588afcb2ab3382] cleaned > [19:13:01][Resolving artifact dependencies] Downloading files from Tests 2.4+ (Java 8/9/10/11) / ~Build Apache Ignite~, build #1084597 [id > 4482201]> for pattern [ignite.zip!** => ./] > [19:13:01][Resolving artifact dependencies] Downloading 1 artifact > [19:13:04][Resolving artifact dependencies] Failed to resolve artifact > dependency build #1084597 [id 4482201]>: Failed to download file > 'ignite.zip': No space left on device > (jetbrains.buildServer.artifacts.impl.SourcePathAwareResolvingFailedException) > [19:13:04]Failed to resolve artifacts from 8/9/10/11) / ~Build Apache Ignite~, build #1084597 [id 4482201]> > ``` > > [1] > https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=4483694&_focus=60 >
Issue with the TC disk space
Hello, Igniters. Looks like TC has the issues with the free disk space [1] Can someone take a look? ``` [19:13:00]Free disk space requirement [19:13:00][Free disk space requirement] Removing files to meet 3 GB of free disk space required for directory /opt/buildagent/temp (only 122.05 MB is free now). [19:13:00][Free disk space requirement] Free disk space requirement of 3 GB is met for directory /opt/buildagent/work/69588afcb2ab3382 (106.14 GB is free) [19:13:00][Free disk space requirement] Free disk space requirement of 3 GB could not be met for directory /opt/buildagent/temp (only 123.32 MB is free) [19:13:00]Resolving artifact dependencies (4s) [19:13:01][Resolving artifact dependencies] Destination directory [/opt/buildagent/work/69588afcb2ab3382] cleaned [19:13:01][Resolving artifact dependencies] Downloading files from for pattern [ignite.zip!** => ./] [19:13:01][Resolving artifact dependencies] Downloading 1 artifact [19:13:04][Resolving artifact dependencies] Failed to resolve artifact dependency : Failed to download file 'ignite.zip': No space left on device (jetbrains.buildServer.artifacts.impl.SourcePathAwareResolvingFailedException) [19:13:04]Failed to resolve artifacts from ``` [1] https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=4483694&_focus=60 signature.asc Description: This is a digitally signed message part
[jira] [Created] (IGNITE-12058) AtomicReference issue with different userVersions
Niels Ejrnæs created IGNITE-12058:
-
Summary: AtomicReference issue with different userVersions
Key: IGNITE-12058
URL: https://issues.apache.org/jira/browse/IGNITE-12058
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7.5
Reporter: Niels Ejrnæs
Attachments: ignite-playground.tar.gz
When running DeploymentMode CONTINUOUS or SHARED and connecting a client node
with a different userVersion from the server nodes - IgniteAtomicLongs and
IgniteAtomicReferences cannot be fetched directly from Ignite.
{code:java}
IgniteAtomicLong atomicLong = ignite.atomicLong("long", 0, false);
IgniteAtomicReference atomicReference =
ignite.atomicReference("reference", "", false);
{code}
It throws an Exception {noformat}
SEVERE: Error deserializing job response: GridJobExecuteResponse
[nodeId=b52607ba-b6d1-47bc-983c-380af8a679bd,
sesId=f13d9c48c61-0fabe984-ecf1-4acf-84ac-3bdd478405f7,
jobId=023d9c48c61-0fabe984-ecf1-4acf-84ac-3bdd478405f7, gridEx=null,
isCancelled=false, retry=null]
class org.apache.ignite.IgniteCheckedException: Failed to unmarshal object with
optimized marshaller
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10147)
...
Caused by: class org.apache.ignite.internal.IgniteDeploymentCheckedException:
Failed to obtain deployment for class:
org.apache.ignite.configuration.CacheConfiguration$IgniteAllNodesPredicate
...
{noformat}
It works if you use a compute job to fetch it.
{code:java}
long remoteLong = ignite.compute().call(() -> { return
ignite.atomicLong("long", 0, false).get(); });
ignite.compute().call(() -> { return ignite.atomicLong("long", 0,
false).incrementAndGet(); });
String remoteReference = ignite.compute().call(() -> { return
ignite.atomicReference("reference", "", false).get(); });
{code}
I've attached a small reproducer project.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
