Re: Ability to check and completely fill transactions on creation

[Dmitriy Setrakyan]

On Wed, May 23, 2018 at 4:08 AM, Anton Vinogradov  wrote:

> Dmitriy, Yakov
>
> Are there any objections to updated design taking into account the comments
> I provided?
>

Anton, I do not like an additional validator. I think you can accomplish
the same with a transaction event. You just need to design it more cleanly,
incorporating the feedback from Yakov.

[GitHub] ignite pull request #3780: IGNITE-4958: Make data pages recyclable into inde...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3780


---

Re: IEP-4, Phase 2. Using BL(A)T for in-memory caches.

[Dmitriy Setrakyan]

Ed,

Anyone speaking Russian would agree that BLAT is not a good name :) Let's
steak to BLT.

D.

On Wed, May 23, 2018 at 5:34 AM, Eduard Shangareev <
eduard.shangar...@gmail.com> wrote:

> Igniters,
>
> We have invested too much in explaining BLAT. So, it would hard to change
> the name.
> I.e. I propose to save this term.
>
>
> New names for auto-adjust control.
>
> 1. org.apache.ignite.IgniteCluster
>
> *Add*
> isBaselineAutoAdjustEnabled()
> setBaselineAutoAdjustEnabled(boolean enabled);
> setBaselineAutoAdjustTimeout(long timeoutInMs);
> setBaselineAutoAdjustMaxTimeout(long timeoutInMs);
>
> 2. org.apache.ignite.configuration.IgniteConfiguration
>
> *Add*
> IgniteConfiguration setBaselineAutoAdjustEnabled(boolean enabled);
> IgniteConfiguration setBaselineAutoAdjustTimeout(long timeoutInMs);
> IgniteConfiguration setBaselineAutoAdjustMaxTimeout(long timeoutInMs);
>
> Any objections?
>
>
>
> On Fri, May 4, 2018 at 10:01 PM, Dmitriy Setrakyan 
> wrote:
>
> > I do not like the name "current" on the methods. I think we should just
> > remove it, e.g. currentAffinityTopology() -> affinityTopology()
> >
> > D.
> >
> > On Fri, May 4, 2018 at 6:17 AM, Eduard Shangareev <
> > eduard.shangar...@gmail.com> wrote:
> >
> > > Igniters,
> > >
> > > With Vladimir's help, we analyzed another solution's approaches.
> > > And decided to simplify our affinity topology auto-adjusting.
> > >
> > > It should be enough to be able to turn on/off auto-adjusting (flag) and
> > set
> > > 2 timeouts if it is working:
> > > -soft timeout which would be used if there was no other node
> joins/exits;
> > > -hard timeout which we would track from first discovery event and if it
> > > reached then immediately would change affinity topology.
> > >
> > > All other strategies could be realized with API usage
> > (setAffinityTopology)
> > > and metrics tracking by user's monitoring tools.
> > >
> > > So, I suggest next API changes:
> > >
> > > org.apache.ignite.IgniteCluster
> > >
> > > *Deprecate*:
> > > Collection currentBaselineTopology();
> > > void setBaselineTopology(Collection
> > baselineTop);
> > > void setBaselineTopology(long topVer);
> > >
> > > *Replace them with*
> > > Collection currentAffinityTopology();
> > > void setAffinityTopology(Collection
> > affinityTop);
> > > void setAffinityTopology(long topVer);
> > >
> > > *Add*
> > > isAffinityTopologyAutoAdjustEnabled()
> > > setAffinityTopologyAutoAdjustEnabled(boolean enabled);
> > >
> > > org.apache.ignite.configuration.IgniteConfiguration
> > >
> > > *Add*
> > > IgniteConfiguration setAffinityTopologyAutoAdjustEnabled(boolean
> > enabled);
> > > IgniteConfiguration setAffinityTopologyAutoAdjustTimeout(long
> > > timeoutInMs);
> > > IgniteConfiguration setAffinityTopologyAutoAdjustMaxTimeout(long
> > > timeoutInMs);
> > >
> > >
> > > An open question is could we rename or duplicate BaselineNode with
> > > AffinityNode?
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Apr 27, 2018 at 6:56 PM, Ivan Rakov 
> > wrote:
> > >
> > > > Eduard,
> > > >
> > > > +1 to your proposed API for configuring Affinity Topology change
> > > policies.
> > > > Obviously we should use "auto" as default behavior. I believe,
> > automatic
> > > > rebalancing is expected and more convenient for majority of users.
> > > >
> > > > Best Regards,
> > > > Ivan Rakov
> > > >
> > > >
> > > > On 26.04.2018 19:27, Eduard Shangareev wrote:
> > > >
> > > >> Igniters,
> > > >>
> > > >> Ok, I want to share my thoughts about "affinity topology (AT)
> changing
> > > >> policies".
> > > >>
> > > >>
> > > >> There would be three major option:
> > > >> -auto;
> > > >> -manual;
> > > >> -custom.
> > > >>
> > > >> 1. Automatic change.
> > > >> A user could set timeouts for:
> > > >> a. change AT on any topology change after some timeout
> > > (setATChangeTimeout
> > > >> in seconds);
> > > >> b. change AT on node left after some timeout
> > > (setATChangeOnNodeLeftTimeout
> > > >> in seconds);
> > > >> c. change AT on node join after some timeout
> > > (setATChangeOnNodeJoinTimeout
> > > >> in seconds).
> > > >>
> > > >> b and c are more specific, so they would override a.
> > > >>
> > > >> Also, I want to introduce a mechanism of merging AT changes, which
> > would
> > > >> be
> > > >> turned on by default.
> > > >> Other words, if we reached timeout than we would change AT to
> current
> > > >> topology, not that one which was on timeout schedule.
> > > >>
> > > >> 2. Manual change.
> > > >>
> > > >> Current behavior. A user change AT himself by console tools or web
> > > >> console.
> > > >>
> > > >> 3. Custom.
> > > >>
> > > >> We would give the option to set own realization of changing policy
> > > (class
> > > >> name in config).
> > > >> We should pass as incoming parameters:
> > > >> - current topology (collection of cluster nodes);
> > > >> - current AT (affinity topology);
> > > >> - map of GroupId to minimal alive backup number;
> > > >> - list of 

[jira] [Created] (IGNITE-8590) Overridden members in descendant classes can cause BinaryMarshaller exceptions

[Raymond Wilson (JIRA)]

Raymond Wilson created IGNITE-8590:
--

 Summary: Overridden members in descendant classes can cause 
BinaryMarshaller exceptions
 Key: IGNITE-8590
 URL: https://issues.apache.org/jira/browse/IGNITE-8590
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.4
 Environment: Apache Ignite 2.4 using .Net client with .Net Standard 
artifacts.
Reporter: Raymond Wilson


If you define a pair of classes, one descended from the other, with an 
overridden field, the Ignite binary marshaller throws the exception shown 
below. 

 

public class A

{

public int Filters;

}

 

public class B : A

{

public int Filters;

}

 

This code compiles (with a warning about an overridden field that does not use 
the C# 'new' annotation) and runs, but produces this exception if class B is 
supplied to an Ignite Compute function as an argument.

 

2018-05-22 13:40:50,523 [13] ERROR PlanViewTileRenderer. ExecutePipeline raised 
exception System.AggregateException: One or more errors occurred. ---> 
Apache.Ignite.Core.Binary.BinaryObjectException: Conflicting field IDs 
[type=SubGridsRequestArgument, field1=Filters, field2=Filters, 
fieldId=-854547461]

   at 
Apache.Ignite.Core.Impl.Binary.BinaryReflectiveSerializerInternal.Register(Type 
type, Int32 typeId, IBinaryNameMapper converter, IBinaryIdMapper idMapper, 
Boolean forceTimestamp)

   at 
Apache.Ignite.Core.Impl.Binary.Marshaller.GetSerializer(BinaryConfiguration 
cfg, BinaryTypeConfiguration typeCfg, Type type, Int32 typeId, 
IBinaryNameMapper nameMapper, IBinaryIdMapper idMapper, ILogger log)

   at Apache.Ignite.Core.Impl.Binary.Marshaller.AddUserType(Type type, Int32 
typeId, String typeName, Boolean registered, BinaryFullTypeDescriptor desc)

   at Apache.Ignite.Core.Impl.Binary.Marshaller.RegisterType(Type type, 
BinaryFullTypeDescriptor desc)

   at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type type)

   at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)

   at 
Apache.Ignite.Core.Impl.Deployment.PeerLoadingExtensions.WriteWithPeerDeployment(BinaryWriter
 writer, Object o)

   at 
Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1 
obj, BinaryWriter writer)

   at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)

   at 
Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1 
obj, BinaryWriter writer)

   at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)

   at Apache.Ignite.Core.Impl.Binary.BinaryWriter.WriteObjectDetached[T](T o)

   at Apache.Ignite.Core.Impl.Compute.ComputeImpl.WriteJob(IComputeJob job, 
BinaryWriter writer)

   at 
Apache.Ignite.Core.Impl.Compute.ComputeImpl.<>c__DisplayClass1d`3.b__1a(BinaryWriter
 writer)

   at Apache.Ignite.Core.Impl.PlatformTargetAdapter.WriteToStream(Action`1 
action, IBinaryStream stream, Marshaller marsh)

   at Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutObject(Int32 type, 
Action`1 writeAction)

   at 
Apache.Ignite.Core.Impl.Compute.ComputeImpl.ExecuteClosures0[TArg,TJobRes,TReduceRes](IComputeTask`3
 task, IComputeJob job, IEnumerable`1 jobs, Int32 opId, Int32 jobsCount, 
Action`1 writeAction)

   --- End of inner exception stack trace ---

   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean 
includeTaskCanceledExceptions)

   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, 
CancellationToken cancellationToken)

   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout)

   at VSS.TRex.GridFabric.Requests.SubGridRequestsProgressive`2.Execute() in 
C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\GridFabric\Requests\SubGridRequestsProgressive.cs:line
 107

   at VSS.TRex.Pipelines.SubGridPipelineBase`3.Initiate() in 
C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\Pipelines\SubGridPipelineBase.cs:line
 241

   at VSS.TRex.Rendering.PlanViewTileRenderer.ExecutePipeline() in 
C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\Rendering\PlanViewTileRenderer.cs:line
 262

---> (Inner Exception #0) Apache.Ignite.Core.Binary.BinaryObjectException: 
Conflicting field IDs [type=SubGridsRequestArgument, field1=Filters, 
field2=Filters, fieldId=-854547461]

   at 
Apache.Ignite.Core.Impl.Binary.BinaryReflectiveSerializerInternal.Register(Type 
type, Int32 typeId, IBinaryNameMapper converter, IBinaryIdMapper idMapper, 
Boolean forceTimestamp)

   at 
Apache.Ignite.Core.Impl.Binary.Marshaller.GetSerializer(BinaryConfiguration 
cfg, BinaryTypeConfiguration typeCfg, Type type, Int32 typeId, 
IBinaryNameMapper nameMapper, IBinaryIdMapper idMapper, ILogger log)

   at Apache.Ignite.Core.Impl.Binary.Marshaller.AddUserType(Type type, Int32 
typeId, String typeName, Boolean registered, BinaryFullTypeDescriptor desc)

   at Apache.Ignite.Core.Impl.Binary.Marshaller.RegisterType(Type type, 

Re: NodeJS thin client: full API

[Denis Magda]

Alexey, Pavel,

I've done a preliminary review of the doc and moved it to the readme.io
page:
https://apacheignite.readme.io/v2.4/docs/nodejs-thin-client

The page is hidden. I'll grant you access to readme so that you can update
the doc taking my suggestions into account:
https://issues.apache.org/jira/browse/IGNITE-8589

--
Denis


On Mon, May 21, 2018 at 6:39 PM, Alexey Kuznetsov 
wrote:

> Hi,
>
> FYI, HZ also has NodeJs client: https://github.com/
> hazelcast/hazelcast-nodejs-client
> May be it is worth to take a look?
>
> --
> Alexey Kuznetsov
>

[jira] [Created] (IGNITE-8589) Prepare Node.JS Thin Client documentation

[Denis Magda (JIRA)]

Denis Magda created IGNITE-8589:
---

 Summary: Prepare Node.JS Thin Client documentation
 Key: IGNITE-8589
 URL: https://issues.apache.org/jira/browse/IGNITE-8589
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Denis Magda
Assignee: Pavel Petroshenko
 Fix For: 2.6


The hidden page is presently here:
https://apacheignite.readme.io/v2.4/docs/nodejs-thin-client

Once all the suggestions are resolved, we might split this page into several 
pages. I can do this closer to 2.6 release.

[~pavel.petroshenko], [~alexey.kosenchuk], please address the following 
suggestions for now:

Installation section:
* Ignite repository has to be used instead of the private one
* The section needs to explain the installation steps once the NPM module is 
released. It's fine to put the current installation instructions under 
"Installing from Sources" section.

Data Types:
* The term "field" is truly confusing. Does it really imply any possible data 
(value, key, element of an array)? Why can't we use the term "value" instead?
* Provide a code snippet that shows how to configure the explicit mapping
* Default mapping has to be documented in place on readme.io (no references to 
the private GIT repo)

Configuring Ignite Client
*Failover on a reconnect code snippet. How to pass a list of the endpoints.

General:
* You use CacheClient or just Cache notion to refer to an instance of the cache 
class. Let's use one term. I prefer the Cache one or IgniteCache if it's named 
this way.
* Add a reference to the examples once they are merged to Ignite repo (see the 
latest section on the readme page)
* Add a reference to Node.JS APIs within supported APIs section.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8588) .NET: Serialization issue when derived type hides base type member

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-8588:
--

 Summary: .NET: Serialization issue when derived type hides base 
type member
 Key: IGNITE-8588
 URL: https://issues.apache.org/jira/browse/IGNITE-8588
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.4
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn


The following class structure causes an exception that is hard to understand 
(when putting instance of B into Ignite cache):

{code}
public class A
{
  public int bob;
} 

public class B : A
{
  public int bob;
}
{code}

See user list thread for more details:
http://apache-ignite-users.70518.x6.nabble.com/Binary-type-has-different-fields-error-td21540.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #4057: IGNITE-8584: Provide ability to terminate any thr...

[x-kreator]

GitHub user x-kreator opened a pull request:

https://github.com/apache/ignite/pull/4057

IGNITE-8584: Provide ability to terminate any thread with enabled tes…

…t features.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/x-kreator/ignite ignite-8584

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4057.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4057


commit 7c0cd0e08a0460982a392c96bbfe02353ec35227
Author: Dmitriy Sorokin 
Date:   2018-05-23T18:24:24Z

IGNITE-8584: Provide ability to terminate any thread with enabled test 
features.




---

[jira] [Created] (IGNITE-8587) High Contention in GridToStringBuilder.toStringImpl

[Sergey Kosarev (JIRA)]

Sergey Kosarev created IGNITE-8587:
--

 Summary: High Contention in GridToStringBuilder.toStringImpl  
 Key: IGNITE-8587
 URL: https://issues.apache.org/jira/browse/IGNITE-8587
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Sergey Kosarev
Assignee: Sergey Kosarev






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #4056: IGNITE-8586 Minor fix for Apache Ignite's release...

[vveider]

GitHub user vveider opened a pull request:

https://github.com/apache/ignite/pull/4056

IGNITE-8586 Minor fix for Apache Ignite's release procedure



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8586

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4056.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4056


commit 16244d7ff374d59975e6b6b735f423d782c759f5
Author: Ivanov Petr 
Date:   2018-05-23T15:33:19Z

IGNITE-8586 Minor fix for Apache Ignite's release procedure




---

[jira] [Created] (IGNITE-8586) Minor fix for Apache Ignite's release procedure

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-8586:


 Summary: Minor fix for Apache Ignite's release procedure
 Key: IGNITE-8586
 URL: https://issues.apache.org/jira/browse/IGNITE-8586
 Project: Ignite
  Issue Type: Bug
Reporter: Peter Ivanov
Assignee: Peter Ivanov


Fix package.sh to not require sudo permissions for packages build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8585) Remove ignored-tests module, move those tests to regular suites in commented out form

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-8585:
---

 Summary: Remove ignored-tests module, move those tests to regular 
suites in commented out form
 Key: IGNITE-8585
 URL: https://issues.apache.org/jira/browse/IGNITE-8585
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.6
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev


Nobody either updates or runs this module and it's infeasible to use!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Apache Ignite 2.5 release

[Andrey Gura]

Hi,

looks like critical issue. Please merge to ignite-2.5 branch.

Thanks!

On Wed, May 23, 2018 at 3:28 PM, Alexey Goncharuk
 wrote:
> Agree, I think we should include this fix in 2.5 as well, otherwise users
> who enable WAL compaction may face data consistency issues after various
> topology restarts.
>
> ср, 23 мая 2018 г. в 12:33, Ivan Rakov :
>
>> Igniters,
>>
>> Unfortunately, previous issue mentioned by Alex G. [1] has broken WAL
>> compaction in 2.5.
>> Follow up fix is already implemented and merged to master [2]. I suggest
>> to include it into 2.5 scope; any user attempt to enable compaction on
>> 2.5 (or use previously compacted WAL segments) will fail with exception
>> otherwise.
>>
>> [1] - https://issues.apache.org/jira/browse/IGNITE-8464
>> [2] - https://issues.apache.org/jira/browse/IGNITE-8561
>>
>> Best Regards,
>> Ivan Rakov
>>
>> On 17.05.2018 19:28, Denis Magda wrote:
>> > Alexey,
>> >
>> > Makes sense to merge.
>> >
>> > --
>> > Denis
>> >
>> > On Thu, May 17, 2018 at 8:53 AM, Alexey Goncharuk <
>> > alexey.goncha...@gmail.com> wrote:
>> >
>> >> Denis,
>> >>
>> >> The issue with page corruption may manifest itself when a node is
>> stopped
>> >> during partition eviction (basically, a random chance on topology change
>> >> scenario).
>> >>
>> >> The issue with WAL iterator can manifest during historical rebalancing
>> >> (this is less likely than the previous issue).
>> >>
>> >> 2018-05-17 18:07 GMT+03:00 Denis Magda :
>> >>
>> >>> We keep facing the issues that postpone the release over and over again
>> >>> which seems like a never-ending story.
>> >>>
>> >>> What are the changes the users come across the 2 latest bugs you've
>> >>> mentioned (any special conditions)?
>> >>>
>> >>> What's the overall state of our testing cycles? When would we send the
>> >>> release for vote if include the abovementioned bugs or move them to the
>> >>> next release?
>> >>>
>> >>> --
>> >>> Denis
>> >>>
>> >>> On Thu, May 17, 2018 at 7:44 AM, Alexey Goncharuk <
>> >>> alexey.goncha...@gmail.com> wrote:
>> >>>
>>  Another issue that may lead to incorrect recovery on node startup is
>>  https://issues.apache.org/jira/browse/IGNITE-8464 which is already in
>> >>> PA.
>>  I
>>  suggest we also include it to 2.5 given that fix improves stability of
>> >>> the
>>  persistence layer. Any objections?
>> 
>>  2018-05-17 16:55 GMT+03:00 Ivan Rakov :
>> 
>> > Andrey, Igniters,
>> >
>> > I bumped into this issue while trying to reproduce another:
>> > https://issues.apache.org/jira/browse/IGNITE-8320
>> > I think, this fix worth being cherry-picked into 2.5. Possibility of
>> > AssertionError on persistence level is really undesirable for Ignite
>> >>> as a
>> > product.
>> >
>> > Best Regards,
>> > Ivan Rakov
>> >
>> >
>> > On 14.05.2018 15:59, Andrey Gura wrote:
>> >
>> >> Igniters,
>> >>
>> >> we are ready to start process of releasing Apache Ignite 2.5.
>> >>
>> >> So code freeze. No more commits to ignite-2.5 branch.
>> >>
>> >> Thanks!
>> >>
>> >>
>> >> On Thu, May 10, 2018 at 8:02 PM, Andrey Gura 
>> >>> wrote:
>> >>> Igniters,
>> >>>
>> >>> Almost all issues for Apache Ignite 2.5 release are fixed. Issues
>> >>> that
>> >>> are still in Open state will be moved to 2.6 release.
>> >>>
>> >>> Code freeze for ignite-2.5 branch is planed for tomorrow.
>> >>>
>> >>> Thanks!
>> >>>
>> >>> On Tue, May 8, 2018 at 7:09 PM, Andrey Gura 
>> >>> wrote:
>>  Thanks for fast update, Ivan.
>> 
>>  On Tue, May 8, 2018 at 5:59 PM, Ivan Rakov >  wrote:
>> 
>> > Andrey,
>> >
>> > Sorry to disturb you again. I have a follow up fix for
>> >> IGNITE-8429
>> >>> -
>> > https://issues.apache.org/jira/browse/IGNITE-8453.
>> > Please merge it to master and ignite-2.5.
>> >
>> > Best Regards,
>> > Ivan Rakov
>> >
>> >
>> > On 08.05.2018 15:29, Vladimir Ozerov wrote:
>> >
>> >> H2 version updated is moved to AI 2.6. There are several serious
>> >> problems,
>> >> main - spatial dependency replacement which is a breaking
>> >> change.
>> >> On Tue, May 8, 2018 at 10:17 AM, Pavel Tupitsyn <
>>  ptupit...@apache.org
>> >> wrote:
>> >>
>> >> IGNITE-8434 merged to master, cherry-picked to ignite-2.5.
>> >>> Thank you, Andrey!
>> >>>
>> >>> On Mon, May 7, 2018 at 10:46 PM, Andrey Gura > >>> wrote:
>> >>>
>> >>> Pavel,
>>  issue is targeted to release 2.5 now. Thanks!
>> 
>>  On Mon, May 7, 2018 at 10:40 PM, Pavel Tupitsyn <
>> 

[jira] [Created] (IGNITE-8584) Provide ability to terminate any thread with enabled test features

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-8584:
---

 Summary: Provide ability to terminate any thread with enabled test 
features
 Key: IGNITE-8584
 URL: https://issues.apache.org/jira/browse/IGNITE-8584
 Project: Ignite
  Issue Type: New Feature
Reporter: Andrey Gura
 Fix For: 2.6


We already have {{WorkersControlMXBean}} that provides possibility to interrupt 
thread registered in system workers registry. We also want stop any thread in 
the system for testing purposes.

Method {{stop(String threadName)}} should be added that have to find thread by 
name and stop it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8583) DataStorageMetricsMXBean.getOffHeapSize include checkpoint buffer size, this is not clear

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-8583:
--

 Summary: DataStorageMetricsMXBean.getOffHeapSize include 
checkpoint buffer size, this is not clear
 Key: IGNITE-8583
 URL: https://issues.apache.org/jira/browse/IGNITE-8583
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Govorukhin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8582) MVCC TX: Cache store read-through support

[Sergey Kalashnikov (JIRA)]

Sergey Kalashnikov created IGNITE-8582:
--

 Summary: MVCC TX: Cache store read-through support
 Key: IGNITE-8582
 URL: https://issues.apache.org/jira/browse/IGNITE-8582
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Sergey Kalashnikov


Add support for read-through cache store for mvcc caches.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8581) MVCC TX: data streamer support

[Sergey Kalashnikov (JIRA)]

Sergey Kalashnikov created IGNITE-8581:
--

 Summary: MVCC TX: data streamer support
 Key: IGNITE-8581
 URL: https://issues.apache.org/jira/browse/IGNITE-8581
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Sergey Kalashnikov


Add support for data streamer for mvcc caches.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: TeamCity permissions

[Vitaliy Osipov]

Hi.

Done. Check please.

On 23 May 2018 at 17:28, Maxim Muzafarov  wrote:

> Hello, Igniters
>
> Would you be so pleased, also grant permissions to cancel builds on
> TeamCity for me? I'm not iteresting to reorder builds.
> Username: mmuzaf
>
>
> пн, 21 мая 2018 г. в 19:32, Pavel Petroshenko :
>
>> It works, thanks Vitaliy!
>>
>> p.
>>
>> On Sun, May 20, 2018 at 1:16 PM, Vitaliy Osipov 
>> wrote:
>>
>> > Pavel. Hi
>> >
>> > The necessary rights have been added. Check please.
>> >
>> > On 19 May 2018 at 01:48, Pavel Petroshenko 
>> wrote:
>> >
>> >> Thank you, Denis! I need to have a role to be able to temporary
>> rearrange
>> >> builds in the TC build queue for testing and CI integration purposes.
>> >>
>> >> Vitaly, I would appreciate any help.
>> >>
>> >> Thanks,
>> >> P.
>> >>
>> >>
>> >> On Fri, May 18, 2018 at 10:49 AM, Denis Magda 
>> wrote:
>> >>
>> >>> Hi Pavel,
>> >>>
>> >>> All the accounts are assigned Project developer role on TC that should
>> >>> provide anything you need to manage builds there.
>> >>>
>> >>> What specifically are you looking for? Please elaborate so that Vitaly
>> >>> can
>> >>> grant more permissions.
>> >>>
>> >>> Vitaly, please keep an eye on the conversation.
>> >>>
>> >>> --
>> >>> Denis
>> >>>
>> >>>
>> >>> On Fri, May 18, 2018 at 9:44 AM, Pavel Petroshenko <
>> >>> pa...@petroshenko.com>
>> >>> wrote:
>> >>>
>> >>> > Hi,
>> >>> >
>> >>> > Can anyone please grant TC permissions to manage jobs (reorder, etc)
>> >>> to:
>> >>> >
>> >>> > ekaterina.vergizova
>> >>> > alexey.kosenchuk
>> >>> > pavel.petroshenko
>> >>> >
>> >>> > Thanks!
>> >>> > p.
>> >>> >
>> >>>
>> >>
>> >>
>> >
>> >
>> > --
>> > Kind Regards
>> > Vitaliy Osipov
>> > vosi...@gridgain.com
>> > *+7 (921) 397 27 68 <+7%20921%20397-27-68>*
>> >
>> > *gridgain.com *Powered by Apache® Ignite™
>> >
>>
>


-- 
Kind Regards
Vitaliy Osipov
vosi...@gridgain.com
*+7 (921) 397 27 68*

*gridgain.com *Powered by Apache® Ignite™

Re: Baseline topology documentation clarified: usage scenarios and definition

[Dmitry Pavlov]

Hi Ivan,

Would you like to run presentation based on this slides for Igniters?

We can set up webinar using gotomeeting if you like this idea.

Sincerely,
Dmitriy Pavlov

ср, 23 мая 2018 г. в 0:19, Ivan Rakov :

> I used to present some slides introducing baseline topology concept.
> Please feel free to use or change any pictures.
>
> https://docs.google.com/presentation/d/1DVLwlaR0zPIuL5YMkX8MyGLutZw-tvK9InDTCvubAEQ/edit?usp=sharing
>
> Best Regards,
> Ivan Rakov
>
> On 18.05.2018 15:20, Dmitriy Setrakyan wrote:
> > Great docs! Any chance we could add some pictures to illustrate the
> concept
> > better.
> >
> > On Fri, May 18, 2018 at 2:15 AM, Denis Magda  wrote:
> >
> >> Igniters,
> >>
> >> With the help of Stanislav Lukyanov and Ivan Rakov, we could make our
> >> baseline topology documentation much better and vivid. Check up the new
> >> sections that did a better job explaining the topology, cover common
> usage
> >> scenarious and explain how to trigger the rebalancing programmatically
> if
> >> it's not expected that the baseline topology's node count to be
> recovered
> >> soon:
> >>
> >> - https://apacheignite.readme.io/v2.4/docs/cluster-
> >> activation#section-baseline-topology
> >> <
> https://apacheignite.readme.io/v2.4/docs/cluster-activation#section-baseline-topology
> >
> >> - https://apacheignite.readme.io/v2.4/docs/cluster-
> >> activation#section-usage-scenarios
> >> <
> https://apacheignite.readme.io/v2.4/docs/cluster-activation#section-usage-scenarios
> >
> >> - https://apacheignite.readme.io/v2.4/docs/cluster-
> >> activation#section-triggering-rebalancing-programmatically
> >> <
> https://apacheignite.readme.io/v2.4/docs/cluster-activation#section-triggering-rebalancing-programmatically
> >
> >>
> >> --
> >> Denis
> >>
>
>

Re: How to turn debug log on in Intellij Idea console for ignite core module?

[Ray]

Thanks for the reply.

But your approach seems only to be working for tests in Ignite core module.
What I'm looking for is a way to open DEBUG mode when starting an Ignite
node from
modules/core/src/main/java/org/apache/ignite/startup/cmdline/CommandLineStartup.java.



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: TeamCity permissions

[Maxim Muzafarov]

Hello, Igniters

Would you be so pleased, also grant permissions to cancel builds on
TeamCity for me? I'm not iteresting to reorder builds.
Username: mmuzaf


пн, 21 мая 2018 г. в 19:32, Pavel Petroshenko :

> It works, thanks Vitaliy!
>
> p.
>
> On Sun, May 20, 2018 at 1:16 PM, Vitaliy Osipov 
> wrote:
>
> > Pavel. Hi
> >
> > The necessary rights have been added. Check please.
> >
> > On 19 May 2018 at 01:48, Pavel Petroshenko 
> wrote:
> >
> >> Thank you, Denis! I need to have a role to be able to temporary
> rearrange
> >> builds in the TC build queue for testing and CI integration purposes.
> >>
> >> Vitaly, I would appreciate any help.
> >>
> >> Thanks,
> >> P.
> >>
> >>
> >> On Fri, May 18, 2018 at 10:49 AM, Denis Magda 
> wrote:
> >>
> >>> Hi Pavel,
> >>>
> >>> All the accounts are assigned Project developer role on TC that should
> >>> provide anything you need to manage builds there.
> >>>
> >>> What specifically are you looking for? Please elaborate so that Vitaly
> >>> can
> >>> grant more permissions.
> >>>
> >>> Vitaly, please keep an eye on the conversation.
> >>>
> >>> --
> >>> Denis
> >>>
> >>>
> >>> On Fri, May 18, 2018 at 9:44 AM, Pavel Petroshenko <
> >>> pa...@petroshenko.com>
> >>> wrote:
> >>>
> >>> > Hi,
> >>> >
> >>> > Can anyone please grant TC permissions to manage jobs (reorder, etc)
> >>> to:
> >>> >
> >>> > ekaterina.vergizova
> >>> > alexey.kosenchuk
> >>> > pavel.petroshenko
> >>> >
> >>> > Thanks!
> >>> > p.
> >>> >
> >>>
> >>
> >>
> >
> >
> > --
> > Kind Regards
> > Vitaliy Osipov
> > vosi...@gridgain.com
> > *+7 (921) 397 27 68 <+7%20921%20397-27-68>*
> >
> > *gridgain.com *Powered by Apache® Ignite™
> >
>

[GitHub] ignite pull request #4053: IGNITE-8561 SingleSegmentLogicalRecordsIterator i...

[glukos]

GitHub user glukos opened a pull request:

https://github.com/apache/ignite/pull/4053

IGNITE-8561 SingleSegmentLogicalRecordsIterator is broken

Signed-off-by: Ivan Rakov 

(cherry picked from commit 21678bc)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8561-2.5

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4053.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4053


commit 3c112ccdb08512febd1234b14ca08521130a49df
Author: Anton Kalashnikov 
Date:   2018-05-23T09:24:51Z

IGNITE-8561 SingleSegmentLogicalRecordsIterator is broken

Signed-off-by: Ivan Rakov 

(cherry picked from commit 21678bc)




---

[jira] [Created] (IGNITE-8580) Print page read/write metrics splitted by type

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-8580:
---

 Summary: Print page read/write metrics splitted by type
 Key: IGNITE-8580
 URL: https://issues.apache.org/jira/browse/IGNITE-8580
 Project: Ignite
  Issue Type: Task
  Components: persistence
Reporter: Vladimir Ozerov
 Fix For: 2.6


Currently it is impossible to track how many pages of a certain type were read 
from or written to disk. This might be very useful for performance tuning and 
debugging purposes. E.g. excessive page reads may highlight missing SQL index.

We need to expose total read/write pages metrics splitted by page type (see 
org.apache.ignite.internal.processors.cache.persistence.tree.io.PageIO#getType()).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8579) SQL: Unicast request with LIMIT should skip merge table if possible

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-8579:
---

 Summary: SQL: Unicast request with LIMIT should skip merge table 
if possible
 Key: IGNITE-8579
 URL: https://issues.apache.org/jira/browse/IGNITE-8579
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.5
Reporter: Vladimir Ozerov
 Fix For: 2.6


*Problem*
We have two cases when request could be executed only over a single partition:
1) With explicit partition
2) When partition pruning optimization reduced request to a single partition 
(IGNITE-4509). E.g. if {{department_id}} is affinity key in the query below:
{code}
SELECT * FROM emp WHERE department_id=? LIMIT 50;
{code}

In both cases we need to ensure that instead of fully-fledged two-step 
execution, we perform only map request, and reduce phase is skipped. I.e. 
{{org.apache.ignite.internal.processors.cache.query.GridCacheTwoStepQuery#skipMergeTbl}}
 is resolved to true.

*Reproducer*
The following query reproduces a situation when this is not the case at the 
moment, and merge table is initialized
{code}
CREATE TABLE emp (pk_id BIGINT, dept_ID BIGINT, name VARCHAR, PRIMARY 
KEY(pk_id, dept_id) WITH "AFFINITY_KEY=dept_id";
SELECT * FROM emp WHERE dept_id=? LIMIT 10
{code}

Notice that reduce phase exists, while in reality it is not needed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Ticket review checklist

[Dmitry Pavlov]

Hi Vladimir,

I've replied in separate thread.

I would like to keep requirement of Green TC instead of separation to
new/old test failures.

Once you allow just one test failure, it would be more failures after some
time.

Sincererly,
Dmitriy Pavlov

ср, 23 мая 2018 г. в 17:02, Vladimir Ozerov :

> Igniters,
>
> I created review checklist on WIKI [1] and also fixed related pages (e.g.
> "How To Contribute"). Please let me know if you have any comments before I
> go with public announce.
>
> Vladimir.
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
>
> On Thu, May 10, 2018 at 5:10 PM, Vladimir Ozerov 
> wrote:
>
> > Ilya,
> >
> > We define that exception messages *SHOULD* have clear explanation on what
> > is wrong. *SHOULD* mean that the rule should be followed unless there is
> a
> > reason not to follow. In your case you refer to some unexpected behavior.
> > I.e. an exceptional situation developer is not aware of. In this case for
> > sure we cannot force contributor to explain what is wrong, because, well,
> > we don't know. This is why we relaxed the rule from *MUST* to *SHOULD*.
> >
> > On Thu, May 10, 2018 at 3:50 PM, Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com> wrote:
> >
> >> I don't think I quite understand how exception explanations should work.
> >>
> >> Imagine we have the following exception:
> >>
> >> // At least RuntimeException can be thrown by the code above when
> >> GridCacheContext is cleaned and there is
> >> // an attempt to use cleaned resources.
> >> U.error(log, "Unexpected exception during cache update", e);
> >>
> >> I mean, we genuinely don't know what happened here.
> >>
> >> Under new rules, what kind of "workaround" would that exception suggest?
> >> "Try turning it off and then back on"?
> >> What explanation how to resolve this exception can we offer? "Please
> write
> >> to d...@apache.ignite.org or to Apache JIRA, and then wait for a release
> >> with fix?"
> >>
> >> I'm really confused how we can implement 1.6 and 1.7 when dealing with
> >> messy real-world code.
> >>
> >> Regards,
> >>
> >>
> >> --
> >> Ilya Kasnacheev
> >>
> >> 2018-05-10 11:39 GMT+03:00 Vladimir Ozerov :
> >>
> >> > Andrey, Anton, Alex
> >> >
> >> > Agree, *SHOULD* is more appropriate here.
> >> >
> >> > Please see latest version below. Does anyone want to add or change
> >> > something? Let's wait for several days for more feedback and then
> >> publish
> >> > and announce this list. Note that it would not be carved in stone and
> we
> >> > will be able to change it at any time if needed.
> >> >
> >> > 1) API
> >> > 1.1) API compatibility *MUST* be maintained between minor releases. Do
> >> not
> >> > remove existing methods or change their signatures, deprecate them
> >> instead
> >> > 1.2) Default behaviour "SHOULD NOT* be changed between minor releases,
> >> > unless absolutely needed. If change is made, it *MUST* be described in
> >> > "Migration Guide"
> >> > 1.3) New operation *MUST* be well-documented in code (javadoc,
> >> dotnetdoc):
> >> > documentation must contain method's purpose, description of parameters
> >> and
> >> > how their values affect the outcome, description of return value and
> >> it's
> >> > default, behavior in negative cases, interaction with other operations
> >> and
> >> > components
> >> > 1.4) API parity between Java and .NET platforms *SHOULD* be maintained
> >> when
> >> > operation makes sense on both platforms. If method cannot be
> >> implemented in
> >> > a platform immediately, new JIRA ticket *MUST* be created and linked
> to
> >> > current ticket
> >> > 1.5) API parity between thin clients (Java, .NET) *SHOULD* be
> maintained
> >> > when operation makes sense on several clients. If method cannot be
> >> > implemented in a client immediately, new JIRA ticket *MUST* be created
> >> and
> >> > linked to current ticket
> >> > 1.6) All exceptions thrown to a user **SHOULD** have explanation how
> to
> >> > resolve, workaround or debug an error
> >> >
> >> > 2) Compatibility
> >> > 2.1) Persistence backward compatibility *MUST* be maintained between
> >> minor
> >> > releases. It should be possible to start newer version on data files
> >> > created by the previous version
> >> > 2.2) Thin client forward and backward compatibility *SHOULD* be
> >> maintained
> >> > between two consecutive minor releases. If compatibility cannot be
> >> > maintained it *MUST* be described in "Migration Guide"
> >> > 2.3) JDBC and ODBC forward and backward compatibility *SHOULD* be
> >> > maintained between two consecutive minor releases. If compatibility
> >> cannot
> >> > be maintained it *MUST* be described in "Migration Guide"
> >> >
> >> > 3) Tests
> >> > 3.1) New functionality *MUST* be covered with unit tests for both
> >> positive
> >> > and negative use cases
> >> > 3.2) All test suites *MUST* be run before merge to master..There
> *MUST*
> >> be
> >> > no new test failures

Re: Ticket review checklist

[Vladimir Ozerov]

Igniters,

I created review checklist on WIKI [1] and also fixed related pages (e.g.
"How To Contribute"). Please let me know if you have any comments before I
go with public announce.

Vladimir.

[1] https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist

On Thu, May 10, 2018 at 5:10 PM, Vladimir Ozerov 
wrote:

> Ilya,
>
> We define that exception messages *SHOULD* have clear explanation on what
> is wrong. *SHOULD* mean that the rule should be followed unless there is a
> reason not to follow. In your case you refer to some unexpected behavior.
> I.e. an exceptional situation developer is not aware of. In this case for
> sure we cannot force contributor to explain what is wrong, because, well,
> we don't know. This is why we relaxed the rule from *MUST* to *SHOULD*.
>
> On Thu, May 10, 2018 at 3:50 PM, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com> wrote:
>
>> I don't think I quite understand how exception explanations should work.
>>
>> Imagine we have the following exception:
>>
>> // At least RuntimeException can be thrown by the code above when
>> GridCacheContext is cleaned and there is
>> // an attempt to use cleaned resources.
>> U.error(log, "Unexpected exception during cache update", e);
>>
>> I mean, we genuinely don't know what happened here.
>>
>> Under new rules, what kind of "workaround" would that exception suggest?
>> "Try turning it off and then back on"?
>> What explanation how to resolve this exception can we offer? "Please write
>> to d...@apache.ignite.org or to Apache JIRA, and then wait for a release
>> with fix?"
>>
>> I'm really confused how we can implement 1.6 and 1.7 when dealing with
>> messy real-world code.
>>
>> Regards,
>>
>>
>> --
>> Ilya Kasnacheev
>>
>> 2018-05-10 11:39 GMT+03:00 Vladimir Ozerov :
>>
>> > Andrey, Anton, Alex
>> >
>> > Agree, *SHOULD* is more appropriate here.
>> >
>> > Please see latest version below. Does anyone want to add or change
>> > something? Let's wait for several days for more feedback and then
>> publish
>> > and announce this list. Note that it would not be carved in stone and we
>> > will be able to change it at any time if needed.
>> >
>> > 1) API
>> > 1.1) API compatibility *MUST* be maintained between minor releases. Do
>> not
>> > remove existing methods or change their signatures, deprecate them
>> instead
>> > 1.2) Default behaviour "SHOULD NOT* be changed between minor releases,
>> > unless absolutely needed. If change is made, it *MUST* be described in
>> > "Migration Guide"
>> > 1.3) New operation *MUST* be well-documented in code (javadoc,
>> dotnetdoc):
>> > documentation must contain method's purpose, description of parameters
>> and
>> > how their values affect the outcome, description of return value and
>> it's
>> > default, behavior in negative cases, interaction with other operations
>> and
>> > components
>> > 1.4) API parity between Java and .NET platforms *SHOULD* be maintained
>> when
>> > operation makes sense on both platforms. If method cannot be
>> implemented in
>> > a platform immediately, new JIRA ticket *MUST* be created and linked to
>> > current ticket
>> > 1.5) API parity between thin clients (Java, .NET) *SHOULD* be maintained
>> > when operation makes sense on several clients. If method cannot be
>> > implemented in a client immediately, new JIRA ticket *MUST* be created
>> and
>> > linked to current ticket
>> > 1.6) All exceptions thrown to a user **SHOULD** have explanation how to
>> > resolve, workaround or debug an error
>> >
>> > 2) Compatibility
>> > 2.1) Persistence backward compatibility *MUST* be maintained between
>> minor
>> > releases. It should be possible to start newer version on data files
>> > created by the previous version
>> > 2.2) Thin client forward and backward compatibility *SHOULD* be
>> maintained
>> > between two consecutive minor releases. If compatibility cannot be
>> > maintained it *MUST* be described in "Migration Guide"
>> > 2.3) JDBC and ODBC forward and backward compatibility *SHOULD* be
>> > maintained between two consecutive minor releases. If compatibility
>> cannot
>> > be maintained it *MUST* be described in "Migration Guide"
>> >
>> > 3) Tests
>> > 3.1) New functionality *MUST* be covered with unit tests for both
>> positive
>> > and negative use cases
>> > 3.2) All test suites *MUST* be run before merge to master..There *MUST*
>> be
>> > no new test failures
>> >
>> > 4) Code style *MUST* be followed as per Ignite's Coding Guidelines
>> >
>> > Vladimir.
>> >
>> >
>> > On Tue, May 8, 2018 at 1:05 PM, Andrey Kuznetsov 
>> > wrote:
>> >
>> > > Anton,
>> > >
>> > > I agree, *MUST* for exception reasons and *SHOULD* for ways of
>> resolution
>> > > sound clearer.
>> > >
>> > > 2018-05-08 12:56 GMT+03:00 Anton Vinogradov :
>> > >
>> > > > Andrey,
>> > > >
>> > > > How about
>> > > > 1.6) All exceptions thrown to a user *MUST* have explanation of
>> > > workaround
>> > > > and 

[jira] [Created] (IGNITE-8578) .Net Add support baseline auto-adjust parameters (definition, run-time change)

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-8578:
-

 Summary: .Net Add support baseline auto-adjust parameters 
(definition, run-time change)
 Key: IGNITE-8578
 URL: https://issues.apache.org/jira/browse/IGNITE-8578
 Project: Ignite
  Issue Type: New Feature
Reporter: Eduard Shangareev
 Fix For: 2.6


We would introduce at IGNITE-8571 new parameters. 

We need their support in .Net side.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8577) Add MIGRATION_GUIDE file

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-8577:
---

 Summary: Add MIGRATION_GUIDE file
 Key: IGNITE-8577
 URL: https://issues.apache.org/jira/browse/IGNITE-8577
 Project: Ignite
  Issue Type: Task
  Components: general
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.6


We are going to log all important changes in public API (deprecations, better 
APIs, changes to default behavior) in separate document, called 
"MIGRATION_GUIDE". 
Need to create it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: How to turn debug log on in Intellij Idea console for ignite core module?

[Maxim Muzafarov]

Hello, Ray!

I usually update this one configuration file for running test in DEBUG mode:
ignite\modules\core\src\test\config\log4j-test.xml

I've uncommented line for DEBUG only specific package, because debug whole
module produces too much output. e.g.:





Is it what are you looking for?

ср, 23 мая 2018 г. в 16:08, Ray :

> I tried change .level=INFO to FINE in config/java.util.logging.properties
> file and disable quite mode using -DIGNITE_QUIET=false, but it still didn't
> work and there's no DEBUG or TRACE level log in the console.
> Please advice me how to turn debug log on in Intellij Idea console for
> ignite core module.
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

[jira] [Created] (IGNITE-8576) Change Baseline auto-adjust parameters via SQL

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-8576:
-

 Summary: Change Baseline auto-adjust parameters via SQL
 Key: IGNITE-8576
 URL: https://issues.apache.org/jira/browse/IGNITE-8576
 Project: Ignite
  Issue Type: New Feature
Reporter: Eduard Shangareev
 Fix For: 2.6


We would introduce at IGNITE-8571 new parameters. 

We need to have option change them via SQL.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #4052: IGNITE-5954 Remove obsolete near cache value from...

[voipp]

GitHub user voipp opened a pull request:

https://github.com/apache/ignite/pull/4052

IGNITE-5954 Remove obsolete near cache value from primary\backup node.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/voipp/ignite IGNITE-5954

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4052.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4052


commit 4e6cd513856d460b65d91f5eee05ad3bd6269277
Author: voipp 
Date:   2018-05-23T13:14:51Z

IGNITE-5954 Remove obsolete near cache value from primary\backup node.




---

[jira] [Created] (IGNITE-8575) Change Baseline auto-adjust parameters via console.sh

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-8575:
-

 Summary: Change Baseline auto-adjust parameters via console.sh
 Key: IGNITE-8575
 URL: https://issues.apache.org/jira/browse/IGNITE-8575
 Project: Ignite
  Issue Type: New Feature
Reporter: Eduard Shangareev
 Fix For: 2.6


We would introduce at IGNITE-8571 new parameters. 
We need to have option change them via JMX.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8574) Change Baseline auto-adjust parameters via JMX

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-8574:
-

 Summary: Change Baseline auto-adjust parameters via JMX
 Key: IGNITE-8574
 URL: https://issues.apache.org/jira/browse/IGNITE-8574
 Project: Ignite
  Issue Type: New Feature
Reporter: Eduard Shangareev
 Fix For: 2.6


We would introduce at IGNITE-8571 new parameters. 
We need to have option change them via JMX.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Fwd: [CONF] Apache Ignite > How to Contribute

[Dmitry Pavlov]

Hi Igniters,

Was it ever discussed we stop to require TC to be passed with PR?

I insist we keep this sentence here:

   - Any change that touches code or test, whether reviewed or not, must
   have full TeamCity CI  test suite pass.


Sincerely,
Dmitriy Pavlov

-- Forwarded message -
From: Vladimir Ozerov (Confluence) 
Date: ср, 23 мая 2018 г. в 16:10
Subject: [CONF] Apache Ignite > How to Contribute
To: 


There's *1 new edit* on this page

[image: page-icon.png]

How
to Contribute

[image: avatar_9a795451037091d2a0feba74463c9e49.png]
Vladimir Ozerov edited this page
Here's what changed:

...

   - Ignite employs both Review-Then-Commit (RTC) process for most of the
   components and Commit-Then-Review (CTR) for few ones.
   - Any change that touches code or test, whether reviewed or not, must
   have full TeamCity CI  test suite pass.
   - As a guideline, trivial changes, like updates to documentation or
   tests, etc. should not need a review prior to committing, and often can be
   made directly in the master branch.Please consult to Review Checklist
   
   to understand how tickets are reviewed and what rules to follow.


Info
title Master Branch
 Ignite "master" branch should always be *release-ready*. Please avoid any
commits or merges to the "master" branch unless the whole TeamCity CI
 suite has passed.

...
Info
title Optional: Tips to pass review quickly

Ask commiter to review changes directly.


Check affected files git history to find person most likely able to review
changes.

In case it's hard to determine who's able to review by git history use
maintainers list presented above.


Add "review request" comment to the Jira Issue starting with a commiter
username.

for example: "[~avinogradov], Please review my changes."


Commiter will gain notification and review your changes and/or help to find
another commiter to do this.
Reviewing a Ticket

   - Make sure that your patch satisfies Review Checklist
   
   rules.
   - Each comment should be started with [~username] to guarantee proper
   notification.
   - Commiter should add comment like "Changes accepted and ready to be
   merged." once review successfully finished.
   - If the commiter/contributor has proposals, it is recommended to add a
   comment in the ticket in addition to PR / CR comments referring proposals
   added. This helps other committers to identify that fix has something to
   improve.

...
Go to page history

View page


Stop watching page

•
Manage notifications

[image: footer-desktop-logo.png]
This message was sent by Atlassian Confluence 6.9.0
[image: footer-mobile-logo.png]

[jira] [Created] (IGNITE-8573) Save baseline auto-adjust parameters to metastore

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-8573:
-

 Summary: Save baseline auto-adjust parameters to metastore
 Key: IGNITE-8573
 URL: https://issues.apache.org/jira/browse/IGNITE-8573
 Project: Ignite
  Issue Type: New Feature
Reporter: Eduard Shangareev
 Fix For: 2.6


We would introduce at IGNITE-8048 new parameters. They should be saved in the 
metastore and restored from it on node/cluster restart.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #4051: IGNITE-8560 checkFirst and checkThrough parameter...

[sergey-chugunov-1985]

GitHub user sergey-chugunov-1985 opened a pull request:

https://github.com/apache/ignite/pull/4051

IGNITE-8560 checkFirst and checkThrough parameters added



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8560

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4051.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4051


commit 4462573638e9b06e5686a0f8ebfce4e9aa8d481b
Author: Sergey Chugunov 
Date:   2018-05-23T12:55:27Z

IGNITE-8560 checkFirst and checkThrough parameters added




---

[GitHub] ignite pull request #4050: Ignite 2.5.1 p3

[sergey-chugunov-1985]

GitHub user sergey-chugunov-1985 opened a pull request:

https://github.com/apache/ignite/pull/4050

Ignite 2.5.1 p3



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-2.5.1-p3

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4050.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4050


commit 1cea80d29f4f1c61ed56ad1261b74ed42611bf64
Author: Ilya Lantukh 
Date:   2018-04-06T10:49:10Z

IGNITE-8018 Optimized GridCacheMapEntry initialValue() - Fixes #3686.

Signed-off-by: Alexey Goncharuk 

commit 37fc72542eb6baa8be8b41aecd08a194102d13c1
Author: Алексей Стельмак 
Date:   2018-04-06T15:28:22Z

IGNITE-8049 Limit the number of operation cycles in B+Tree - Fixes #3769.

Signed-off-by: dpavlov 

(cherry picked from commit e491f10)

commit 76e293654e34c927d6c9efc85a12e736b58a21f2
Author: Eduard Shangareev 
Date:   2018-04-06T16:22:07Z

IGNITE-8114 Add fail recovery mechanism to tracking pages - Fixes #3734.

Signed-off-by: dpavlov 

(cherry picked from commit 0829397)

commit 49f11db727febc83297c7f0f5de9e6f98f0197fa
Author: Alexey Kuznetsov 
Date:   2018-04-09T02:25:50Z

IGNITE-8159 control.sh: Fixed NPE on adding nodes on empty baseline and not 
active cluster.

(cherry picked from commit 834869c)

commit 9ad7be2f51b6dcdcdf43fedb298cd4e240f0adab
Author: Ilya Borisov 
Date:   2018-04-09T13:59:32Z

IGNITE-8155 Web Console: Fixed number pattern warning in browser console.

(cherry picked from commit 5d8f570)

commit 4aa56751906e5db7aad025a7193933fa929aae26
Author: Vasiliy Sisko 
Date:   2018-04-09T15:13:21Z

IGNITE-7940 Visor CMD: Added "cache -slp" and "cache -rlp" commands to show 
and reset lost partitions for specified cache.

(cherry picked from commit abfa0f5)

commit cc04c5c70af1bdbba834f73330e73277b60e23fc
Author: Eduard Shangareev 
Date:   2018-04-09T16:15:50Z

IGNITE-8114 Additional fix for Add fail recovery mechanism to tracking pages

(cherry picked from commit 961fc35)

commit c70d85aa36c702ea0f29bd8668e9bf0790f9ba11
Author: Vasiliy Sisko 
Date:   2018-04-10T08:42:24Z

IGNITE-8126 Web Console: Fixed code generation for cache load.

(cherry picked from commit a0a187b)

commit 8d3755b9c58eef12c5fc9cabfc0b1c05f6db716e
Author: Semyon Boikov 
Date:   2018-04-10T08:37:39Z

IGNITE-7222 Added ZooKeeper discovery SPI

commit b096a463c338565a7661f8a853a257518d872997
Author: Stanislav Lukyanov 
Date:   2018-04-09T11:33:13Z

IGNITE-7904: Changed IgniteUtils::cast not to trim exception chains. This 
closes #3683.

commit 82a4c024fe06ef8c8deeaf762f0cc20a8e481252
Author: Roman Guseinov 
Date:   2018-04-09T11:45:44Z

IGNITE-7944: Disconnected client node tries to send JOB_CANCEL message. 
Applied fix:
- Skip sending message if client disconnected;
- Throw IgniteCheckedException if a client node is disconnected and 
communication client is null.
This closes #3737.

commit c1745de37891026e0a719f0c1d1afe768dfccbf3
Author: Vasiliy Sisko 
Date:   2018-04-10T10:48:52Z

IGNITE-7927 Web Console: Fixed demo for non-collocated joins.

(cherry picked from commit 647620b)

commit b28287d1861fd841a18d0eef95eff309d21a55ef
Author: Alexey Goncharuk 
Date:   2018-04-10T13:22:28Z

IGNITE-8025 Future must fail if assertion error has been thrown in the 
worker thread

commit a832f2b2e5788c45114c3cb5529d7cf53d08f9a6
Author: Andrey Kuznetsov 
Date:   2018-04-10T14:30:12Z

ignite-7772 System workers critical failures handling

Signed-off-by: Andrey Gura 

commit 912433ba9aa113508d05930691b251eccd8f5870
Author: Aleksey Plekhanov 
Date:   2018-04-10T15:54:03Z

IGNITE-8069 IgniteOutOfMemoryException should be handled accordingly to 
provided failure handler

Signed-off-by: Andrey Gura 

commit 99feab6ace66d011b677fd4d57b44fc54da8fd4f
Author: Alexey Goncharuk 
Date:   2018-04-10T17:33:47Z

IGNITE-6430 Complete failing test early

commit 526fb0ee612ef71fde58a1274db35e8205304a63
Author: Dmitriy Sorokin 
Date:   2018-04-10T19:20:41Z

IGNITE-8101 Ability to terminate system workers by JMX for test purposes.

Signed-off-by: Andrey Gura 

commit b4cb2f0df944534743a9d73811e047eda572258c
Author: mcherkasov 
Date:   2018-04-11T00:27:20Z

IGNITE-8153 Nodes fail to connect each other when SSL 

[jira] [Created] (IGNITE-8572) StandaloneWalRecordsIterator may throw NPE if compressed WAL segment is empty

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-8572:
--

 Summary: StandaloneWalRecordsIterator may throw NPE if compressed 
WAL segment is empty
 Key: IGNITE-8572
 URL: https://issues.apache.org/jira/browse/IGNITE-8572
 Project: Ignite
  Issue Type: New Feature
  Components: persistence
Reporter: Ivan Rakov
Assignee: Ivan Rakov
 Fix For: 2.6


In case ZIP archive with WAL segment doesn't contain any ZIP entries, attempt 
to iterate through it with standalone WAL iterator will throw NPE:
{noformat}
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.persistence.file.UnzipFileIO.(UnzipFileIO.java:53)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.initReadHandle(AbstractWalRecordsIterator.java:265)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneWalRecordsIterator.advanceSegment(StandaloneWalRecordsIterator.java:262)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.advance(AbstractWalRecordsIterator.java:155)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneWalRecordsIterator.(StandaloneWalRecordsIterator.java:111)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.iteratorArchiveDirectory(IgniteWalIteratorFactory.java:156)
... 6 more
{noformat}
We should throw excpetion with descriptive error message instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

How to turn debug log on in Intellij Idea console for ignite core module?

[Ray]

I tried change .level=INFO to FINE in config/java.util.logging.properties
file and disable quite mode using -DIGNITE_QUIET=false, but it still didn't
work and there's no DEBUG or TRACE level log in the console.
Please advice me how to turn debug log on in Intellij Idea console for
ignite core module.



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[jira] [Created] (IGNITE-8571) Baseline auto-adjust feature

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-8571:
-

 Summary: Baseline auto-adjust feature
 Key: IGNITE-8571
 URL: https://issues.apache.org/jira/browse/IGNITE-8571
 Project: Ignite
  Issue Type: New Feature
Reporter: Eduard Shangareev


Now we have only one way to change BLAT - manually update it via console.sh or 
API.

We need to add the possibility to change it automatically. Adjust to current 
topology.

So, I propose 3 new parameters which would be responsible to tune this feature.
1. Flag autoAdjustEnabled - true/false. Easy. Manual baseline control or auto 
adjusting baseline.

2. autoAdjustTimeout - time which we would wait after the actual topology 
change. But it would be reset if new discovery event happened. (node join/exit).

3. autoAdjustMaxTimeout - time which we would wait from the first dicovery 
event in the chain. If we achieved it than we would change BLAT right away (no 
matter were another node join/exit happened or not).

We need to change API next way:
1. org.apache.ignite.IgniteCluster

*Add*
isBaselineAutoAdjustEnabled()
setBaselineAutoAdjustEnabled(boolean enabled);
setBaselineAutoAdjustTimeout(long timeoutInMs);
setBaselineAutoAdjustMaxTimeout(long timeoutInMs);

2. org.apache.ignite.configuration.IgniteConfiguration

*Add*
IgniteConfiguration setBaselineAutoAdjustEnabled(boolean enabled);
IgniteConfiguration setBaselineAutoAdjustTimeout(long timeoutInMs);
IgniteConfiguration setBaselineAutoAdjustMaxTimeout(long timeoutInMs);

Also, we need to ensure that all nodes would have the same parameters.
And we should be able to survive coordinator left during parameters changes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #4049: IGNITE-8183 run test 50 times

[dgarus]

GitHub user dgarus opened a pull request:

https://github.com/apache/ignite/pull/4049

IGNITE-8183 run test 50 times



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dgarus/ignite ignite-8183

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4049.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4049


commit 0893dbac3409248c0638f0bd259ac088c279e09c
Author: Garus Denis 
Date:   2018-05-23T12:17:24Z

IGNITE-8183 run test 50 times




---

[GitHub] ignite pull request #3905: IGNITE-5789: if server was restarted, client does...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3905


---

Re: Unreliable checks in tests for string presence in GridStringLogger contents

[Andrey Kuznetsov]

Thanks, Vyacheslav.

Created the issue [1] based on your idea.

[1]  https://issues.apache.org/jira/browse/IGNITE-8570


2018-05-23 12:41 GMT+03:00 Vyacheslav Daradur :

> Hi, Andrey, I have faced this problem too.
>
> I'd suggest introducing new logger for tests instead of extending API
> of *GridStringLogger*.
>
> The new logger should be some kind of *listened*, for example with the
> folowing API:
>
> void addListener(String pattern, CountDownLatch latch);
> void addListener(IgniteInClosure lsnr);
>
> This approach reduces memory load in comparison with *GridStringLogger*.
>
> Just for example these should demonstrate my idea, *listened logger* -
> [1], *listener* - [2]:
>
> [1] https://github.com/apache/ignite/blob/master/modules/
> compatibility/src/test/java/org/apache/ignite/compatibility/testframework/
> junits/logger/ListenedGridTestLog4jLogger.java
> [2] https://github.com/apache/ignite/blob/master/modules/
> compatibility/src/test/java/org/apache/ignite/compatibility/testframework/
> junits/IgniteCompatibilityAbstractTest.java#L304
>
>
>
-- 
Best regards,
  Andrey Kuznetsov.

[jira] [Created] (IGNITE-8570) Create lighter version of GridStringLogger

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-8570:


 Summary: Create lighter version of GridStringLogger
 Key: IGNITE-8570
 URL: https://issues.apache.org/jira/browse/IGNITE-8570
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.4
Reporter: Andrey Kuznetsov
 Fix For: 2.6


Most usages of {{GridStringLogger}} in test assumes the following scenario. 
First, it is set as a logger for some Ignite node. Then, after some activity on 
that node, log content is searched for some predefined strings. 
{{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to store 
log contents, older contents gets dropped on exaustion. Thus, changes that add 
more logging may damage some independent tests that use {{GridStringLogger}}.

The suggestion is to implement and use another test logger conforming to these 
requirements:
* It does not accumulate any logs.
* It allows to set the listener that fires when log message matches certain 
regular expression, {{Matcher}} can be passed to the listener.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Upgrading Ignite to JCache 1.1

[Александр Меньшиков]

Thanks, Slava. You are right.

2018-05-23 14:00 GMT+03:00 Vyacheslav Daradur :

> Hi, Alex!
>
> Please have a look at maven profile named "jcache-tck".
>
> I believe this is what you are looking for.
>
> On Wed, May 23, 2018 at 11:50 AM, Александр Меньшиков
>  wrote:
> > Igniters,
> > I think I can do it. As I see we already have JCache TCK tests in TC.
> > Can I take somewhere settings/script which we are using?
> >
> > 2018-05-23 2:58 GMT+03:00 Dmitriy Setrakyan :
> >
> >> Igniters,
> >>
> >> It will be great if someone in the community would pick this up. The
> amount
> >> of changes are minimal and many of them only have to do with clarifying
> the
> >> documentation. However, removing JSR 107 license confusion in 1.1 would
> be
> >> great for Ignite.
> >>
> >> D.
> >>
> >> On Tue, May 22, 2018 at 3:04 PM, Denis Magda  wrote:
> >>
> >> > Here is a list of all changes:
> >> > https://groups.google.com/forum/#!topic/jsr107/BC1qKqknzKU
> >> >
> >> > The primary argument for the migration is a license. JCache 1.0 is
> >> licensed
> >> > by Oracle that causes legal issues for some of the users. Once we
> upgrade
> >> > to JCache 1.1 the won't longer be a big deal.
> >> >
> >> > However, once we move to 1.1 we need to be sure that we comply with
> the
> >> > updated specification.
> >> >
> >> > --
> >> > Denis
> >> >
> >> > On Tue, May 22, 2018 at 5:20 AM, Dmitry Pavlov  >
> >> > wrote:
> >> >
> >> > > Hi Denis,
> >> > >
> >> > > What was improved in JCache 1.1?
> >> > >
> >> > > Would it be useful for product to change supported spec. version?
> >> > >
> >> > > Sincerely,
> >> > > Dmitriy Pavlov
> >> > >
> >> > > пн, 21 мая 2018 г. в 20:12, Denis Magda :
> >> > >
> >> > > > Igniters,
> >> > > >
> >> > > > Eventually, JCache was relicensed to Apache 2.0 and released 1.1
> >> > version:
> >> > > > https://groups.google.com/forum/#!topic/jsr107/BC1qKqknzKU
> >> > > >
> >> > > > Is there anyone interested in upgrading Ignite to the new version
> for
> >> > the
> >> > > > next release?
> >> > > > https://issues.apache.org/jira/browse/IGNITE-8548
> >> > > >
> >> > > > --
> >> > > > Denis
> >> > > >
> >> > >
> >> >
> >>
>
>
>
> --
> Best Regards, Vyacheslav D.
>

[GitHub] ignite pull request #4048: IGNITE-7165: do not cancel rebalance at client jo...

[Mmuzaf]

GitHub user Mmuzaf opened a pull request:

https://github.com/apache/ignite/pull/4048

 IGNITE-7165: do not cancel rebalance at client join left topology



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Mmuzaf/ignite ignite-7165

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4048.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4048


commit 339e5a6e6e18bb136d988e85dc81f67686bda285
Author: Maxim Muzafarov 
Date:   2018-05-23T11:07:53Z

IGNITE-7165: do not cancel rebalance at client join left topology

commit 4c0b5a3649033bf22f773f753bf96f0ae54e7537
Author: Maxim Muzafarov 
Date:   2018-05-23T11:11:10Z

IGNITE-7165: code styles




---

Re: Ability to check and completely fill transactions on creation

[Anton Vinogradov]

Dmitriy, Yakov

Are there any objections to updated design taking into account the comments
I provided?

пн, 21 мая 2018 г. в 18:49, Anton Vinogradov :

> One more case is to analize and log tx's creators info without tx creation
> restriction.
> This is very important feature on huge system trial period when you may
> want to check who creates tx, tx content and configuration.
> For example you may want to log stacktrace for any tx without meta or with
> empty timeout.
> This will allow you to find a team responsible for that and make sure that
> they will fix their code.
>
> пн, 21 мая 2018 г. в 18:14, Anton Vinogradov :
>
>> Dmitriy,
>>
>> Main idea is to restrict transaction creation in case label or timeout
>> are not set.
>> But there can be variations, for example label should fit some regexp or
>> timeout should be between 30 and 5000 ms.
>>
>> That's not easy to restrict this at user code when you have dozens of
>> libraries written by different people in one system using one ignite
>> cluster.
>> That solution based on idea of TopologyValidator when you have no chances
>> to use cluster in case something wrong with nodes.
>> So, any client should have no chances to create transaction not suitable
>> for this ignite cluster.
>>
>> пн, 21 мая 2018 г. в 17:48, Dmitriy Setrakyan :
>>
>>> Anton,
>>>
>>> The change looks very questionable. We cannot be adding configuration
>>> validators for every piece of Ignite API. What is it you are trying to
>>> achieve?
>>>
>>> D.
>>>
>>> On Mon, May 21, 2018 at 7:22 AM, Anton Vinogradov  wrote:
>>>
>>> > Yakov, thank's for deep check.
>>> >
>>> > >> I think that we should think about some other solution instead of
>>> > altering
>>> > >> event sub-system.
>>> >
>>> > Thank's to your comments now I see that solution is not perfect.
>>> >
>>> > How about to create
>>> >
>>> > interface TransactionsValidator {
>>> >boolean validate(IgniteTransactions tx){
>>> >   ...
>>> >}
>>> > }
>>> >
>>> > and add it's setter to IgniteConfiguration?
>>> >
>>> > icfg.setTransactionsValidator(new CustomTransactionsValidator(...));
>>> >
>>> > In that case we'll gain easy and proper solution allows to check
>>> > transaction configuration before real tx creation.
>>> >
>>> > It will be necessary to add some getters to IgniteTransactions:
>>> > - label()
>>> > - timeout()
>>> > - concurrency() (optional)
>>> > - isolation() (optional)
>>> > - txSize() (optional)
>>> >
>>> > Thoughts?
>>> >
>>> > пн, 21 мая 2018 г. в 16:31, Yakov Zhdanov :
>>> >
>>> > > Ok, then it probably might have been created before this PR. Anyway,
>>> I
>>> > > would not bother too much about pt 3.
>>> > >
>>> > > --Yakov
>>> > >
>>> > > 2018-05-21 16:15 GMT+03:00 Dmitry Pavlov :
>>> > >
>>> > > > Hi Yakov,
>>> > > >
>>> > > > I've checked this code and IgniteCacheTestSuite6 includes
>>> TxLabelTest,
>>> > so
>>> > > > point 3 can be considered as solved.
>>> > > >
>>> > > > Sincerely,
>>> > > > Dmitriy Pavlov
>>> > > >
>>> > > > пн, 21 мая 2018 г. в 16:05, Yakov Zhdanov :
>>> > > >
>>> > > > > Anton, I have objections. Please do not merge unless we agree on
>>> > > details.
>>> > > > >
>>> > > > > 1. You use internal API in public event, i.e. you cannot have
>>> user
>>> > > > > accessing to IgniteInternalTx instance through TxEvent.
>>> > > > > 2. Throwing runtime errors from listener is not documented and I
>>> > doubt
>>> > > if
>>> > > > > it can be fully supported in the pattern you use in TxLabelTest.
>>> > After
>>> > > > > looking at the mentioned test user may think that throwing
>>> runtime
>>> > > error
>>> > > > > when notified on new node join may prohibit new node joining
>>> which is
>>> > > not
>>> > > > > true. Do you have any example in Ignite when throwing exception
>>> from
>>> > > > > listener is valid and documented.
>>> > > > > 3. TxLabelTest is not included into any suite.
>>> > > > > 4. EVT_TX_STARTED - does not seems to be a proper and descriptive
>>> > name
>>> > > > >
>>> > > > > I think that we should think about some other solution instead of
>>> > > > altering
>>> > > > > event sub-system.
>>> > > > >
>>> > > > > Also I want to ask everyone in community to request explicit
>>> approval
>>> > > > from
>>> > > > > community members before changing anything in transactional
>>> logic.
>>> > > > >
>>> > > > > Thanks!
>>> > > > >
>>> > > > > --Yakov
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>

Re: Upgrading Ignite to JCache 1.1

[Vyacheslav Daradur]

Hi, Alex!

Please have a look at maven profile named "jcache-tck".

I believe this is what you are looking for.

On Wed, May 23, 2018 at 11:50 AM, Александр Меньшиков
 wrote:
> Igniters,
> I think I can do it. As I see we already have JCache TCK tests in TC.
> Can I take somewhere settings/script which we are using?
>
> 2018-05-23 2:58 GMT+03:00 Dmitriy Setrakyan :
>
>> Igniters,
>>
>> It will be great if someone in the community would pick this up. The amount
>> of changes are minimal and many of them only have to do with clarifying the
>> documentation. However, removing JSR 107 license confusion in 1.1 would be
>> great for Ignite.
>>
>> D.
>>
>> On Tue, May 22, 2018 at 3:04 PM, Denis Magda  wrote:
>>
>> > Here is a list of all changes:
>> > https://groups.google.com/forum/#!topic/jsr107/BC1qKqknzKU
>> >
>> > The primary argument for the migration is a license. JCache 1.0 is
>> licensed
>> > by Oracle that causes legal issues for some of the users. Once we upgrade
>> > to JCache 1.1 the won't longer be a big deal.
>> >
>> > However, once we move to 1.1 we need to be sure that we comply with the
>> > updated specification.
>> >
>> > --
>> > Denis
>> >
>> > On Tue, May 22, 2018 at 5:20 AM, Dmitry Pavlov 
>> > wrote:
>> >
>> > > Hi Denis,
>> > >
>> > > What was improved in JCache 1.1?
>> > >
>> > > Would it be useful for product to change supported spec. version?
>> > >
>> > > Sincerely,
>> > > Dmitriy Pavlov
>> > >
>> > > пн, 21 мая 2018 г. в 20:12, Denis Magda :
>> > >
>> > > > Igniters,
>> > > >
>> > > > Eventually, JCache was relicensed to Apache 2.0 and released 1.1
>> > version:
>> > > > https://groups.google.com/forum/#!topic/jsr107/BC1qKqknzKU
>> > > >
>> > > > Is there anyone interested in upgrading Ignite to the new version for
>> > the
>> > > > next release?
>> > > > https://issues.apache.org/jira/browse/IGNITE-8548
>> > > >
>> > > > --
>> > > > Denis
>> > > >
>> > >
>> >
>>



-- 
Best Regards, Vyacheslav D.

[jira] [Created] (IGNITE-8569) Web console: incorrect user activities amount on admin page

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8569:
--

 Summary: Web console: incorrect user activities amount on admin 
page
 Key: IGNITE-8569
 URL: https://issues.apache.org/jira/browse/IGNITE-8569
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Alexey Kuznetsov


# create a cluster configuration on basic page, save
# open admin panel and check Cfg counter



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Apache Ignite 2.5 release

[Ivan Rakov]

Igniters,

Unfortunately, previous issue mentioned by Alex G. [1] has broken WAL 
compaction in 2.5.
Follow up fix is already implemented and merged to master [2]. I suggest 
to include it into 2.5 scope; any user attempt to enable compaction on 
2.5 (or use previously compacted WAL segments) will fail with exception 
otherwise.


[1] - https://issues.apache.org/jira/browse/IGNITE-8464
[2] - https://issues.apache.org/jira/browse/IGNITE-8561

Best Regards,
Ivan Rakov

On 17.05.2018 19:28, Denis Magda wrote:

Alexey,

Makes sense to merge.

--
Denis

On Thu, May 17, 2018 at 8:53 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:


Denis,

The issue with page corruption may manifest itself when a node is stopped
during partition eviction (basically, a random chance on topology change
scenario).

The issue with WAL iterator can manifest during historical rebalancing
(this is less likely than the previous issue).

2018-05-17 18:07 GMT+03:00 Denis Magda :


We keep facing the issues that postpone the release over and over again
which seems like a never-ending story.

What are the changes the users come across the 2 latest bugs you've
mentioned (any special conditions)?

What's the overall state of our testing cycles? When would we send the
release for vote if include the abovementioned bugs or move them to the
next release?

--
Denis

On Thu, May 17, 2018 at 7:44 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:


Another issue that may lead to incorrect recovery on node startup is
https://issues.apache.org/jira/browse/IGNITE-8464 which is already in

PA.

I
suggest we also include it to 2.5 given that fix improves stability of

the

persistence layer. Any objections?

2018-05-17 16:55 GMT+03:00 Ivan Rakov :


Andrey, Igniters,

I bumped into this issue while trying to reproduce another:
https://issues.apache.org/jira/browse/IGNITE-8320
I think, this fix worth being cherry-picked into 2.5. Possibility of
AssertionError on persistence level is really undesirable for Ignite

as a

product.

Best Regards,
Ivan Rakov


On 14.05.2018 15:59, Andrey Gura wrote:


Igniters,

we are ready to start process of releasing Apache Ignite 2.5.

So code freeze. No more commits to ignite-2.5 branch.

Thanks!


On Thu, May 10, 2018 at 8:02 PM, Andrey Gura 

wrote:

Igniters,

Almost all issues for Apache Ignite 2.5 release are fixed. Issues

that

are still in Open state will be moved to 2.6 release.

Code freeze for ignite-2.5 branch is planed for tomorrow.

Thanks!

On Tue, May 8, 2018 at 7:09 PM, Andrey Gura 

wrote:

Thanks for fast update, Ivan.

On Tue, May 8, 2018 at 5:59 PM, Ivan Rakov 
wrote:


Igniters,

There is an unpleasant bug in .NET [1]:
Services do not work at all on .NET Core and sometimes on

classic

.NET.

I'm almost done with the fix and I think we should include it

in

2.5.


Users


are complaining [2].


[1] https://issues.apache.org/jira/browse/IGNITE-8434
[2]
http://apache-ignite-users.70518.x6.nabble.com/Re-


Service-Grid-and-net-core-2-td21318.html


On Mon, May 7, 2018 at 6:44 PM, Vladimir Ozerov <
voze...@gridgain.com>
wrote:

Andrey,

I realized that we missed one very important thing - H2

version

upgrade

[1]. This is very important thing because new version contain

optimization
to IN clause processing. All we need is to upgrade H2 vesion

from

1.4.196
to 1.4.197 and re-run tests. Can we target it to 2.5 release?

[1] https://issues.apache.org/jira/browse/IGNITE-4150

On Mon, May 7, 2018 at 6:07 PM, Andrey Gura <

ag...@apache.org

wrote:

Ivan,

ok, targeted to 2.5. Thanks!

On Mon, May 7, 2018 at 5:24 PM, Dmitry Pavlov <


dpavlov@gmail.com>

wrote:

Thank you, Andrey,

I saw 1 more proposal in separate topic
http://apache-ignite-developers.2346864.n4.nabble.


com/RE-Hi-can-we-squeeze-this-

into-2-5-https-issues-apache-

org-jira-browse-IGNITE-8439-td30161.html


and 1 proposal here related to ML:
http://apache-ignite-developers.2346864.n4.nabble.


com/Apache-Ignite-2-5-release-td28927i20.html#a30155


but here Yuriy Babak probably should share his opinion.

Sincerely,
Dmitriy Pavlov

пн, 7 мая 2018 г. в 17:09, Andrey Gura 

[GitHub] ignite pull request #4045: IGNITE-8561 in SingleSegmentLogicalRecordsIterato...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/4045


---

Re: Upgrading Ignite to JCache 1.1

[Александр Меньшиков]

Igniters,
I think I can do it. As I see we already have JCache TCK tests in TC.
Can I take somewhere settings/script which we are using?

2018-05-23 2:58 GMT+03:00 Dmitriy Setrakyan :

> Igniters,
>
> It will be great if someone in the community would pick this up. The amount
> of changes are minimal and many of them only have to do with clarifying the
> documentation. However, removing JSR 107 license confusion in 1.1 would be
> great for Ignite.
>
> D.
>
> On Tue, May 22, 2018 at 3:04 PM, Denis Magda  wrote:
>
> > Here is a list of all changes:
> > https://groups.google.com/forum/#!topic/jsr107/BC1qKqknzKU
> >
> > The primary argument for the migration is a license. JCache 1.0 is
> licensed
> > by Oracle that causes legal issues for some of the users. Once we upgrade
> > to JCache 1.1 the won't longer be a big deal.
> >
> > However, once we move to 1.1 we need to be sure that we comply with the
> > updated specification.
> >
> > --
> > Denis
> >
> > On Tue, May 22, 2018 at 5:20 AM, Dmitry Pavlov 
> > wrote:
> >
> > > Hi Denis,
> > >
> > > What was improved in JCache 1.1?
> > >
> > > Would it be useful for product to change supported spec. version?
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > пн, 21 мая 2018 г. в 20:12, Denis Magda :
> > >
> > > > Igniters,
> > > >
> > > > Eventually, JCache was relicensed to Apache 2.0 and released 1.1
> > version:
> > > > https://groups.google.com/forum/#!topic/jsr107/BC1qKqknzKU
> > > >
> > > > Is there anyone interested in upgrading Ignite to the new version for
> > the
> > > > next release?
> > > > https://issues.apache.org/jira/browse/IGNITE-8548
> > > >
> > > > --
> > > > Denis
> > > >
> > >
> >
>

Unreliable checks in tests for string presence in GridStringLogger contents

[Andrey Kuznetsov]

Folks,

While testing my PR on TeamCity I found a floating test failure. Sometimes
we use {{GridStringLogger}} test facility to capture Ignite node logs and
then check whether some marker strings exist in log output. Since logger's
buffer is limited (32K chars by default) unrelated changes that add more
logging can damage a test.

I propose to add some stuff to {{GridStringLogger}} in order to catch
preset marker strings during logging, then we will not depend on buffer
size.

Thoughts?

-- 
Best regards,
  Andrey Kuznetsov.

[GitHub] ignite pull request #4046: IGNITE-8480 Broken Ignite Examples test Support S...

[homich1991]

GitHub user homich1991 opened a pull request:

https://github.com/apache/ignite/pull/4046

IGNITE-8480 Broken Ignite Examples test Support Spring Data 2.0

Fix dependency problem via spring-data 2.0 and spring 4.0

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/homich1991/ignite ignite-8480

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4046.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4046


commit c4ec6211865f9f34489c3818d93ca0da5ec8c9df
Author: Roman_Meerson 
Date:   2018-05-23T07:28:10Z

IGNITE-8480 Broken Ignite Examples test Support Spring Data 2.0




---