Re: DataFrame integration does not support ARRAY type

[Dmitriy Setrakyan]

Would be nice if someone in the community would pick this ticket up.

On Wed, Aug 8, 2018 at 1:19 AM, Nikolay Izhikov  wrote:

> Hello, Valentin.
>
> Yes, this is a bug.
>
> Ticket created - https://issues.apache.org/jira/browse/IGNITE-9229
>
> В Вт, 31/07/2018 в 16:01 -0700, Valentin Kulichenko пишет:
> > Hi Nikolay,
> >
> > Can you please take a look at this thread on SO?
> https://stackoverflow.com/questions/51621280/saving-a-
> spark-dataset-to-apache-ignite-with-array-column-and-savemode-overwrite
> >
> > Looks like org.apache.ignite.spark.impl.QueryUtils#dataType method
> should also support ArrayType as one of the cases. Currently it doesn't and
> throws an exception.
> >
> > Is it a bug?
> >
> > -Val
>

Re: New Contributor - IGNITE-7616

[Dmitriy Pavlov]

Hi David,

Welcome. I believe everyone in the community is happy that new people come
and help.

I've added you to contributor role. You can now assign ticket to yourself.

Sincerely,
Dmitriy Pavlov

P.S. Additional references that should boost your onboarding.

Please subscribe to both dev and user lists:
https://ignite.apache.org/community/resources.html#mail-lists

Get familiar with Ignite development process described here:
https://cwiki.apache.org/confluence/display/IGNITE/Development+Process

Instructions on how to contribute can be found here:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Project setup in Intellij IDEA:
https://cwiki.apache.org/confluence/display/IGNITE/Project+Setup

ср, 8 авг. 2018 г. в 21:02, David Harvey :

> I've be working with ignite for almost a year, but haven't contributed
> anything back yet.
> IGNITE-7616 is annoying me, so I might as well just fix it.  My Jira ID is
> syssoftsol.
>
> Thanks,
> -DH
>

Re: Metrics for MVCC caches

[Dmitriy Setrakyan]

I think we should be updating the IEP with metrics specifications in
parallel.

D.

On Wed, Aug 8, 2018, 05:32 Roman Kondakov 
wrote:

> Hi Ivan!
>
> In my opinion we need to preserve the essence of the metrics: if we
> didn't consider dirty writes as updates before MVCC implementation, we
> also shouldn't count these writes in MVCC metrics implementation too.
> So, I think we need to count only committed entries. But we can count
> this dirty writes as additional metrics.
>
> Also additional metrics concerning MVCC could be:
>
> - Average count of the active transactions per snapshot
>
> - Average quantity of versions per key
>
>
> --
>
> Roman Kondakov
>
>
> On 07.08.2018 17:17, Павлухин Иван wrote:
> > Hi Igniters,
> >
> > I am working on cache metrics support for caches with enabled MVCC. As
> you
> > may know, during MVCC transaction execution entry versions are written to
> > storage right away (without deferring until commit). So, it is not
> obvious
> > for me if we should update writes count right away or defer it until
> > commit. On one hand, MVCC entry version write is not "true" write until
> > commit. On the other hand, it definitely changes the storage. How do we
> > interpret write metrics in Ignite philosophy?
> >
> > Also, it seems that bunch of MVCC specific metrics could be introduced. I
> > would like to collect some thoughts about it. Which such metrics come to
> > your mind?
> >
>
>

[jira] [Created] (IGNITE-9238) Test GridTaskFailoverAffinityRunTest.testNodeRestartClient hangs when coordinator forces client to reconnect on grid startup.

[Pavel Pereslegin (JIRA)]

Pavel Pereslegin created IGNITE-9238:


 Summary: Test 
GridTaskFailoverAffinityRunTest.testNodeRestartClient hangs when coordinator 
forces client to reconnect on grid startup.
 Key: IGNITE-9238
 URL: https://issues.apache.org/jira/browse/IGNITE-9238
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.6
Reporter: Pavel Pereslegin
Assignee: Pavel Pereslegin
 Fix For: 2.7


Example of such hang on TC: 
https://ci.ignite.apache.org/viewLog.html?buildId=1605243=buildResultsDiv=IgniteTests24Java8_ComputeGrid

Log output:
{noformat}
[2018-08-07 12:20:09,804][WARN 
][sys-#12799%internal.GridTaskFailoverAffinityRunTest1%][GridCachePartitionExchangeManager]
 Client node tries to connect but its exchange info is cleaned up from exchange 
history. Consider increasing 'IGNITE_EXCHANGE_HISTORY_SIZE' property or start 
clients in  smaller batches. Current settings and versions: 
[IGNITE_EXCHANGE_HISTORY_SIZE=1000, initVer=AffinityTopologyVersion [topVer=3, 
minorTopVer=0], readyVer=AffinityTopologyVersion [topVer=4, minorTopVer=0]].
[2018-08-07 12:20:09,804][INFO 
][exchange-worker-#12782%internal.GridTaskFailoverAffinityRunTest1%][GridDhtPartitionsExchangeFuture]
 Completed partition exchange [localNode=511d5932-5f22-4919-807d-575c7f61, 
exchange=GridDhtPartitionsExchangeFuture [topVer=AffinityTopologyVersion 
[topVer=3, minorTopVer=0], evt=NODE_JOINED, evtNode=TcpDiscoveryNode 
[id=6b9a7a1d-07bf-4d20-882a-8462ada3, addrs=ArrayList [127.0.0.1], 
sockAddrs=HashSet [/127.0.0.1:47502], discPort=47502, order=3, intOrder=3, 
lastExchangeTime=1533644409739, loc=false, ver=2.7.0#20180807-sha1:e96616f5, 
isClient=false], done=true], topVer=AffinityTopologyVersion [topVer=4, 
minorTopVer=0], durationFromInit=21]
[2018-08-07 12:20:09,806][INFO 
][exchange-worker-#12782%internal.GridTaskFailoverAffinityRunTest1%][time] 
Finished exchange init [topVer=AffinityTopologyVersion [topVer=3, 
minorTopVer=0], crd=true]
[2018-08-07 12:20:09,807][INFO 
][exchange-worker-#12782%internal.GridTaskFailoverAffinityRunTest1%][GridCachePartitionExchangeManager]
 Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
[topVer=4, minorTopVer=0], force=false, evt=NODE_JOINED, 
node=6b9a7a1d-07bf-4d20-882a-8462ada3]
[2018-08-07 12:20:09,811][INFO 
][sys-#12798%internal.GridTaskFailoverAffinityRunTest2%][GridDhtPartitionsExchangeFuture]
 Finish exchange future [startVer=AffinityTopologyVersion [topVer=4, 
minorTopVer=0], resVer=AffinityTopologyVersion [topVer=4, minorTopVer=0], 
err=null]
[2018-08-07 12:20:09,813][INFO 
][sys-#12798%internal.GridTaskFailoverAffinityRunTest2%][GridDhtPartitionsExchangeFuture]
 Completed partition exchange [localNode=a3206c1f-6d57-4fd6-8aa5-e22f3b42, 
exchange=GridDhtPartitionsExchangeFuture [topVer=AffinityTopologyVersion 
[topVer=4, minorTopVer=0], evt=NODE_JOINED, evtNode=TcpDiscoveryNode 
[id=a3206c1f-6d57-4fd6-8aa5-e22f3b42, addrs=ArrayList [127.0.0.1], 
sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4, 
lastExchangeTime=1533644409779, loc=true, ver=2.7.0#20180807-sha1:e96616f5, 
isClient=false], done=true], topVer=AffinityTopologyVersion [topVer=4, 
minorTopVer=0], durationFromInit=41]
[2018-08-07 12:20:09,814][INFO 
][grid-starter-testNodeRestartClient-1][GridTaskFailoverAffinityRunTest1] To 
start Console Management & Monitoring run ignitevisorcmd.{sh|bat}
[2018-08-07 12:20:09,815][INFO 
][grid-starter-testNodeRestartClient-1][GridTaskFailoverAffinityRunTest1] 
[2018-08-07 12:20:09,815][INFO 
][grid-starter-testNodeRestartClient-1][GridTaskFailoverAffinityRunTest1] 

>>> +---+
>>> Ignite ver. 
>>> 2.7.0-SNAPSHOT#20180807-sha1:e96616f580930f267eab44f75d410fa29a876bcb
>>> +---+
>>> OS name: Linux 4.4.0-128-generic amd64
>>> CPU(s): 5
>>> Heap: 2.0GB
>>> VM name: 20126@8790182f15a5
>>> Ignite instance name: internal.GridTaskFailoverAffinityRunTest1
>>> Local node [ID=511D5932-5F22-4919-807D-575C7F61, order=2, 
>>> clientMode=false]
>>> Local node addresses: [127.0.0.1]
>>> Local ports: TCP:10801 TCP:45821 TCP:47501 

[2018-08-07 12:20:09,816][INFO 
][grid-starter-testNodeRestartClient-1][GridDiscoveryManager] Topology snapshot 
[ver=2, servers=1, clients=1, CPUs=5, offheap=0.1GB, heap=2.0GB]
[2018-08-07 12:20:09,816][INFO 
][grid-starter-testNodeRestartClient-1][GridDiscoveryManager]   ^-- Node 
[id=511D5932-5F22-4919-807D-575C7F61, clusterState=ACTIVE]
[2018-08-07 12:20:09,816][INFO 
][grid-starter-testNodeRestartClient-1][GridDiscoveryManager] Data Regions 
Configured:
[2018-08-07 12:20:09,816][INFO 
][exchange-worker-#12789%internal.GridTaskFailoverAffinityRunTest2%][GridCachePartitionExchangeManager]
 Rebalancing scheduled [order=[ignite-sys-cache, 

New Contributor - IGNITE-7616

[David Harvey]

I've be working with ignite for almost a year, but haven't contributed
anything back yet.
IGNITE-7616 is annoying me, so I might as well just fix it.  My Jira ID is
syssoftsol.

Thanks,
-DH

Re: [MTCGA]: new failures in builds [1570331] needs to be handled

[Dmitriy Pavlov]

This change will trigger master every time if free agent percent >50%
longer than 10 minutes. And likelihood that was just one commit in each
runall is increased. But it is not 100% because several commit may be done
while TC was loaded.

Contributed change is not bisect based on git revisions,- I hope this
change will be also contributed some day.

About this failure, could you please contact author directly or using dev.
list with ask to contribute fix?

ср, 8 авг. 2018 г. в 18:38, Maxim Muzafarov :

> Dmitry,
>
> Good news.
> How can I trigger build\MTCGA.Bot to find the problem commit?
>
> As for this case I've already found commit who caused the test to fall.
> I don't know how to fix this problem. Probably, we slould conslut with
> author to find out the right case.
>
> On Wed, 8 Aug 2018 at 18:29 Dmitriy Pavlov  wrote:
>
> > Ok, let's fill priority and version for new failures.
> >
> > About locating changes, which break particular build:
> >
> > Thanks to Pavel Pereslegin for his recent contribution to MTCGA.Bot.
> Patch
> > allows to adaptively trigger 'run all' in case there are enought of free
> > agents. So it will be easier to locate particular commit.
> >
> > ср, 8 авг. 2018 г. в 17:42, Dmitriy Setrakyan :
> >
> > > Dmitriy, yes, if you set it as blocker and assign it to the next
> release,
> > > the likelihood of someone looking at it before the release will
> increase.
> > > We should follow this practice for all new test failures.
> > >
> > > Moreover, if someone's change caused a new test failure, then we should
> > try
> > > to contact that person on the dev list and bring it to his/her
> attention.
> > >
> > > D.
> > >
> > > On Wed, Aug 8, 2018 at 7:25 AM, Dmitriy Pavlov 
> > > wrote:
> > >
> > > > Hi Dmitriy,
> > > >
> > > > Would it increase likelihood that somebody will pick up this ticket
> if
> > we
> > > > will set blocker priority?
> > > >
> > > > If it would increase I totally agree. IMO, JIRA priorities do not
> have
> > > much
> > > > effect on community members, do it?
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > вт, 7 авг. 2018 г. в 14:00, Dmitriy Setrakyan  >:
> > > >
> > > > > Maxim, if it is a new failure, why is it filed as Minor and is not
> > > > assigned
> > > > > to any release? I would suggest that any new failure should be
> filed
> > > as a
> > > > > Blocker and assigned to the next release.
> > > > >
> > > > > D.
> > > > >
> > > > > On Tue, Aug 7, 2018 at 12:55 AM, Maxim Muzafarov <
> maxmu...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > Seems this is a new failures due to last changes.
> > > > > > I've created new issue [1].
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9202
> > > > > >
> > > > > > On Fri, 3 Aug 2018 at 20:57  wrote:
> > > > > >
> > > > > > > Hi Ignite Developer,
> > > > > > >
> > > > > > > I am MTCGA.Bot, and I've detected some issue on TeamCity to be
> > > > > addressed.
> > > > > > > I hope you can help.
> > > > > > >
> > > > > > >  *New test failure in master
> > > > > > > ExamplesTest.TestRemoteNodes(BinaryModeExample)
> > > > > > > https://ci.ignite.apache.org/project.html?projectId=
> > > > > > IgniteTests24Java8=-3155722801840665529=%
> > > > > > 3Cdefault%3E=testDetails
> > > > > > >
> > > > > > >  *New test failure in master ExamplesTest.TestRemoteNodes(
> > > > > > LinqExample)
> > > > > > > https://ci.ignite.apache.org/project.html?projectId=
> > > > > > IgniteTests24Java8=8941219717117543602=%
> > > > > > 3Cdefault%3E=testDetails
> > > > > > >
> > > > > > >  *New test failure in master ExamplesTest.TestRemoteNodes(
> > > > > > SqlExample)
> > > > > > > https://ci.ignite.apache.org/project.html?projectId=
> > > > > > IgniteTests24Java8=-61288549283153227=%
> > > > > > 3Cdefault%3E=testDetails
> > > > > > >  Changes may led to failure were done by
> > > > > > >  - nsamelchev
> > > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > > 827132=false
> > > > > > >  - biryukovvitaliy92
> > > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > > 827130=false
> > > > > > >  - ppozerov
> > > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > > 827122=false
> > > > > > >  - ppozerov
> > > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > > 827121=false
> > > > > > >  - dmitrievanthony
> > > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > > 827116=false
> > > > > > >  - eshangareev
> > > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > > 827112=false
> > > > > > >  - kaa.dev
> > > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > > 827106=false
> > > > > > >  - alkuznetsov.sb
> > > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > > 827101=false
> > > > > > >  - akuznetsov
> > 

[jira] [Created] (IGNITE-9237) [ML] Random forest optimization

[Yury Babak (JIRA)]

Yury Babak created IGNITE-9237:
--

 Summary: [ML] Random forest optimization
 Key: IGNITE-9237
 URL: https://issues.apache.org/jira/browse/IGNITE-9237
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Reporter: Yury Babak
Assignee: Alexey Platonov
 Fix For: 2.7


We need to implement best split selection by statistics over impurity data and 
share this data for several nodes in several trees while learning process.



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

Re: [MTCGA]: new failures in builds [1570331] needs to be handled

[Maxim Muzafarov]

Dmitry,

Good news.
How can I trigger build\MTCGA.Bot to find the problem commit?

As for this case I've already found commit who caused the test to fall.
I don't know how to fix this problem. Probably, we slould conslut with
author to find out the right case.

On Wed, 8 Aug 2018 at 18:29 Dmitriy Pavlov  wrote:

> Ok, let's fill priority and version for new failures.
>
> About locating changes, which break particular build:
>
> Thanks to Pavel Pereslegin for his recent contribution to MTCGA.Bot. Patch
> allows to adaptively trigger 'run all' in case there are enought of free
> agents. So it will be easier to locate particular commit.
>
> ср, 8 авг. 2018 г. в 17:42, Dmitriy Setrakyan :
>
> > Dmitriy, yes, if you set it as blocker and assign it to the next release,
> > the likelihood of someone looking at it before the release will increase.
> > We should follow this practice for all new test failures.
> >
> > Moreover, if someone's change caused a new test failure, then we should
> try
> > to contact that person on the dev list and bring it to his/her attention.
> >
> > D.
> >
> > On Wed, Aug 8, 2018 at 7:25 AM, Dmitriy Pavlov 
> > wrote:
> >
> > > Hi Dmitriy,
> > >
> > > Would it increase likelihood that somebody will pick up this ticket if
> we
> > > will set blocker priority?
> > >
> > > If it would increase I totally agree. IMO, JIRA priorities do not have
> > much
> > > effect on community members, do it?
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > вт, 7 авг. 2018 г. в 14:00, Dmitriy Setrakyan :
> > >
> > > > Maxim, if it is a new failure, why is it filed as Minor and is not
> > > assigned
> > > > to any release? I would suggest that any new failure should be filed
> > as a
> > > > Blocker and assigned to the next release.
> > > >
> > > > D.
> > > >
> > > > On Tue, Aug 7, 2018 at 12:55 AM, Maxim Muzafarov  >
> > > > wrote:
> > > >
> > > > > Igniters,
> > > > >
> > > > > Seems this is a new failures due to last changes.
> > > > > I've created new issue [1].
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9202
> > > > >
> > > > > On Fri, 3 Aug 2018 at 20:57  wrote:
> > > > >
> > > > > > Hi Ignite Developer,
> > > > > >
> > > > > > I am MTCGA.Bot, and I've detected some issue on TeamCity to be
> > > > addressed.
> > > > > > I hope you can help.
> > > > > >
> > > > > >  *New test failure in master
> > > > > > ExamplesTest.TestRemoteNodes(BinaryModeExample)
> > > > > > https://ci.ignite.apache.org/project.html?projectId=
> > > > > IgniteTests24Java8=-3155722801840665529=%
> > > > > 3Cdefault%3E=testDetails
> > > > > >
> > > > > >  *New test failure in master ExamplesTest.TestRemoteNodes(
> > > > > LinqExample)
> > > > > > https://ci.ignite.apache.org/project.html?projectId=
> > > > > IgniteTests24Java8=8941219717117543602=%
> > > > > 3Cdefault%3E=testDetails
> > > > > >
> > > > > >  *New test failure in master ExamplesTest.TestRemoteNodes(
> > > > > SqlExample)
> > > > > > https://ci.ignite.apache.org/project.html?projectId=
> > > > > IgniteTests24Java8=-61288549283153227=%
> > > > > 3Cdefault%3E=testDetails
> > > > > >  Changes may led to failure were done by
> > > > > >  - nsamelchev
> > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > 827132=false
> > > > > >  - biryukovvitaliy92
> > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > 827130=false
> > > > > >  - ppozerov
> > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > 827122=false
> > > > > >  - ppozerov
> > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > 827121=false
> > > > > >  - dmitrievanthony
> > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > 827116=false
> > > > > >  - eshangareev
> > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > 827112=false
> > > > > >  - kaa.dev
> > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > 827106=false
> > > > > >  - alkuznetsov.sb
> > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > 827101=false
> > > > > >  - akuznetsov
> > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > 827091=false
> > > > > >  - akuznetsov
> > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > 827089=false
> > > > > >  - dmitriyff
> > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > 827084=false
> > > > > >  - ppozerov
> > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > 827066=false
> > > > > >  - vsisko
> > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > 827036=false
> > > > > >  - akuznetsov
> > > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > > 827034=false
> > > > > >  - verbalab
> > > > > > 

Re: SSLParameters for SslContextFactory

[Michael Cherkasov]

Hi all,

Looks like no one has objections about the API I want to introduce.
Could someone please review and push my patch?

Thanks,
Mike.

вт, 31 июл. 2018 г. в 13:02, Mikhail Cherkasov :

> > I have commented your change: setProtocols is still redundant since we
> have protocol in sslContextFactory.
>
> it's not the same, the protocol field allows to set only one particular
> protocol, while protocols allow you to set several different versions, for
> example with protocols you can set:
> TLSv1.1 and TLSv1.2, but exclude TLSv1.0.
>
> > there is a caveat with ciphers list: by default SSL will fail if you ever
> list a cipher there that is not present in current JVM
>
> these are options for subtle SSL configuration, so it requires some
> understanding what you do.
>
> On Mon, Jul 30, 2018 at 6:54 PM Ilya Kasnacheev  >
> wrote:
>
> > Hello!
> >
> > Thank you! I have commented your change: setProtocols is still redundant
> > since we have protocol in sslContextFactory.
> >
> > BTW, there is a caveat with ciphers list: by default SSL will fail if you
> > ever list a cipher there that is not present in current JVM, even if the
> > rest of them are present and can be used. Thus the configuration becomes
> > fragile. However I don't think it's our job to take care of that.
> >
> > Regards,
> >
> > --
> > Ilya Kasnacheev
> >
> > 2018-07-30 18:12 GMT+03:00 Michael Cherkasov <
> michael.cherka...@gmail.com
> > >:
> >
> > > Hi all,
> > >
> > > as was suggested, I removed all mention about SSLParameters and
> replaced
> > it
> > > with a simple String[].
> > > I added configurations for protocols and cipher suites.
> > >
> > > Please, review .
> > >
> > > Thanks,
> > > Mike.
> > >
> > >
> > >
> > > 2018-07-30 13:58 GMT+03:00 Vladimir Ozerov :
> > >
> > > > Agree. It is much easier for user to set a collection of strings
> > > > (especially from Spring), rather than construct some complex Java 8
> > > object.
> > > > Also we need to remember that this feature should be propagated to
> all
> > > thin
> > > > clients and .NET integration. String getter/setter is only way to
> > > maintain
> > > > API consistency across various platforms.
> > > >
> > > > On Thu, Jul 26, 2018 at 9:16 PM Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hello!
> > > > >
> > > > > I really dislike the fact that SSLParameters has 6 setter methods,
> > and
> > > we
> > > > > only support one of them, when two more clash with SSL settings
> which
> > > are
> > > > > set elsewhere.
> > > > >
> > > > > I.e. what happens if I pass SSLParameters with
> > > setAlgorithmConstraints()
> > > > or
> > > > > setProtocols() called on them?
> > > > >
> > > > > Is it possible that we will just have an array of allowed ciphers
> in
> > > > > configuration?
> > > > >
> > > > > Regards,
> > > > >
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > > 2018-07-26 20:16 GMT+03:00 Michael Cherkasov <
> > > > michael.cherka...@gmail.com
> > > > > >:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I want to add SSLParameters for SslContextFactory.
> > > > > >
> > > > > > Right now there's no way to specify a particular set of cipher
> > suites
> > > > > that
> > > > > > you want to use.
> > > > > > there's even old request to add this functionality:
> > > > > > https://issues.apache.org/jira/browse/IGNITE-6167
> > > > > > even with current API you can achieve this, but this requires a
> lot
> > > of
> > > > > > boilerplate code, to avoid this I added SSLParameters, that would
> > be
> > > > > > applied to all SSL connections, please review my pull request:
> > > > > > https://github.com/apache/ignite/pull/4440
> > > > > >
> > > > > > I think this patch covers 6167, so I want to push it in context
> of
> > > this
> > > > > > ticket.
> > > > > >
> > > > > > Thanks,
> > > > > > Mike.
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Thanks,
> Mikhail.
>

Re: Pessimistic Mode and Transactions and 2PC

[John Wilson]

No they are not. I just want to understand.

On Wednesday, August 8, 2018, Dmitriy Pavlov  wrote:

> Hi John,
>
> Are these questions related to some contribution?
>
> Sincerely,
> Dmitriy Pavlov
>
> ср, 8 авг. 2018 г. в 3:18, John Wilson :
>
> > Hi,
> >
> > Assume the following:
> >
> >
> >- I have a transaction coordinator and two primary nodes with 0 backup
> >nodes.
> >- Persistence store is enabled.
> >- I'm running a transaction in pessimistic mode with serializable
> >isolation.
> >
> > I have these questions:
> >
> >1. What exactly happens during the prepare phase? Only acquiring locks
> >on the two primary nodes? Or do the primary nodes themselves, in
> > addition
> >to acquiring locks, write to their respective WAL a TxRecord with a
> > "begin
> >prepare" info?
> >2. Assume locks have been acquired successfully, would the nodes then
> >write a "prepared" TxRecord to WAL before returning a "Yes" vote to
> >coordinator?
> >3. When the coordinator sends a commit message, would each node write
> >the key-values to the DataRecord and a commit to the TxRecord before
> >returning to coordinator?
> >
> >
> > Overall, I'm trying to understand what happens exactly during prepare and
> > commit phases and when the key-values involved in the transaction are
> > actually written; as well as the exact updates that are written to the
> WAL
> > files in each phase.
> >
> > appreciate your response.
> >
> > Thanks,
> >
>

Re: [MTCGA]: new failures in builds [1570331] needs to be handled

[Dmitriy Pavlov]

Ok, let's fill priority and version for new failures.

About locating changes, which break particular build:

Thanks to Pavel Pereslegin for his recent contribution to MTCGA.Bot. Patch
allows to adaptively trigger 'run all' in case there are enought of free
agents. So it will be easier to locate particular commit.

ср, 8 авг. 2018 г. в 17:42, Dmitriy Setrakyan :

> Dmitriy, yes, if you set it as blocker and assign it to the next release,
> the likelihood of someone looking at it before the release will increase.
> We should follow this practice for all new test failures.
>
> Moreover, if someone's change caused a new test failure, then we should try
> to contact that person on the dev list and bring it to his/her attention.
>
> D.
>
> On Wed, Aug 8, 2018 at 7:25 AM, Dmitriy Pavlov 
> wrote:
>
> > Hi Dmitriy,
> >
> > Would it increase likelihood that somebody will pick up this ticket if we
> > will set blocker priority?
> >
> > If it would increase I totally agree. IMO, JIRA priorities do not have
> much
> > effect on community members, do it?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > вт, 7 авг. 2018 г. в 14:00, Dmitriy Setrakyan :
> >
> > > Maxim, if it is a new failure, why is it filed as Minor and is not
> > assigned
> > > to any release? I would suggest that any new failure should be filed
> as a
> > > Blocker and assigned to the next release.
> > >
> > > D.
> > >
> > > On Tue, Aug 7, 2018 at 12:55 AM, Maxim Muzafarov 
> > > wrote:
> > >
> > > > Igniters,
> > > >
> > > > Seems this is a new failures due to last changes.
> > > > I've created new issue [1].
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-9202
> > > >
> > > > On Fri, 3 Aug 2018 at 20:57  wrote:
> > > >
> > > > > Hi Ignite Developer,
> > > > >
> > > > > I am MTCGA.Bot, and I've detected some issue on TeamCity to be
> > > addressed.
> > > > > I hope you can help.
> > > > >
> > > > >  *New test failure in master
> > > > > ExamplesTest.TestRemoteNodes(BinaryModeExample)
> > > > > https://ci.ignite.apache.org/project.html?projectId=
> > > > IgniteTests24Java8=-3155722801840665529=%
> > > > 3Cdefault%3E=testDetails
> > > > >
> > > > >  *New test failure in master ExamplesTest.TestRemoteNodes(
> > > > LinqExample)
> > > > > https://ci.ignite.apache.org/project.html?projectId=
> > > > IgniteTests24Java8=8941219717117543602=%
> > > > 3Cdefault%3E=testDetails
> > > > >
> > > > >  *New test failure in master ExamplesTest.TestRemoteNodes(
> > > > SqlExample)
> > > > > https://ci.ignite.apache.org/project.html?projectId=
> > > > IgniteTests24Java8=-61288549283153227=%
> > > > 3Cdefault%3E=testDetails
> > > > >  Changes may led to failure were done by
> > > > >  - nsamelchev
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827132=false
> > > > >  - biryukovvitaliy92
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827130=false
> > > > >  - ppozerov
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827122=false
> > > > >  - ppozerov
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827121=false
> > > > >  - dmitrievanthony
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827116=false
> > > > >  - eshangareev
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827112=false
> > > > >  - kaa.dev
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827106=false
> > > > >  - alkuznetsov.sb
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827101=false
> > > > >  - akuznetsov
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827091=false
> > > > >  - akuznetsov
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827089=false
> > > > >  - dmitriyff
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827084=false
> > > > >  - ppozerov
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827066=false
> > > > >  - vsisko
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827036=false
> > > > >  - akuznetsov
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827034=false
> > > > >  - verbalab
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827032=false
> > > > >  - verbalab
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827030=false
> > > > >  - verbalab
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827028=false
> > > > >  - verbalab
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827027=false
> > > > >  - verbalab
> > > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > > 827025=false
> > > > >  - verbalab
> > > > > 

Re: Data regions on client nodes

[Dmitriy Pavlov]

I used to think that OS allocates pages not immediately after call to
allocate(), but only during first touch of each page.

I'm not sure every OS provides guaranee that 'allocated' memory will never
cause OOME. Please correct me if I'm wrong.

ср, 8 авг. 2018 г. в 17:38, Dmitriy Setrakyan :

> Alexey,
>
> I am not sure I understand. If cache creation proceeds, but memory region
> was not allocated, how can the cache operate?
>
> D.
>
> On Wed, Aug 8, 2018 at 8:05 AM, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > wrote:
>
> > I do not mind making this change, but note that the reason for non-lazy
> > region allocation is the need to gracefully handle OOME errors during
> cache
> > start. When a region is pre-allocated, no OOME can happen.
> >
> > If a region is allocated dynamically, then all errors that happened
> during
> > the node start before should be properly handled (a client node must be
> > stopped, but cache creation should proceed).
> >
> > пт, 27 июл. 2018 г. в 20:04, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com>:
> >
> > > Ticket created: https://issues.apache.org/jira/browse/IGNITE-9113
> > >
> > > -Val
> > >
> > > On Fri, Jul 27, 2018 at 5:59 AM Dmitry Pavlov 
> > > wrote:
> > >
> > > > Maxim, thank you.
> > > >
> > > > If it seems it is technically possible, we can file ticket for this
> > > change.
> > > >
> > > > I find this proposal reasonable, change makes perfectly sense to me.
> > > >
> > > > We can wait Alex G. feedback on this change before starting actual
> > > > implementation. It can take for a while, because he is travelling
> now.
> > > >
> > > > пт, 27 июл. 2018 г. в 14:35, Maxim Muzafarov :
> > > >
> > > > > Guys,
> > > > >
> > > > > I can miss some details, but at the first glance we have everething
> > we
> > > > need
> > > > > to defer
> > > > > region memory allocation if it has no cache groups assignments. And
> > it
> > > > > doesn't matter
> > > > > where it happens on client or server nodes.
> > > > >
> > > > > Currently region memory allocation happens at exchange future init
> > > > method.
> > > > > At the
> > > > > node startup method initCachesOnLocalJoin executes. This method
> > > > resposnible
> > > > > for
> > > > > memory allocation (through initiating cache managers) and it also
> > > starts
> > > > > caches.
> > > > > So, at this point we have all existing caches descriptors and can
> > find
> > > > out
> > > > > which
> > > > > cache matches which region to defer some regions initialization to
> > the
> > > > > moment when
> > > > > newly cache assings to this region (happend at
> onCacheChangeRequest).
> > > > >
> > > > > Please, сorrect me if I'm wrong and missing something.
> > > > >
> > > > >
> > > > >
> > > > > On Wed, 25 Jul 2018 at 19:32 Dmitry Pavlov 
> > > > wrote:
> > > > >
> > > > > > Hi Maxim,
> > > > > >
> > > > > > thank you for stepping in. How do you think, is it possible to
> > check
> > > > > cache
> > > > > > assignment to region at stage of memory allocation?
> > > > > >
> > > > > > Sincerely,
> > > > > > Dmitriy Pavlov
> > > > > >
> > > > > > ср, 25 июл. 2018 г. в 18:22, Maxim Muzafarov  >:
> > > > > >
> > > > > > > Folks,
> > > > > > >
> > > > > > > I've checked memory allocation. It looks like we are allocating
> > > > memory
> > > > > > only
> > > > > > > on the first exchange future init on local join occurs on node.
> > > Also,
> > > > > > seems
> > > > > > > like we are allocating only the first chunk of memory (not the
> > > whole
> > > > > > bunch)
> > > > > > > and it calculates as:
> > > > > > >
> > > > > > > Math.max((maxSize - startSize) / (SEG_CNT - 1), 256L * 1024 *
> > 1024)
> > > > > > >
> > > > > > > But, I'm agree with Val. It's better to allocate memory only
> when
> > > > when
> > > > > > > the first cache assigned to this region.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Also, It seems like we have some problem with user notification
> > > about
> > > > > > > available
> > > > > > > physical resources. For client nodes method requiredOffheap()
> > > returns
> > > > > > > always
> > > > > > > zero [1]. That's why WARN message shown here [2] would be not
> not
> > > > quite
> > > > > > > right
> > > > > > > if we have a lot of client nodes in cluster.
> > > > > > >
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > https://github.com/apache/ignite/blob/master/modules/
> > core/src/main/java/org/apache/ignite/internal/managers/discovery/
> > GridDiscoveryManager.java#L1501
> > > > > > > [2]
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > https://github.com/apache/ignite/blob/master/modules/
> > core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L1489
> > > > > > >
> > > > > > > сб, 21 июл. 2018 г. в 14:15, Dmitriy Setrakyan <
> > > > dsetrak...@apache.org
> > > > > >:
> > > > > > >
> > > > > > > > On Sat, Jul 21, 2018 at 5:22 AM, Valentin Kulichenko <
> > > > > > > > valentin.kuliche...@gmail.com> wrote:
> > > > 

Re: TDE: Upgrade Team City JDK

[Petr Ivanov]

Nikolay,


I’ve updated publicagent03_9091 and tested all current builds for Ignite Tests 
2.4+ project for master branch.
Please test your PR on this agent (select it when starting build) for correct 
java configuration.

If everything is OK — I’ll distribute this Java among all other agents.



> On 31 Jul 2018, at 22:18, Petr Ivanov  wrote:
> 
>> 8u111.
> 
> I’ve started the process of update, will try to accomplish by the end of the 
> week.
> 
> 
>> On 31 Jul 2018, at 21:26, Denis Magda  wrote:
>> 
>> Nikolay,
>> 
>> Do you need 8u111 and later? Or any JDK 8 works for you?
>> 
>> --
>> Denis
>> 
>> On Tue, Jul 31, 2018 at 6:55 AM Nikolay Izhikov  wrote:
>> 
>>> Hello, Petr.
>>> 
 What JDK is required for running this build?
>>> 
>>> 8u111 and later.
>>> 
 I can filter agents with correct JDK for now.
>>> 
>>> Encryption tests are executed by following build plans:
>>> 
>>>   * Basic 1
>>>   * Binary Objects (Simple Mapper Basic)
>>>   * Queries 1
>>>   * Spring
>>> 
>>> В Вт, 31/07/2018 в 16:45 +0300, Petr Ivanov пишет:
 No we cannot do it right now.
 
 What JDK is required for running this build?
 I can filter agents with correct JDK for now.
 
 
 
> On 31 Jul 2018, at 16:35, Nikolay Izhikov  wrote:
> 
> Hello, Igniters.
> 
> I have to up this thread.
> 
> TDE. Phase 1 development is over.
> But, I still can't run TDE tests on Team city [1].
> 
> I think that source of error is [2]
> 
> Can we upgrade Team City JDK?
> 
> [1]
>>> https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=1566703&_focus=446976
> [2] https://bugs.openjdk.java.net/browse/JDK-8149411
> 
> В Ср, 27/06/2018 в 18:50 +0300, Nikolay Izhikov пишет:
>> Hi.
>> 
>>> can we add option enables AES 128
>> 
>> Currently, 128 bit key used [1]
>> 
>> 
>>> I guess we should update environment to meet test requirements
>>> prior putting changes to master.
>> 
>> Yes.
>> 
>> [1]
>>> https://github.com/apache/ignite/pull/4167/files#diff-1088ffe504f1aa300830e1ae9c030de1R80
>> 
>> 
>> В Ср, 27/06/2018 в 18:44 +0300, Dmitry Pavlov пишет:
>>> Hi Nikolay,
>>> 
>>> can we add option enables AES 128 for test mode? This should work
>>> well
>>> without update env.
>>> 
>>> Sincerely,
>>> 
>>> ср, 27 июн. 2018 г. в 18:43, Petr Ivanov :
>>> 
 
 
> On 27 Jun 2018, at 18:06, Nikolay Izhikov 
>>> wrote:
> 
> Hello, Eduard.
> 
>> We should make suites which are restricted by agents to make
>>> as small
 
 as> possible.
> 
> Agree. That means we should enable java cryptography on all
>>> agents.
 
 Isn't it?
> 
>> So, I strictly against adding such test (therefore
>>> restriction) to
 
 these> suites.>
> 
> What is wrong with tests?
 
 Tests in current configuration require specific environment.
 I guess we should update environment to meet test requirements
>>> prior
 putting changes to master.
 
 
> Do you looked at it or something?
> 
> 
> В Ср, 27/06/2018 в 14:24 +0300, Eduard Shangareev пишет:
>> Nikolay, Petr,
>> 
>> We should make suites which are restricted by agents to make
>>> as small as
>> possible.
>> 
>> So, I strictly against adding such test (therefore
>>> restriction) to these
>> suites.
>> 
>> On Wed, Jun 27, 2018 at 11:39 AM, Petr Ivanov <
>>> mr.wei...@gmail.com>
 
 wrote:
>> 
>>> IgniteSpiTestSuite is called from ’SPI’ build type and
>>> I’ve added agent
>>> filter there.
>>> IgniteKernalSelfTestSuite is not found in build types.
>>> 
>>> 
>>> 
 On 27 Jun 2018, at 11:26, Nikolay Izhikov <
>>> nizhi...@apache.org>
 
 wrote:
 
 Well, it's a good question :)
 
 I've added encryption tests in
>>> `IgniteKernalSelfTestSuite` and in
>>> 
>>> `IgniteSpiTestSuite`.
 Not sure, what builds on Team City runs these suites.
 
 В Ср, 27/06/2018 в 11:18 +0300, Petr Ivanov пишет:
> Nikolay,
> 
> 
> What is “core” module?
> 
> 
>> On 27 Jun 2018, at 00:42, Nikolay Izhikov <
>>> nizhi...@apache.org>
 
 wrote:
>> 
>> Hello, Petr.
>> 
>> Thanks a lot!
>> I see success spring encryption tests now [1]
>> 
>> I've added encryption tests to core module also.
>> Can we set same rule for a core module?
>> 
>> [1]
>>> 

Re: [MTCGA]: new failures in builds [1570331] needs to be handled

[Dmitriy Setrakyan]

Dmitriy, yes, if you set it as blocker and assign it to the next release,
the likelihood of someone looking at it before the release will increase.
We should follow this practice for all new test failures.

Moreover, if someone's change caused a new test failure, then we should try
to contact that person on the dev list and bring it to his/her attention.

D.

On Wed, Aug 8, 2018 at 7:25 AM, Dmitriy Pavlov 
wrote:

> Hi Dmitriy,
>
> Would it increase likelihood that somebody will pick up this ticket if we
> will set blocker priority?
>
> If it would increase I totally agree. IMO, JIRA priorities do not have much
> effect on community members, do it?
>
> Sincerely,
> Dmitriy Pavlov
>
> вт, 7 авг. 2018 г. в 14:00, Dmitriy Setrakyan :
>
> > Maxim, if it is a new failure, why is it filed as Minor and is not
> assigned
> > to any release? I would suggest that any new failure should be filed as a
> > Blocker and assigned to the next release.
> >
> > D.
> >
> > On Tue, Aug 7, 2018 at 12:55 AM, Maxim Muzafarov 
> > wrote:
> >
> > > Igniters,
> > >
> > > Seems this is a new failures due to last changes.
> > > I've created new issue [1].
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-9202
> > >
> > > On Fri, 3 Aug 2018 at 20:57  wrote:
> > >
> > > > Hi Ignite Developer,
> > > >
> > > > I am MTCGA.Bot, and I've detected some issue on TeamCity to be
> > addressed.
> > > > I hope you can help.
> > > >
> > > >  *New test failure in master
> > > > ExamplesTest.TestRemoteNodes(BinaryModeExample)
> > > > https://ci.ignite.apache.org/project.html?projectId=
> > > IgniteTests24Java8=-3155722801840665529=%
> > > 3Cdefault%3E=testDetails
> > > >
> > > >  *New test failure in master ExamplesTest.TestRemoteNodes(
> > > LinqExample)
> > > > https://ci.ignite.apache.org/project.html?projectId=
> > > IgniteTests24Java8=8941219717117543602=%
> > > 3Cdefault%3E=testDetails
> > > >
> > > >  *New test failure in master ExamplesTest.TestRemoteNodes(
> > > SqlExample)
> > > > https://ci.ignite.apache.org/project.html?projectId=
> > > IgniteTests24Java8=-61288549283153227=%
> > > 3Cdefault%3E=testDetails
> > > >  Changes may led to failure were done by
> > > >  - nsamelchev
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827132=false
> > > >  - biryukovvitaliy92
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827130=false
> > > >  - ppozerov
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827122=false
> > > >  - ppozerov
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827121=false
> > > >  - dmitrievanthony
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827116=false
> > > >  - eshangareev
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827112=false
> > > >  - kaa.dev
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827106=false
> > > >  - alkuznetsov.sb
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827101=false
> > > >  - akuznetsov
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827091=false
> > > >  - akuznetsov
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827089=false
> > > >  - dmitriyff
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827084=false
> > > >  - ppozerov
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827066=false
> > > >  - vsisko
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827036=false
> > > >  - akuznetsov
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827034=false
> > > >  - verbalab
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827032=false
> > > >  - verbalab
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827030=false
> > > >  - verbalab
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827028=false
> > > >  - verbalab
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827027=false
> > > >  - verbalab
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827025=false
> > > >  - verbalab
> > > > http://ci.ignite.apache.org/viewModification.html?modId=
> > > 827023=false
> > > >
> > > > - If your changes can led to this failure(s), please create
> > issue
> > > > with label MakeTeamCityGreenAgain and assign it to you.
> > > > -- If you have fix, please set ticket to PA state and write
> to
> > > dev
> > > > list fix is ready
> > > > -- For case fix will require some time please mute test and
> set
> > > > label Muted_Test to issue
> > > > - If you know which change caused failure please contact
> change
> > > > author directly
> > > > - If you don't know which 

Re: Session with Weblogic and Ignite

[Ilya Kasnacheev]

Hello!

I think that the comment sums it up nicely. WebLogic seems to add extra
stuff to session ID, which has to be removed.

What is the problem that you have? I suggest responding to userlist (
*u...@ignite.apache.org
* ) since it's the one to discuss end user problems.

Regards,

-- 
Ilya Kasnacheev

2018-08-08 16:45 GMT+03:00 Karim Fadel :

> Dears,
>
>
>
> We are facing a problem with session timeout in weblogic
>
> We are using ignite, spring and spring security and deploy on tomcat and
> weblogic
>
>
>
> and we found something that Ignite has a special handle for sessionId in
> case of WebLogic
>
>
>
> String srvInfo = ctx.getServerInfo();
>
>
>
> // Special case for WebLogic, which appends timestamps to session
>
> // IDs upon session creation (the created session ID looks like:
>
> // pdpTSTcCcG6CVM8BTZWzxjTB1lh3w7zFbYVvwBb4bJGjrBx3TMPl!-
> 508312620!1385045122601).
>
> if (srvInfo != null && srvInfo.contains("WebLogic")) {
>
> sesIdTransformer = new C1() {
>
> @Override public String apply(String s) {
>
> // Find first exclamation mark.
>
> int idx = s.indexOf('!');
>
>
>
> // Return original string if not found.
>
> if (idx < 0 || idx == s.length() - 1)
>
> return s;
>
>
>
> // Find second exclamation mark.
>
> idx = s.indexOf('!', idx + 1);
>
>
>
> // Return original string if not found.
>
> if (idx < 0)
>
> return s;
>
>
>
> // Return the session ID without timestamp.
>
> return s.substring(0, idx);
>
> }
>
> };
>
> }
>
>
>
>
>
> Could you please describe what is the problem in weblogic, that could be
> help us to understand problem that we have.
>
>
> *Best Regards, Karim M.Fadel* | SW Developer | GSS
>
> Esri Northeast Africa | 13 G Ahmed Kamel Street, New Maadi, Cairo, Egypt
>
> M +20 271615995| Extension 2706
>
> *Karim.fadel*@esrinea.com | www.esrinea.com
>
> [image: Description: cid:image001.png@01CDAA34.62617D70]
>
>
>

Re: Data regions on client nodes

[Dmitriy Setrakyan]

Alexey,

I am not sure I understand. If cache creation proceeds, but memory region
was not allocated, how can the cache operate?

D.

On Wed, Aug 8, 2018 at 8:05 AM, Alexey Goncharuk  wrote:

> I do not mind making this change, but note that the reason for non-lazy
> region allocation is the need to gracefully handle OOME errors during cache
> start. When a region is pre-allocated, no OOME can happen.
>
> If a region is allocated dynamically, then all errors that happened during
> the node start before should be properly handled (a client node must be
> stopped, but cache creation should proceed).
>
> пт, 27 июл. 2018 г. в 20:04, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
> > Ticket created: https://issues.apache.org/jira/browse/IGNITE-9113
> >
> > -Val
> >
> > On Fri, Jul 27, 2018 at 5:59 AM Dmitry Pavlov 
> > wrote:
> >
> > > Maxim, thank you.
> > >
> > > If it seems it is technically possible, we can file ticket for this
> > change.
> > >
> > > I find this proposal reasonable, change makes perfectly sense to me.
> > >
> > > We can wait Alex G. feedback on this change before starting actual
> > > implementation. It can take for a while, because he is travelling now.
> > >
> > > пт, 27 июл. 2018 г. в 14:35, Maxim Muzafarov :
> > >
> > > > Guys,
> > > >
> > > > I can miss some details, but at the first glance we have everething
> we
> > > need
> > > > to defer
> > > > region memory allocation if it has no cache groups assignments. And
> it
> > > > doesn't matter
> > > > where it happens on client or server nodes.
> > > >
> > > > Currently region memory allocation happens at exchange future init
> > > method.
> > > > At the
> > > > node startup method initCachesOnLocalJoin executes. This method
> > > resposnible
> > > > for
> > > > memory allocation (through initiating cache managers) and it also
> > starts
> > > > caches.
> > > > So, at this point we have all existing caches descriptors and can
> find
> > > out
> > > > which
> > > > cache matches which region to defer some regions initialization to
> the
> > > > moment when
> > > > newly cache assings to this region (happend at onCacheChangeRequest).
> > > >
> > > > Please, сorrect me if I'm wrong and missing something.
> > > >
> > > >
> > > >
> > > > On Wed, 25 Jul 2018 at 19:32 Dmitry Pavlov 
> > > wrote:
> > > >
> > > > > Hi Maxim,
> > > > >
> > > > > thank you for stepping in. How do you think, is it possible to
> check
> > > > cache
> > > > > assignment to region at stage of memory allocation?
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > >
> > > > > ср, 25 июл. 2018 г. в 18:22, Maxim Muzafarov :
> > > > >
> > > > > > Folks,
> > > > > >
> > > > > > I've checked memory allocation. It looks like we are allocating
> > > memory
> > > > > only
> > > > > > on the first exchange future init on local join occurs on node.
> > Also,
> > > > > seems
> > > > > > like we are allocating only the first chunk of memory (not the
> > whole
> > > > > bunch)
> > > > > > and it calculates as:
> > > > > >
> > > > > > Math.max((maxSize - startSize) / (SEG_CNT - 1), 256L * 1024 *
> 1024)
> > > > > >
> > > > > > But, I'm agree with Val. It's better to allocate memory only when
> > > when
> > > > > > the first cache assigned to this region.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Also, It seems like we have some problem with user notification
> > about
> > > > > > available
> > > > > > physical resources. For client nodes method requiredOffheap()
> > returns
> > > > > > always
> > > > > > zero [1]. That's why WARN message shown here [2] would be not not
> > > quite
> > > > > > right
> > > > > > if we have a lot of client nodes in cluster.
> > > > > >
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/ignite/blob/master/modules/
> core/src/main/java/org/apache/ignite/internal/managers/discovery/
> GridDiscoveryManager.java#L1501
> > > > > > [2]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > https://github.com/apache/ignite/blob/master/modules/
> core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L1489
> > > > > >
> > > > > > сб, 21 июл. 2018 г. в 14:15, Dmitriy Setrakyan <
> > > dsetrak...@apache.org
> > > > >:
> > > > > >
> > > > > > > On Sat, Jul 21, 2018 at 5:22 AM, Valentin Kulichenko <
> > > > > > > valentin.kuliche...@gmail.com> wrote:
> > > > > > >
> > > > > > > > Actually, I would go even further: only allocate a data
> region
> > > on a
> > > > > > node
> > > > > > > > when the first cache assigned to this region is deployed on
> > that
> > > > > node.
> > > > > > > > Because issue is broader than client nodes and local caches.
> > One
> > > > can
> > > > > > have
> > > > > > > > server nodes without any caches as well - running only
> > services,
> > > > for
> > > > > > > > example.
> > > > > > > >
> > > > > > >
> > > > > > > It would be great if this was possible, but to my knowledge,
> > > regions
> > > > > need
> > > > > > > to be allocated on startup.

Session with Weblogic and Ignite

[Karim Fadel]

Dears,

We are facing a problem with session timeout in weblogic
We are using ignite, spring and spring security and deploy on tomcat and 
weblogic

and we found something that Ignite has a special handle for sessionId in case 
of WebLogic

String srvInfo = ctx.getServerInfo();

// Special case for WebLogic, which appends timestamps to session
// IDs upon session creation (the created session ID looks like:
// 
pdpTSTcCcG6CVM8BTZWzxjTB1lh3w7zFbYVvwBb4bJGjrBx3TMPl!-508312620!1385045122601).
if (srvInfo != null && srvInfo.contains("WebLogic")) {
sesIdTransformer = new C1() {
@Override public String apply(String s) {
// Find first exclamation mark.
int idx = s.indexOf('!');

// Return original string if not found.
if (idx < 0 || idx == s.length() - 1)
return s;

// Find second exclamation mark.
idx = s.indexOf('!', idx + 1);

// Return original string if not found.
if (idx < 0)
return s;

// Return the session ID without timestamp.
return s.substring(0, idx);
}
};
}


Could you please describe what is the problem in weblogic, that could be help 
us to understand problem that we have.
Best Regards,
Karim M.Fadel | SW Developer | GSS
Esri Northeast Africa | 13 G Ahmed Kamel Street, New Maadi, Cairo, Egypt
M +20 271615995| Extension 2706
karim.fa...@esrinea.com | 
www.esrinea.com
[Description: cid:image001.png@01CDAA34.62617D70]

[GitHub] ignite pull request #4499: IGNITE-9236 : Removed setting failureDetectionTim...

[ilantukh]

GitHub user ilantukh opened a pull request:

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

IGNITE-9236 : Removed setting failureDetectionTimeout to Integer.MAX_VALUE 
in tests.



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

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

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

https://github.com/apache/ignite/pull/4499.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 #4499


commit 1106650a21386f24cc5b1cc9087883779385a47e
Author: Ilya Lantukh 
Date:   2018-08-08T13:49:42Z

IGNITE-9236 : Removed setting failureDetectionTimeout to Integer.MAX_VALUE 
in tests.




---

[GitHub] ignite pull request #4498: IGNITE-9235: Transitivity violation in GridMergeI...

[andrewmed]

GitHub user andrewmed opened a pull request:

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

IGNITE-9235: Transitivity violation in GridMergeIndex Comparator



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

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

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

https://github.com/apache/ignite/pull/4498.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 #4498


commit 07cbf194d94e41a741dfcaecc74826c0b897c9bf
Author: AMedvedev 
Date:   2018-08-08T13:46:37Z

IGNITE-9235: Transitivity violation in GridMergeIndex Comparator




---

[jira] [Created] (IGNITE-9236) Handshake timeout never completes in some tests (GridCacheReplicatedFailoverSelfTest in particular)

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-9236:


 Summary: Handshake timeout never completes in some tests 
(GridCacheReplicatedFailoverSelfTest in particular)
 Key: IGNITE-9236
 URL: https://issues.apache.org/jira/browse/IGNITE-9236
 Project: Ignite
  Issue Type: Bug
Reporter: Ilya Lantukh
Assignee: Ilya Lantukh


In GridCacheReplicatedFailoverSelfTest one thread tries to establish TCP 
connection and hangs on handshake forever, holding lock on RebalanceFuture:
{code}
[11:51:55] : [Step 3/4] Locked synchronizers:
[11:51:55] : [Step 3/4] 
java.util.concurrent.ThreadPoolExecutor$Worker@5b17b883
[11:51:55] : [Step 3/4] Thread 
[name="sys-#68921%new-node-topology-change-thread-1%", id=77410, 
state=RUNNABLE, blockCnt=3, waitCnt=0]
[11:51:55] : [Step 3/4] at 
sun.nio.ch.FileDispatcherImpl.read0(Native Method)
[11:51:55] : [Step 3/4] at 
sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
[11:51:55] : [Step 3/4] at 
sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
[11:51:55] : [Step 3/4] at sun.nio.ch.IOUtil.read(IOUtil.java:197)
[11:51:55] : [Step 3/4] at 
sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
[11:51:55] : [Step 3/4] - locked java.lang.Object@23aaa756
[11:51:55] : [Step 3/4] at 
o.a.i.spi.communication.tcp.TcpCommunicationSpi.safeTcpHandshake(TcpCommunicationSpi.java:3647)
[11:51:55] : [Step 3/4] at 
o.a.i.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3293)
[11:51:55] : [Step 3/4] at 
o.a.i.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2967)
[11:51:55] : [Step 3/4] at 
o.a.i.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2850)
[11:51:55] : [Step 3/4] at 
o.a.i.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2693)
[11:51:55] : [Step 3/4] at 
o.a.i.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2652)
[11:51:55] : [Step 3/4] at 
o.a.i.i.managers.communication.GridIoManager.send(GridIoManager.java:1643)
[11:51:55] : [Step 3/4] at 
o.a.i.i.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1750)
[11:51:55] : [Step 3/4] at 
o.a.i.i.processors.cache.GridCacheIoManager.sendOrderedMessage(GridCacheIoManager.java:1231)
[11:51:55] : [Step 3/4] at 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.cleanupRemoteContexts(GridDhtPartitionDemander.java:)
[11:51:55] : [Step 3/4] at 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.cancel(GridDhtPartitionDemander.java:1041)
[11:51:55] : [Step 3/4] - locked 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture@7e28f150
[11:51:55] : [Step 3/4] at 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.lambda$null$2(GridDhtPartitionDemander.java:534)
[11:51:55] : [Step 3/4] at 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$$Lambda$41/603501511.run(Unknown
 Source)
[11:51:55] : [Step 3/4] at 
o.a.i.i.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6800)
[11:51:55] : [Step 3/4] at 
o.a.i.i.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
[11:51:55] : [Step 3/4] at 
o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
[11:51:55] : [Step 3/4] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[11:51:55] : [Step 3/4] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[11:51:55] : [Step 3/4] at java.lang.Thread.run(Thread.java:748)
{code}

Because of that, exchange worker hangs forever while trying to acquire that 
lock:
{code}
[11:51:55] : [Step 3/4] Thread 
[name="exchange-worker-#68894%new-node-topology-change-thread-1%", id=77379, 
state=BLOCKED, blockCnt=11, waitCnt=7]
[11:51:55] : [Step 3/4] Lock 
[object=o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture@7e28f150,
 ownerName=sys-#68921%new-node-topology-change-thread-1%, ownerId=77410]
[11:51:55] : [Step 3/4] at 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.cancel(GridDhtPartitionDemander.java:1033)
[11:51:55] : [Step 3/4] at 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.addAssignments(GridDhtPartitionDemander.java:302)
[11:51:55] : [Step 3/4] at 

[GitHub] ignite pull request #4489: IGNITE-9146 Analyse and improve code coverage in ...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Data regions on client nodes

[Alexey Goncharuk]

I do not mind making this change, but note that the reason for non-lazy
region allocation is the need to gracefully handle OOME errors during cache
start. When a region is pre-allocated, no OOME can happen.

If a region is allocated dynamically, then all errors that happened during
the node start before should be properly handled (a client node must be
stopped, but cache creation should proceed).

пт, 27 июл. 2018 г. в 20:04, Valentin Kulichenko <
valentin.kuliche...@gmail.com>:

> Ticket created: https://issues.apache.org/jira/browse/IGNITE-9113
>
> -Val
>
> On Fri, Jul 27, 2018 at 5:59 AM Dmitry Pavlov 
> wrote:
>
> > Maxim, thank you.
> >
> > If it seems it is technically possible, we can file ticket for this
> change.
> >
> > I find this proposal reasonable, change makes perfectly sense to me.
> >
> > We can wait Alex G. feedback on this change before starting actual
> > implementation. It can take for a while, because he is travelling now.
> >
> > пт, 27 июл. 2018 г. в 14:35, Maxim Muzafarov :
> >
> > > Guys,
> > >
> > > I can miss some details, but at the first glance we have everething we
> > need
> > > to defer
> > > region memory allocation if it has no cache groups assignments. And it
> > > doesn't matter
> > > where it happens on client or server nodes.
> > >
> > > Currently region memory allocation happens at exchange future init
> > method.
> > > At the
> > > node startup method initCachesOnLocalJoin executes. This method
> > resposnible
> > > for
> > > memory allocation (through initiating cache managers) and it also
> starts
> > > caches.
> > > So, at this point we have all existing caches descriptors and can find
> > out
> > > which
> > > cache matches which region to defer some regions initialization to the
> > > moment when
> > > newly cache assings to this region (happend at onCacheChangeRequest).
> > >
> > > Please, сorrect me if I'm wrong and missing something.
> > >
> > >
> > >
> > > On Wed, 25 Jul 2018 at 19:32 Dmitry Pavlov 
> > wrote:
> > >
> > > > Hi Maxim,
> > > >
> > > > thank you for stepping in. How do you think, is it possible to check
> > > cache
> > > > assignment to region at stage of memory allocation?
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > ср, 25 июл. 2018 г. в 18:22, Maxim Muzafarov :
> > > >
> > > > > Folks,
> > > > >
> > > > > I've checked memory allocation. It looks like we are allocating
> > memory
> > > > only
> > > > > on the first exchange future init on local join occurs on node.
> Also,
> > > > seems
> > > > > like we are allocating only the first chunk of memory (not the
> whole
> > > > bunch)
> > > > > and it calculates as:
> > > > >
> > > > > Math.max((maxSize - startSize) / (SEG_CNT - 1), 256L * 1024 * 1024)
> > > > >
> > > > > But, I'm agree with Val. It's better to allocate memory only when
> > when
> > > > > the first cache assigned to this region.
> > > > >
> > > > >
> > > > >
> > > > > Also, It seems like we have some problem with user notification
> about
> > > > > available
> > > > > physical resources. For client nodes method requiredOffheap()
> returns
> > > > > always
> > > > > zero [1]. That's why WARN message shown here [2] would be not not
> > quite
> > > > > right
> > > > > if we have a lot of client nodes in cluster.
> > > > >
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L1501
> > > > > [2]
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L1489
> > > > >
> > > > > сб, 21 июл. 2018 г. в 14:15, Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > > >:
> > > > >
> > > > > > On Sat, Jul 21, 2018 at 5:22 AM, Valentin Kulichenko <
> > > > > > valentin.kuliche...@gmail.com> wrote:
> > > > > >
> > > > > > > Actually, I would go even further: only allocate a data region
> > on a
> > > > > node
> > > > > > > when the first cache assigned to this region is deployed on
> that
> > > > node.
> > > > > > > Because issue is broader than client nodes and local caches.
> One
> > > can
> > > > > have
> > > > > > > server nodes without any caches as well - running only
> services,
> > > for
> > > > > > > example.
> > > > > > >
> > > > > >
> > > > > > It would be great if this was possible, but to my knowledge,
> > regions
> > > > need
> > > > > > to be allocated on startup.
> > > > > >
> > > > > > Alexey Goncharuk, do you have any suggestions on this?
> > > > > >
> > > > > > D.
> > > > > >
> > > > > --
> > > > > --
> > > > > Maxim Muzafarov
> > > > >
> > > >
> > > --
> > > --
> > > Maxim Muzafarov
> > >
> >
>

[jira] [Created] (IGNITE-9235) Transitivity violation in GridMergeIndex Comparator

[Andrew Medvedev (JIRA)]

Andrew Medvedev created IGNITE-9235:
---

 Summary: Transitivity violation in GridMergeIndex Comparator
 Key: IGNITE-9235
 URL: https://issues.apache.org/jira/browse/IGNITE-9235
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Andrew Medvedev


Currently comparator is

 

private final Comparator streamCmp = new Comparator() {
 @Override public int compare(RowStream o1, RowStream o2) {
 // Nulls at the beginning.
 if (o1 == null)
 return -1;

 if (o2 == null)
 return 1;

 return compareRows(o1.get(), o2.get());
 }
};

 

 

This comparator violates transitivity when both RowStream are null. Thus we get 
excetption in JDK1.8:

 

 

 

 

WA: use -Djava.util.Arrays.useLegacyMergeSort=true

 



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

[jira] [Created] (IGNITE-9234) Wrong javadocs about null value for cache name.

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-9234:


 Summary: Wrong javadocs about null value for cache name.
 Key: IGNITE-9234
 URL: https://issues.apache.org/jira/browse/IGNITE-9234
 Project: Ignite
  Issue Type: Task
  Components: documentation
Affects Versions: 2.6
Reporter: Alexey Kuznetsov


Since Ignite 2.0 cache name can not be null (see IGNITE-3488).

javadocs for the following methods are not correct:

org.apache.ignite.configuration.CacheConfiguration#getName

org.apache.ignite.Ignite#cacheNames

They should be fixed.



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

Re: [MTCGA]: new failures in builds [1570331] needs to be handled

[Dmitriy Pavlov]

Hi Dmitriy,

Would it increase likelihood that somebody will pick up this ticket if we
will set blocker priority?

If it would increase I totally agree. IMO, JIRA priorities do not have much
effect on community members, do it?

Sincerely,
Dmitriy Pavlov

вт, 7 авг. 2018 г. в 14:00, Dmitriy Setrakyan :

> Maxim, if it is a new failure, why is it filed as Minor and is not assigned
> to any release? I would suggest that any new failure should be filed as a
> Blocker and assigned to the next release.
>
> D.
>
> On Tue, Aug 7, 2018 at 12:55 AM, Maxim Muzafarov 
> wrote:
>
> > Igniters,
> >
> > Seems this is a new failures due to last changes.
> > I've created new issue [1].
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-9202
> >
> > On Fri, 3 Aug 2018 at 20:57  wrote:
> >
> > > Hi Ignite Developer,
> > >
> > > I am MTCGA.Bot, and I've detected some issue on TeamCity to be
> addressed.
> > > I hope you can help.
> > >
> > >  *New test failure in master
> > > ExamplesTest.TestRemoteNodes(BinaryModeExample)
> > > https://ci.ignite.apache.org/project.html?projectId=
> > IgniteTests24Java8=-3155722801840665529=%
> > 3Cdefault%3E=testDetails
> > >
> > >  *New test failure in master ExamplesTest.TestRemoteNodes(
> > LinqExample)
> > > https://ci.ignite.apache.org/project.html?projectId=
> > IgniteTests24Java8=8941219717117543602=%
> > 3Cdefault%3E=testDetails
> > >
> > >  *New test failure in master ExamplesTest.TestRemoteNodes(
> > SqlExample)
> > > https://ci.ignite.apache.org/project.html?projectId=
> > IgniteTests24Java8=-61288549283153227=%
> > 3Cdefault%3E=testDetails
> > >  Changes may led to failure were done by
> > >  - nsamelchev
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827132=false
> > >  - biryukovvitaliy92
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827130=false
> > >  - ppozerov
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827122=false
> > >  - ppozerov
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827121=false
> > >  - dmitrievanthony
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827116=false
> > >  - eshangareev
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827112=false
> > >  - kaa.dev
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827106=false
> > >  - alkuznetsov.sb
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827101=false
> > >  - akuznetsov
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827091=false
> > >  - akuznetsov
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827089=false
> > >  - dmitriyff
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827084=false
> > >  - ppozerov
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827066=false
> > >  - vsisko
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827036=false
> > >  - akuznetsov
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827034=false
> > >  - verbalab
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827032=false
> > >  - verbalab
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827030=false
> > >  - verbalab
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827028=false
> > >  - verbalab
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827027=false
> > >  - verbalab
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827025=false
> > >  - verbalab
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827023=false
> > >
> > > - If your changes can led to this failure(s), please create
> issue
> > > with label MakeTeamCityGreenAgain and assign it to you.
> > > -- If you have fix, please set ticket to PA state and write to
> > dev
> > > list fix is ready
> > > -- For case fix will require some time please mute test and set
> > > label Muted_Test to issue
> > > - If you know which change caused failure please contact change
> > > author directly
> > > - If you don't know which change caused failure please send
> > > message to dev list to find out
> > > Should you have any questions please contact dpav...@apache.org or
> write
> > > to dev.list
> > > Best Regards,
> > > MTCGA.Bot
> > > Notification generated at Fri Aug 03 20:57:43 MSK 2018
> > >
> > --
> > --
> > Maxim Muzafarov
> >
>

[GitHub] ignite pull request #4462: IGNITE-9124 Remove some dead code in ML module

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Pessimistic Mode and Transactions and 2PC

[Dmitriy Pavlov]

Hi John,

Are these questions related to some contribution?

Sincerely,
Dmitriy Pavlov

ср, 8 авг. 2018 г. в 3:18, John Wilson :

> Hi,
>
> Assume the following:
>
>
>- I have a transaction coordinator and two primary nodes with 0 backup
>nodes.
>- Persistence store is enabled.
>- I'm running a transaction in pessimistic mode with serializable
>isolation.
>
> I have these questions:
>
>1. What exactly happens during the prepare phase? Only acquiring locks
>on the two primary nodes? Or do the primary nodes themselves, in
> addition
>to acquiring locks, write to their respective WAL a TxRecord with a
> "begin
>prepare" info?
>2. Assume locks have been acquired successfully, would the nodes then
>write a "prepared" TxRecord to WAL before returning a "Yes" vote to
>coordinator?
>3. When the coordinator sends a commit message, would each node write
>the key-values to the DataRecord and a commit to the TxRecord before
>returning to coordinator?
>
>
> Overall, I'm trying to understand what happens exactly during prepare and
> commit phases and when the key-values involved in the transaction are
> actually written; as well as the exact updates that are written to the WAL
> files in each phase.
>
> appreciate your response.
>
> Thanks,
>

[GitHub] ignite pull request #4376: IGNITE-9024 Wrong usage of idxLatch in DynamicInd...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Metrics for MVCC caches

[Roman Kondakov]

Hi Ivan!

In my opinion we need to preserve the essence of the metrics: if we 
didn't consider dirty writes as updates before MVCC implementation, we 
also shouldn't count these writes in MVCC metrics implementation too. 
So, I think we need to count only committed entries. But we can count 
this dirty writes as additional metrics.


Also additional metrics concerning MVCC could be:

- Average count of the active transactions per snapshot

- Average quantity of versions per key


--

Roman Kondakov


On 07.08.2018 17:17, Павлухин Иван wrote:

Hi Igniters,

I am working on cache metrics support for caches with enabled MVCC. As you
may know, during MVCC transaction execution entry versions are written to
storage right away (without deferring until commit). So, it is not obvious
for me if we should update writes count right away or defer it until
commit. On one hand, MVCC entry version write is not "true" write until
commit. On the other hand, it definitely changes the storage. How do we
interpret write metrics in Ignite philosophy?

Also, it seems that bunch of MVCC specific metrics could be introduced. I
would like to collect some thoughts about it. Which such metrics come to
your mind?

[GitHub] ignite pull request #4486: IGNITE-9065: Indexes integration for GDB

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4491: IGNITE-9193 Stop child python processes on parent...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-9233) MVCC SQL: False write conflicts on fast updates

[Ivan Pavlukhin (JIRA)]

Ivan Pavlukhin created IGNITE-9233:
--

 Summary: MVCC SQL: False write conflicts on fast updates
 Key: IGNITE-9233
 URL: https://issues.apache.org/jira/browse/IGNITE-9233
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Pavlukhin
Assignee: Ivan Pavlukhin


Currently is possible to encounter query failure e.g. in case when DELETE with 
directly specified key encounters write conflict for row which is created by 
concurrent INSERT. From SNAPSHOT isolation point of view DELETE either should 
not see a row and do nothing or should remove a row gracefully.



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

Re: [MTCGA]: new failures in builds [1570331] needs to be handled

[Maxim Muzafarov]

Dmitry,

I'm not familiar with all details of Ignite release management and can miss
something with changing the right issue priority. Hope you'll help me with
it at the initial stage. Generally, I agree with you here. I've marked this
issue as `Blocker` and attached to `2.7` release as this exception causes
in examples for user (I've just remembered same situation for Spark
examples).

But, from my point not all new failures can be marked as `Blocker` for
release,
e.g. we can change application behavior and skip some tests to fix. In this
case
we should mute them as it says by Review Checklist [1] point 3.c.


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

On Tue, 7 Aug 2018 at 14:00 Dmitriy Setrakyan  wrote:

> Maxim, if it is a new failure, why is it filed as Minor and is not assigned
> to any release? I would suggest that any new failure should be filed as a
> Blocker and assigned to the next release.
>
> D.
>
> On Tue, Aug 7, 2018 at 12:55 AM, Maxim Muzafarov 
> wrote:
>
> > Igniters,
> >
> > Seems this is a new failures due to last changes.
> > I've created new issue [1].
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-9202
> >
> > On Fri, 3 Aug 2018 at 20:57  wrote:
> >
> > > Hi Ignite Developer,
> > >
> > > I am MTCGA.Bot, and I've detected some issue on TeamCity to be
> addressed.
> > > I hope you can help.
> > >
> > >  *New test failure in master
> > > ExamplesTest.TestRemoteNodes(BinaryModeExample)
> > > https://ci.ignite.apache.org/project.html?projectId=
> > IgniteTests24Java8=-3155722801840665529=%
> > 3Cdefault%3E=testDetails
> > >
> > >  *New test failure in master ExamplesTest.TestRemoteNodes(
> > LinqExample)
> > > https://ci.ignite.apache.org/project.html?projectId=
> > IgniteTests24Java8=8941219717117543602=%
> > 3Cdefault%3E=testDetails
> > >
> > >  *New test failure in master ExamplesTest.TestRemoteNodes(
> > SqlExample)
> > > https://ci.ignite.apache.org/project.html?projectId=
> > IgniteTests24Java8=-61288549283153227=%
> > 3Cdefault%3E=testDetails
> > >  Changes may led to failure were done by
> > >  - nsamelchev
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827132=false
> > >  - biryukovvitaliy92
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827130=false
> > >  - ppozerov
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827122=false
> > >  - ppozerov
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827121=false
> > >  - dmitrievanthony
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827116=false
> > >  - eshangareev
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827112=false
> > >  - kaa.dev
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827106=false
> > >  - alkuznetsov.sb
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827101=false
> > >  - akuznetsov
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827091=false
> > >  - akuznetsov
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827089=false
> > >  - dmitriyff
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827084=false
> > >  - ppozerov
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827066=false
> > >  - vsisko
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827036=false
> > >  - akuznetsov
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827034=false
> > >  - verbalab
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827032=false
> > >  - verbalab
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827030=false
> > >  - verbalab
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827028=false
> > >  - verbalab
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827027=false
> > >  - verbalab
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827025=false
> > >  - verbalab
> > > http://ci.ignite.apache.org/viewModification.html?modId=
> > 827023=false
> > >
> > > - If your changes can led to this failure(s), please create
> issue
> > > with label MakeTeamCityGreenAgain and assign it to you.
> > > -- If you have fix, please set ticket to PA state and write to
> > dev
> > > list fix is ready
> > > -- For case fix will require some time please mute test and set
> > > label Muted_Test to issue
> > > - If you know which change caused failure please contact change
> > > author directly
> > > - If you don't know which change caused failure please send
> > > message to dev list to find out
> > > Should you have any questions please contact dpav...@apache.org or
> write
> > > to dev.list
> > > Best Regards,
> > > MTCGA.Bot
> > > Notification generated 

Re: Creation of dynamic cache

[Вячеслав Коптилин]

Hello Denis,

> Is it a typo? May be it should be something like:
> grid(0).getOrCreateCache(cfg); //< original configuration
Yep, it looks like a typo.

> Can I fix it in my PR?
It would be great :)

Best regards,
Slava.




ср, 8 авг. 2018 г. в 11:09, Denis Garus :

> Hi, Slava!
>
> I noticed that in the
> IgniteAbstractDynamicCacheStartFailTest#testCacheStartAfterFailure method
> the second started cache uses new configuration:
> ```
> public void testCacheStartAfterFailure() throws Exception {
> CacheConfiguration cfg = createCacheConfigsWithBrokenAffinityFun(
> false, 1, 0, 1, false).get(0);
>
> GridTestUtils.assertThrows(log, new Callable() {
> @Override public Object call() throws Exception {
> grid(0).getOrCreateCache(cfg);
> return null;
> }
> }, CacheException.class, null);
>
> // Correct the cache configuration. Default constructor creates a good
> affinity function.
> cfg.setAffinity(new BrokenAffinityFunction());
>
> IgniteCache cache =
> grid(0).getOrCreateCache(createCacheConfiguration(EXISTING_CACHE_NAME));
> //< new configuration
>
> checkCacheOperations(cache);
> }
> ```
> Is it a typo? May be it should be something like:
>
> grid(0).getOrCreateCache(cfg); //< original configuration
>
> Can I fix it in my PR?
>
> вт, 7 авг. 2018 г. в 17:37, Вячеслав Коптилин :
>
> > Hi,
> >
> > > I want to add a simulation of IgniteCheckedException in during of cache
> > creation to IgniteAbstractDynamicCacheStartFailTest
> > > and delete the catch block from
> > CacheAffinitySharedManager#processCacheStartRequests method
> > Looks like a plan :)
> >
> > Thanks,
> > S.
> >
> > вт, 7 авг. 2018 г. в 16:42, Denis Garus :
> >
> > > Hello, Slava!
> > >
> > > Yes, I agree with you. If we get rid of this catch block, everything
> > works
> > > well.
> > > But, IgniteAbstractDynamicCacheStartFailTest isn't honest enough
> because
> > it
> > > can't expose this failure.
> > > We should simulate not only RuntimeException but IgniteCheckedException
> > as
> > > well.
> > > I want to add a simulation of IgniteCheckedException in during of cache
> > > creation to IgniteAbstractDynamicCacheStartFailTest
> > > and delete the catch block from
> > > CacheAffinitySharedManager#processCacheStartRequests method.
> > >
> > > What are your thoughts?
> > >
> > > вт, 7 авг. 2018 г. в 15:31, Вячеслав Коптилин <
> slava.kopti...@gmail.com
> > >:
> > >
> > > > Hello Denis,
> > > >
> > > > It seems we can just comment out the following catch block:
> > > > ```
> > > > try {
> > > > if (startCache) {
> > > >
> > > > cctx.cache().prepareCacheStart(req.startCacheConfiguration(),
> > > > cacheDesc,
> > > > nearCfg,
> > > > evts.topologyVersion(),
> > > > req.disabledAfterStart());
> > > > //some code
> > > > }
> > > > }
> > > > //catch (IgniteCheckedException e) {
> > > > //U.error(log, "Failed to initialize cache. Will try to
> > rollback
> > > > cache start routine. [cacheName=" + req.cacheName() + ']', e);
> > > > //
> > > cctx.cache().closeCaches(Collections.singleton(req.cacheName()),
> > > > false);
> > > > //cctx.cache().completeCacheStartFuture(req, false, e);
> > > > //}
> > > > ```
> > > > I think that this exception should be propery handled by
> > > > GridDhtPartitionsExchangeFuture#onCacheChangeRequest(boolean crd)
> > method.
> > > > (please take a look at this JIRA ticket:
> > > > https://issues.apache.org/jira/browse/IGNITE-1094)
> > > >
> > > > Best regards,
> > > > Slava.
> > > >
> > > >
> > > > пт, 3 авг. 2018 г. в 14:54, Denis Garus :
> > > >
> > > > > Hello, Igniters!
> > > > >
> > > > >
> > > > > If an error occurred during of creation dynamic cache, the
> > > > > CacheAffinitySharedManager#processCacheStartRequests method will
> try
> > to
> > > > > rollback cache start routine.
> > > > > ```
> > > > > try {
> > > > > if (startCache) {
> > > > >
> > > > > cctx.cache().prepareCacheStart(req.startCacheConfiguration(),
> > > > > cacheDesc,
> > > > > nearCfg,
> > > > > evts.topologyVersion(),
> > > > > req.disabledAfterStart());
> > > > > //some code
> > > > > }
> > > > > }
> > > > > catch (IgniteCheckedException e) {
> > > > > U.error(log, "Failed to initialize cache. Will try to
> > rollback
> > > > > cache start
> > > > > routine. " +
> > > > > "[cacheName=" + req.cacheName() + ']', e);
> > > > >
> > > > >
> > >  cctx.cache().closeCaches(Collections.singleton(req.cacheName()),
> > > > > false);
> > > > >
> > > > > cctx.cache().completeCacheStartFuture(req, false, e);
> > > > > }
> > > > > ```
> > > > > Assume, that GridDhtPartitionsExchangeFuture will finish without
> any
> > > > error
> > > > > because of the exception is just logged.
> > > > > Is this way right? What should return the 

[jira] [Created] (IGNITE-9232) Remove commented method GridCacheUtils#isMongoCache

[Vyacheslav Daradur (JIRA)]

Vyacheslav Daradur created IGNITE-9232:
--

 Summary: Remove commented method GridCacheUtils#isMongoCache
 Key: IGNITE-9232
 URL: https://issues.apache.org/jira/browse/IGNITE-9232
 Project: Ignite
  Issue Type: Task
Reporter: Vyacheslav Daradur


There is a method: {{GridCacheUtils#isMongoCache}} which has been commented in 
2014y.

Shoud be removed as unused.



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

[jira] [Created] (IGNITE-9231) onMarkDirty improvement throttle implementation.

[Stanilovsky Evgeny (JIRA)]

Stanilovsky Evgeny created IGNITE-9231:
--

 Summary: onMarkDirty improvement throttle implementation.
 Key: IGNITE-9231
 URL: https://issues.apache.org/jira/browse/IGNITE-9231
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.6
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
 Fix For: 2.7


PagesWriteThrottle#onMarkDirty implementation park threads if checkpointBuffer 
is near to overflow, but further release of checkpointBuffer has no effect on 
parking threads, they still can be parked.



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

[jira] [Created] (IGNITE-9230) Cannot use array fields in DML oprtations in sqlline

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-9230:
-

 Summary: Cannot use array fields in DML oprtations in sqlline
 Key: IGNITE-9230
 URL: https://issues.apache.org/jira/browse/IGNITE-9230
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.6
Reporter: Sergey Kozlov
 Fix For: 2.7


{noformat}
sqlline version 1.3.0
0: jdbc:ignite:thin://127.0.0.1/> create table t1(a int null, b ARRAY, primary 
key(a));
No rows affected (0,113 seconds)
0: jdbc:ignite:thin://127.0.0.1/> insert into t1 (a,b) values (1, (1,2,3));
Error: Value conversion failed [from=[Ljava.lang.Object;, to=java.sql.Array] 
(state=0700B,code=0)
0: jdbc:ignite:thin://127.0.0.1/>
{noformat}



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

Re: welcome

[Yakov Zhdanov]

Hi Yriy!

Go ahead! You were added!

--Yakov

2018-08-07 17:19 GMT+03:00 Юрий :

> Hello, Ignite Community!
>
> My name is Iurii. I want to contribute to Apache Ignite.
> my JIRA user name is jooger. Any help on this will be appreciated.
>
> Thanks!
>
> --
> Live with a smile! :D
>

Re: Creation of dynamic cache

[Denis Garus]

Hi, Slava!

I noticed that in the
IgniteAbstractDynamicCacheStartFailTest#testCacheStartAfterFailure method
the second started cache uses new configuration:
```
public void testCacheStartAfterFailure() throws Exception {
CacheConfiguration cfg = createCacheConfigsWithBrokenAffinityFun(
false, 1, 0, 1, false).get(0);

GridTestUtils.assertThrows(log, new Callable() {
@Override public Object call() throws Exception {
grid(0).getOrCreateCache(cfg);
return null;
}
}, CacheException.class, null);

// Correct the cache configuration. Default constructor creates a good
affinity function.
cfg.setAffinity(new BrokenAffinityFunction());

IgniteCache cache =
grid(0).getOrCreateCache(createCacheConfiguration(EXISTING_CACHE_NAME));
//< new configuration

checkCacheOperations(cache);
}
```
Is it a typo? May be it should be something like:

grid(0).getOrCreateCache(cfg); //< original configuration

Can I fix it in my PR?

вт, 7 авг. 2018 г. в 17:37, Вячеслав Коптилин :

> Hi,
>
> > I want to add a simulation of IgniteCheckedException in during of cache
> creation to IgniteAbstractDynamicCacheStartFailTest
> > and delete the catch block from
> CacheAffinitySharedManager#processCacheStartRequests method
> Looks like a plan :)
>
> Thanks,
> S.
>
> вт, 7 авг. 2018 г. в 16:42, Denis Garus :
>
> > Hello, Slava!
> >
> > Yes, I agree with you. If we get rid of this catch block, everything
> works
> > well.
> > But, IgniteAbstractDynamicCacheStartFailTest isn't honest enough because
> it
> > can't expose this failure.
> > We should simulate not only RuntimeException but IgniteCheckedException
> as
> > well.
> > I want to add a simulation of IgniteCheckedException in during of cache
> > creation to IgniteAbstractDynamicCacheStartFailTest
> > and delete the catch block from
> > CacheAffinitySharedManager#processCacheStartRequests method.
> >
> > What are your thoughts?
> >
> > вт, 7 авг. 2018 г. в 15:31, Вячеслав Коптилин  >:
> >
> > > Hello Denis,
> > >
> > > It seems we can just comment out the following catch block:
> > > ```
> > > try {
> > > if (startCache) {
> > >
> > > cctx.cache().prepareCacheStart(req.startCacheConfiguration(),
> > > cacheDesc,
> > > nearCfg,
> > > evts.topologyVersion(),
> > > req.disabledAfterStart());
> > > //some code
> > > }
> > > }
> > > //catch (IgniteCheckedException e) {
> > > //U.error(log, "Failed to initialize cache. Will try to
> rollback
> > > cache start routine. [cacheName=" + req.cacheName() + ']', e);
> > > //
> > cctx.cache().closeCaches(Collections.singleton(req.cacheName()),
> > > false);
> > > //cctx.cache().completeCacheStartFuture(req, false, e);
> > > //}
> > > ```
> > > I think that this exception should be propery handled by
> > > GridDhtPartitionsExchangeFuture#onCacheChangeRequest(boolean crd)
> method.
> > > (please take a look at this JIRA ticket:
> > > https://issues.apache.org/jira/browse/IGNITE-1094)
> > >
> > > Best regards,
> > > Slava.
> > >
> > >
> > > пт, 3 авг. 2018 г. в 14:54, Denis Garus :
> > >
> > > > Hello, Igniters!
> > > >
> > > >
> > > > If an error occurred during of creation dynamic cache, the
> > > > CacheAffinitySharedManager#processCacheStartRequests method will try
> to
> > > > rollback cache start routine.
> > > > ```
> > > > try {
> > > > if (startCache) {
> > > >
> > > > cctx.cache().prepareCacheStart(req.startCacheConfiguration(),
> > > > cacheDesc,
> > > > nearCfg,
> > > > evts.topologyVersion(),
> > > > req.disabledAfterStart());
> > > > //some code
> > > > }
> > > > }
> > > > catch (IgniteCheckedException e) {
> > > > U.error(log, "Failed to initialize cache. Will try to
> rollback
> > > > cache start
> > > > routine. " +
> > > > "[cacheName=" + req.cacheName() + ']', e);
> > > >
> > > >
> >  cctx.cache().closeCaches(Collections.singleton(req.cacheName()),
> > > > false);
> > > >
> > > > cctx.cache().completeCacheStartFuture(req, false, e);
> > > > }
> > > > ```
> > > > Assume, that GridDhtPartitionsExchangeFuture will finish without any
> > > error
> > > > because of the exception is just logged.
> > > > Is this way right? What should return the Ignite#createCache method
> in
> > > this
> > > > case?
> > > >
> > > > I can't check what could return in that case because it just doesn't
> > work
> > > > this way now.
> > > > In the further, we're getting the critical error that stops
> > > ExchangeWorker
> > > > in a test environment
> > > > or stops node in a production environment.
> > > >
> > > > Reproducer:
> > > > ```
> > > > package org.apache.ignite.internal.processors.cache;
> > > >
> > > > import org.apache.ignite.IgniteCheckedException;
> > > > import org.apache.ignite.configuration.CacheConfiguration;
> > > > import 

Re: Metrics for MVCC caches

[Павлухин Иван]

Dmitry,

As with MVCC we can have multiple versions of each tuple at the same time
it introduces storage overhead. It would be good to have a measure for such
overhead.
Another thing is related to VACUUM procedure. For protecting system from
crash in case of high load it would be great to detect that VACUUM cleanup
cannot keep up with new tuple versions creation rate.

Currently it is just raw thoughts, I continue learning Ignite metrics
framework.

2018-08-08 1:12 GMT+03:00 Dmitriy Setrakyan :

> Ivan,
>
> To your 2nd question, can you suggest a few MVCC metrics to get the
> discussion started?
>
> D.
>
> On Tue, Aug 7, 2018 at 9:17 AM, Павлухин Иван  wrote:
>
> > Hi Igniters,
> >
> > I am working on cache metrics support for caches with enabled MVCC. As
> you
> > may know, during MVCC transaction execution entry versions are written to
> > storage right away (without deferring until commit). So, it is not
> obvious
> > for me if we should update writes count right away or defer it until
> > commit. On one hand, MVCC entry version write is not "true" write until
> > commit. On the other hand, it definitely changes the storage. How do we
> > interpret write metrics in Ignite philosophy?
> >
> > Also, it seems that bunch of MVCC specific metrics could be introduced. I
> > would like to collect some thoughts about it. Which such metrics come to
> > your mind?
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
>



-- 
Best regards,
Ivan Pavlukhin

Re: DataFrame integration does not support ARRAY type

[Nikolay Izhikov]

Hello, Valentin.

Yes, this is a bug.

Ticket created - https://issues.apache.org/jira/browse/IGNITE-9229

В Вт, 31/07/2018 в 16:01 -0700, Valentin Kulichenko пишет:
> Hi Nikolay,
> 
> Can you please take a look at this thread on SO? 
> https://stackoverflow.com/questions/51621280/saving-a-spark-dataset-to-apache-ignite-with-array-column-and-savemode-overwrite
> 
> Looks like org.apache.ignite.spark.impl.QueryUtils#dataType method should 
> also support ArrayType as one of the cases. Currently it doesn't and throws 
> an exception.
> 
> Is it a bug?
> 
> -Val

signature.asc
Description: This is a digitally signed message part

[jira] [Created] (IGNITE-9229) Integration with Spark Data Frame. Add support for a ARRAY data type

[Nikolay Izhikov (JIRA)]

Nikolay Izhikov created IGNITE-9229:
---

 Summary: Integration with Spark Data Frame. Add support for a 
ARRAY data type
 Key: IGNITE-9229
 URL: https://issues.apache.org/jira/browse/IGNITE-9229
 Project: Ignite
  Issue Type: Bug
  Components: spark
Affects Versions: 2.6
Reporter: Nikolay Izhikov
 Fix For: 2.7


Currently, integration with Spark Data Frames doesn't support ARRAY data type.
We need to add support for it



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