Re: DeadLocked while calling .Net ThinClient PutAll ?

2019-03-17 Thread Павлухин Иван
Hi,

When you are working with TRANSACTIONAL cache you should be aware that
deadlocks might happen. I see the following options to prevent
deadlocks to happen:
1. Explicitly order all keys involved in any transaction using the
same comparator.
2. Use OPTIMISTIC transactions.

Also, in many databases deadlocks can happen as well. So, instead of
preventing deadlocks it is quite common to provide some means of
breaking them. In Ignite it is possible to configure a transaction
timeout. In that case deadlocked transaction will be aborted sooner or
later and another transaction will be able to make a progress.

> Should it be handle natively in Ignite Core, shouldn't it ?

Unfortunately there is no general way to prevent deadlocks when using
PutAll with unordered collection. Ignite does not enforce all keys to
be Comparable which means that there could be keys without defined
consistent order. And if we cannot order keys consistently then we can
catch a deadlock.

пн, 18 мар. 2019 г. в 05:53, Tâm Nguyễn Mạnh :
>
> Hi Igniters,
>
> I heard that It could lead to DeadLocked when I pass non sorted collection
> into putAll method. Is it true ?
>
> From document i see that method requires a IEnumerable TV>> as input. I think pass a sorted collection into API is just a
> workaround way. Should it be handle natively in Ignite Core, shouldn't it ?
>
> How do you thing ?
>
> --
> Thanks & Best Regards
>
> Tam, Nguyen Manh



-- 
Best regards,
Ivan Pavlukhin


[jira] [Created] (IGNITE-11556) Add color legend into series selection panel

2019-03-17 Thread Alexander Kalinin (JIRA)
Alexander Kalinin created IGNITE-11556:
--

 Summary: Add color legend into series selection panel
 Key: IGNITE-11556
 URL: https://issues.apache.org/jira/browse/IGNITE-11556
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Alexander Kalinin


Currently we have a seris selector for charts, but it lacks color indication 
for matching series. Let's add them.



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


DeadLocked while calling .Net ThinClient PutAll ?

2019-03-17 Thread Tâm Nguyễn Mạnh
Hi Igniters,

I heard that It could lead to DeadLocked when I pass non sorted collection
into putAll method. Is it true ?

>From document i see that method requires a IEnumerable> as input. I think pass a sorted collection into API is just a
workaround way. Should it be handle natively in Ignite Core, shouldn't it ?

How do you thing ?

-- 
Thanks & Best Regards

Tam, Nguyen Manh


[jira] [Created] (IGNITE-11555) Unable to await partitions release latch caused by coordinator failover

2019-03-17 Thread Alexey Goncharuk (JIRA)
Alexey Goncharuk created IGNITE-11555:
-

 Summary: Unable to await partitions release latch caused by 
coordinator failover
 Key: IGNITE-11555
 URL: https://issues.apache.org/jira/browse/IGNITE-11555
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Goncharuk






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


Request for review/merge couple of small JUnit patches

2019-03-17 Thread Павлухин Иван
Hi Igniters,

Recently I created 2 PRs with simple changes related our testing framework.
1. Remove several @RunWith(JUnit4.class) lines left after migration to
junit 4 [1].
2. Remove custom assumption handler in order to improve reporting on
TC for tests skipped by failed assumption [2]. See the ticket for more
details.

First patch is rather trivial. Second patch was already reviewed but
it still waits for someone able to merge it.

Please take a look.

[1] https://issues.apache.org/jira/browse/IGNITE-11398
[2] https://issues.apache.org/jira/browse/IGNITE-11356

-- 
Best regards,
Ivan Pavlukhin


Re: Consistent ID specification from previous random UUID

2019-03-17 Thread Павлухин Иван
Hi Dmitriy,

It is a pitty that we have to guess here. Some comments:
1. The usage scenario is not very complex and erything might work well
with aforementioned patch. Unfortunately some tradeoff and extra
transformations are involved and consequently it is hard to predict
how many users will be troubled. But on a bright side the change is
seemless and perhaps nobody will be really troubled.
2. From "honest" code perspective introducing nodeStorageName seems
better to me because no (surprising) transformations are involved.
3. Also, it seems to me that original logic for choosing storage was
not designed well. From the first glance it looks strange that need
folders for a particular node in different places. Is not it much
clear to have all data of the node in a single directory isolated from
other nodes? AFAIK Hazelcast follows this approach. They generate an
error when someone is trying to launch second instance in the same
working directory. Perhaps, we at least should think about changing
our layout and consider including such change in some future release.

Thank you!

пт, 15 мар. 2019 г. в 17:55, Dmitriy Pavlov :
>
> Hi Ivan, yes, after the restart we need to re-use both folder name and UUID
> as consistent ID.
>
> About returning exact directory name: I'm just guessing here, but the
> persistent store is not the only folder, there are several more folders,
> e.g. binary-meta, etc.
>
> About several nodes reusing same root folder, yes, the proposed solution
> will not works because 00 is hardcoded here. But I expect it will be too
> rare case.
>
> Sincerely,
> Dmitriy Pavlov
>
> пт, 15 мар. 2019 г. в 11:29, Павлухин Иван :
>
> > Hi Dmitriy,
> >
> > It looks like that case with only one node in working directory is
> > covered. But what is problem is solved? As I understand before fix in
> > such case node after restart uses proper folder and proper
> > consistentId. After fix we can specify automatically generated UUID in
> > configuration and everything will go smooth. Is it the main problem
> > case? If yes then such simplicity is very attractive.
> >
> > But honestly I do not fully understand why do we need to return a node
> > to node00-UUID directory after that directory was deleted?
> >
> > чт, 14 мар. 2019 г. в 17:21, Dmitriy Pavlov :
> > >
> > > Hi, I've prepared demo PR for approach 1, just checking UUID and trying
> > to
> > > use node00-UUID. https://github.com/apache/ignite/pull/6266/ Actually
> > for
> > > this approach it is really simple, no API change is required.
> > >
> > > I guess the case is not very often because automatic folders assignment
> > > works well in most cases.
> > >
> > > WDYT?
> > >
> > > ср, 13 мар. 2019 г. в 09:42, Павлухин Иван :
> > >
> > > > Alex,
> > > >
> > > > Why do we need
> > > > >  - check if consistent ID is set to a string 'nodeXX-UUID'. In this
> > case
> > > > > the consistent ID is set to UUID, and the storage folder is chosen
> > > > > according to the proper rules. This change has a minimal chance to
> > affect
> > > > > current users because it's unlikely that somebody is using
> > auto-generated
> > > > > folder naming scheme as consistent ID.
> > > > ?
> > > > It looks hacky as well. The thing I do not like here is that a
> > > > consistentId specified in configuration is not a consistentId used by
> > > > a node sometimes.
> > > >
> > > > Can we go just with
> > > > > - either check if consistent ID is an instance of UUID and then take
> > the
> > > > > appropriate folder. This approach is straightforward, but may affect
> > > > > current users
> > > > ?
> > > >
> > > > And as a last chance a user will have a possibility to rename a
> > directory.
> > > >
> > > >
> > > > вт, 12 мар. 2019 г. в 19:33, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > > >:
> > > > >
> > > > > Igniters,
> > > > >
> > > > > I came across the same issue during development and found no sane
> > > > > workaround for this issue. I believe the solution should be as
> > simple as
> > > > > possible because we are already adding a warning to let users know
> > that
> > > > it
> > > > > is good to specify a consistent ID in production deployments.
> > > > >
> > > > > As for the current solution, I do not like adding a new configuration
> > > > > property like 'storageFolder' because it's another way to shoot
> > yourself
> > > > in
> > > > > the leg (e.g. different nodes have different consistent IDs but
> > > > configured
> > > > > to have the same storage folder).
> > > > > Why can't we:
> > > > >  - either check if consistent ID is an instance of UUID and then
> > take the
> > > > > appropriate folder. This approach is straightforward, but may affect
> > > > > current users
> > > > >  - check if consistent ID is set to a string 'nodeXX-UUID'. In this
> > case
> > > > > the consistent ID is set to UUID, and the storage folder is chosen
> > > > > according to the proper rules. This change has a minimal chance to
> > affect
> > > > > current users because it's unlike

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

2019-03-17 Thread dpavlov . tasks
Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *Recently contributed test failed in master tcp.TcpDiscoverySpiSelfTest 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-6980649976482672951&branch=%3Cdefault%3E&tab=testDetails

 *Recently contributed test failed in master 
tcp.TcpDiscoverySpiFailureTimeoutSelfTest 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=3316347121927346093&branch=%3Cdefault%3E&tab=testDetails
 No changes in the build

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 13:34:15 17-03-2019