Re: IGNITE-7107 Apache Ignite RPM packages

[vveider]

I've added IEP document [1] with current packages design for overview.


[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-11%3A+Introduce+Apache+Ignite+delivery+in+RPM+and+DEB+packages



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

Integration with Docker Hub official repositories

[Petr Ivanov]

Hi, all!


I’d like to initiate a process if integrating with Docker Hub on official level 
- as other Apache projects currently integrated (httpd / tomcat / maven / etc.).
So I’ve created a task [1] and assigned to myself.

Planning to introduce pull request to docker hub git repositories soon with 
corresponding configuration (including every docker image configuration version 
we currently have).
Keep you updated in this thread.


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

Re: Rework locking architecture for MVCC and transactional SQL

[Vladimir Ozerov]

Denis,

Sorry, may be I was not clear enough - "tuple-approach" and "persistent
approach" are the same. By "tuple" I mean a row stored inside a data block.
Currently we store lock information in Java heap and proposal is to move it
to data blocks. The main driver is memory - if there are a rows to be
locked we will either run out of memory, or produce serious memory
pressure. For example, currently update of 1M entries will consume ~500Mb
of heap. With proposed approach it will consume almost nothing. The
drawback is increased number of dirty data pages, but it should not be a
problem because in final implementation we will update data rows before
prepare phase anyway, so I do not expect any write amplification in usual
case.

This approach is only applicable for Ignite persistence.

On Thu, Dec 14, 2017 at 1:53 AM, Denis Magda  wrote:

> Vladimir,
>
> Thanks for a throughout overview and proposal.
>
> > Also we could try employing tiered approach
> > 1) Try to keep everything in-memory to minimize writes to blocks
> > 2) Fallback to persistent lock data if certain threshold is reached.
>
> What are the benefits of the backed-by-persistence approach in compare to
> the one based on tuples? Specifically:
> - will the persistence approach work for both 3rd party and Ignite
> persistence?
> - any performance impacts depending on a chosen method?
> - what’s faster to implement?
>
> —
> Denis
>
> > On Dec 13, 2017, at 2:10 AM, Vladimir Ozerov 
> wrote:
> >
> > Igniters,
> >
> > As you probably we know we work actively on MVCC [1] and transactional
> SQL
> > [2] features which could be treated as a single huge improvement. We
> face a
> > number of challenges and one of them is locking.
> >
> > At the moment information about all locks is kept in memory on per-entry
> > basis (see GridCacheMvccManager). For every locked key we maintain
> current
> > lock owner (XID) and the list of would-be-owner transactions. When
> > transaction is about to lock an entry two scenarios are possible:
> > 1) If entry is not locked we obtain the lock immediately
> > 2) if entry is locked we add current transaction to the wait list and
> jumps
> > to the next entry to be locked. Once the first entry is released by
> > conflicting transaction, current transaction becomes an owner of the
> first
> > entry and tries to promote itself for subsequent entries.
> >
> > Once all required locks are obtained, response is sent to the caller.
> >
> > This approach doesn't work well for transactional SQL - if we update
> > millions of rows in a single transaction we will simply run out of
> memory.
> > To mitigate the problem other database vendors keep information about
> locks
> > inside the tuples. I propose to apply the similar design as follows:
> >
> > 1) No per-entry lock information is stored in memory anymore.
> > 2) The list of active transactions are maintained in memory still
> > 3) When TX locks an entry, it sets special marker to the tuple [3]
> > 4) When TX meets already locked entry, it enlists itself to wait queue of
> > conflicting transaction and suspends
> > 5) When first transaction releases conflicting lock, it notifies and
> wakes
> > up suspended transactions, so they resume locking
> > 6) Entry lock data is cleared on transaction commit
> > 7) Entry lock data is not cleared on rollback or node restart; Instead,
> we
> > will could use active transactions list to identify invalid locks and
> > overwrite them as needed.
> >
> > Also we could try employing tiered approach
> > 1) Try to keep everything in-memory to minimize writes to blocks
> > 2) Fallback to persistent lock data if certain threshold is reached.
> >
> > Thoughts?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-3478
> > [2] https://issues.apache.org/jira/browse/IGNITE-4191
> > [3] Depends on final MVCC design - it could be per-tuple XID, undo
> vectors,
> > per-block transaction lists, etc..
> >
> > Vladimir.
>
>

[GitHub] ignite pull request #3224: Ignite 2.1.9

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

Ignite 2.1.9



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

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

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

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


commit 4bc56b59c5a9f146defdb443b022bc3d4cac069d
Author: Pavel Tupitsyn 
Date:   2017-07-28T07:06:16Z

IGNITE-5769 Abstract away .NET->Java calls

This closes #2352

commit fdb77354147bdb85fd9b0ef804b94d1c10b0c02d
Author: Pavel Tupitsyn 
Date:   2017-08-30T15:35:05Z

IGNITE-5931 .NET: Fix type registration race condition

This closes #2553

commit 7746f5fcd83be2e7240f1bc3143d95c08808373c
Author: Pavel Tupitsyn 
Date:   2017-08-31T11:06:47Z

IGNITE-5924 .NET: Decouple Marshaller from Ignite

This closes #2559

commit b2a0ccbc87386dbc103aad43e4e0f6f09f675e64
Author: Pavel Tupitsyn 
Date:   2017-09-01T08:49:48Z

IGNITE-6233 .NET: Extract type codes to a separate class

This closes #2570

commit d440a73f614ece59c7fa331f408aac7ac955cbdb
Author: Pavel Tupitsyn 
Date:   2017-09-06T13:24:41Z

IGNITE-6279 .NET: Decouple AbstractQueryCursor from PlatformTarget

This closes #2598

commit a810bd2d63523bc27a330eb2c48a5416244948f0
Author: Pavel Tupitsyn 
Date:   2017-09-14T18:40:48Z

IGNITE-6258: Thin client: binary metadata protocol. This closes #2662. This 
closes #2667.

commit 976a8237adc67e2c585b20bd5cd9fd71824ab86c
Author: vsisko 
Date:   2017-09-15T11:02:59Z

IGNITE-6251 Clear selection from removed rows.
(cherry picked from commit 8741acc)

commit 4e6f39ba4876249c08629321e442e46a1b38d982
Author: Pavel Tupitsyn 
Date:   2017-09-15T11:05:53Z

IGNITE-6368: Initial .NET part of thin client. This closes #2670.

commit ef2f8c8b721503e5319033952b51fdf7059d4eba
Author: EdShangGG 
Date:   2017-09-15T08:59:48Z

IGNITE-6277 Added ability to convert WAL to human readable form - Fixes 
#2605.

Signed-off-by: Alexey Goncharuk 

commit c35b336892f601a2c23edb0a803c065bc0a9c664
Author: Andrey V. Mashenkov 
Date:   2017-09-15T13:45:02Z

IGNITE-6256: DiscoCache always contains local node.

Signed-off-by: Andrey Gura 

commit dd9c3a81d5ff53bdd88dd83e8f03480912cfbd58
Author: tledkov-gridgain 
Date:   2017-09-15T14:25:26Z

IGNITE-6395: Remove old test. This closes #2673.

commit b6350366fef2a75e9d4eeba9392aec660c0dda0b
Author: devozerov 
Date:   2017-09-16T11:57:55Z

IGNITE-6327: Added thin client configuration. This closes #2672.

commit ecdb3ea74b1d5444c53a043f52e851c840fc7e7b
Author: Alexander Paschenko 
Date:   2017-09-16T14:41:34Z

IGNITE-5620: Implemented SQLSTATE error code for server-side logic and JDBC 
thin client. This closes #2541.

commit d347c2c00b6084c26c640793ea8ba08114022d07
Author: vsisko 
Date:   2017-09-18T07:09:22Z

IGNITE-6417 Fixed missed binary configuration.
(cherry picked from commit 40597a0)

commit 0a878ece75d2b69be92caac0bacb9a7ba866e522
Author: Ilya Kasnacheev 
Date:   2017-09-07T13:41:44Z

Fixed Licenses & Javadoc tests

cherry-pick from aa172573364b3fd91b089df252d884ee9aa8c24f

commit 9f2426ece7a3aab8701902505774627b096ad6e2
Author: Pavel Tupitsyn 
Date:   2017-09-18T09:57:26Z

IGNITE-6404 Fix failures in .NET (NPE in ExceptionUtils, inspections)

commit a2d9d76cbce8658ec42e951432a0e92ee22f46b5
Author: devozerov 
Date:   2017-09-18T10:36:38Z

IGNITE-6413: Improved thin client configuration processing. This closes 
#2680.

commit 9edcd5f7ca5609860b77a8bbb049ad5e805ad967
Author: Sergey Kalashnikov 
Date:   2017-09-18T11:54:40Z

IGNITE-6396: JDBC thin driver: added test for error code for NOT NULL 
violation. This closes #2681.

commit ea2caeb834a100448784c28d49b8d6aca4b3ed51
Author: Alexandr Kuramshin 
Date:   2017-09-18T12:46:46Z

IGNITE-6200 org.dom4j.QName can't be serialized

Signed-off-by: Andrey Gura 

commit bda0b7ce310a24600583869f491326808f07d8bd
Author: tledkov-gridgain 
Date:   2017-09-18T13:01:34Z

IGNITE-6317: JDBC driver: SQLSTATE support. This closes #2682.

commit b74744a0f57cda09bea4c8b303fd7aecbf5e1142
Author: Vitaliy Biryukov 
Date:   

[jira] [Created] (IGNITE-7199) Web Console: some improvments

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-7199:


 Summary: Web Console: some improvments
 Key: IGNITE-7199
 URL: https://issues.apache.org/jira/browse/IGNITE-7199
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov


1. Add registered date.
2. Improve becomed mode (hide non supported in this mode features).
3. Improved export from grids.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Apache Ignite as a distributed processing back-ends

[Denis Magda]

Those are the valid points. Personally, I would go for the beam-repo way 
because it will guarantee that the integration works as expected with every 
Beam release. This is for instance how Ignite is integrated with Camel, 
MyBatis, Zeppelin.

Anyway, here is a ticket. Hope that an Ignite fellow will step in and solve it 
in the nearest time:
https://issues.apache.org/jira/browse/IGNITE-7198 


—
Denis

> On Dec 12, 2017, at 9:52 PM, Romain Manni-Bucau  wrote:
> 
> Hosting integrations in impl more than beam makes a lot of sense IMHO while
> you can maintain it and follow beam release cycle. It will enable you to
> evolve faster and optimise/adapt it more accurately. If you dont have the
> resources, beam would fit better and guarantee it works with each release.
> 
> My 2 cts
> 
> Le 13 déc. 2017 00:47, "Lukasz Cwik"  a écrit :
> 
>> Having it inside the Apache Beam repo makes sense and I could see it being
>> a good fit as an IO and as a runner.
>> 
>> On Tue, Dec 12, 2017 at 3:29 PM, Denis Magda  wrote:
>> 
>>> Hi Romain,
>>> 
>>> Thanks for the reference. Do you prefer to have the Ignite runner in
>>> Beam’s code base?
>>> 
>>> From what I see, the current runners are hosted there:
>>> https://github.com/apache/beam/tree/master/runners
>>> 
>>> As for Ignite community, we would prefer to hold the integration in your
>>> repo.
>>> 
>>> —
>>> Denis
>>> 
>>> On Dec 7, 2017, at 9:54 PM, Romain Manni-Bucau 
>>> wrote:
>>> 
>>> Hi
>>> 
>>> This sounds awesome to have an Ignite runner which could compete with
>>> hazelcast-jet.
>>> 
>>> The entry point would be https://beam.apache.org/contribute/runner-guide/
>>> IMHO.
>>> 
>>> Being on Ignite cluster also opens a lot of doors - reusing the filesystem
>>> or distributed structures. Very exiting.
>>> 
>>> Le 8 déc. 2017 05:46, "Denis Magda"  a écrit :
>>> 
>>> Hello Apache Beam fellows!
>>> 
>>> We at Apache Ignite community came across your project and would be happy
>>> to integrate with it.
>>> 
>>> In short, Ignite is a distributed database and computational platform that
>>> has its own map-reduce like component:
>>> https://apacheignite.readme.io/docs/compute-grid
>>> 
>>> The integration will give Beam users an ability to use Ignite as a
>>> distributed processing back-end system and database.
>>> 
>>> How should we proceed? Please share any relevant information.
>>> 
>>> —
>>> Denis
>>> Ignite PMC
>>> 
>>> 
>>> 
>> 

[jira] [Created] (IGNITE-7198) Integrate with Apache Beam

[Denis Magda (JIRA)]

Denis Magda created IGNITE-7198:
---

 Summary: Integrate with Apache Beam 
 Key: IGNITE-7198
 URL: https://issues.apache.org/jira/browse/IGNITE-7198
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
 Fix For: 2.5


Apache Beam (https://beam.apache.org/) provides a unified API for batch and 
streaming processing. It can be seen as a generic/portable API with multiple 
implementations (Spark, Flink, etc.).

Apache Ignite perfectly fits Beam architecture as a Runner:
https://beam.apache.org/contribute/runner-guide/

Here is Beam's capability matrix. Let's support as much as we're capable of:
https://beam.apache.org/documentation/runners/capability-matrix/

Most likely the integration should go to Beam's repository:
https://github.com/apache/beam/tree/master/runners

Discussion on the dev list: 
http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-as-a-distributed-processing-back-ends-td25122.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: How properly handle IgniteOOM

[Denis Magda]

Hello Mikhail,

This problem is related to the discussion around Ignite internal problems and 
their possible resolution:
http://apache-ignite-developers.2346864.n4.nabble.com/Internal-problems-requiring-graceful-node-shutdown-reboot-etc-td24856.html
 


Referring to that discussion, I would define a special IgniteFailureAction in 
response to IgniteOOM (IgniteFailureCause in terms of the new API). The action 
can purge, wipe out the page memory or do another extra steps.

—
Denis

> On Dec 13, 2017, at 9:14 AM, Mikhail Cherkasov  
> wrote:
> 
> Hi all,
> 
> I faced with a problem that if Ignite has no memory and IgniteOOM was
> thrown, there's no way to continues work with a cluster.
> 
> You cannot remove some part of data to free some space because during
> removing Ignite tries to move pages to a free list and free list tries
> to acquire more pages, but there's no more space for this.
> 
> Ignite can not revert transactions properly due to the same reason.
> If  IgniteOOM occurs during transaction Ignite will try to revert already
> applied changes and as result will move some pages to free list and there's
> the same problem as above, no space for the free list too.
> 
> And you even cannot add more nodes, because after rebalancing ignite will
> try to evict pages and this means again we need to a space for free list:
> https://issues.apache.org/jira/browse/IGNITE-7019
> 
> Do you have ideas how we can properly handle this?
> 
> -- 
> Thanks,
> Mikhail.

Updated invitation: RSVP now for Dec. 13 Bay Area In-Memory Computing Meetup! @ Wed Dec 13, 2017 8pm - 10pm (CST) (dev@ignite.apache.org)

[tom . diederich]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20171214T02Z
DTEND:20171214T04Z
DTSTAMP:20171213T230118Z
ORGANIZER;CN=GridGain Meetups (includes guest talks):mailto:gridgain.com_ci
 4oqrn7b9ia4drtrurq004...@group.calendar.google.com
UID:3dkgvqsi9lg5otqe9pc3mo2...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=dev@ignite.apache.org;X-NUM-GUESTS=0:mailto:dev@ignite.apache.org
CREATED:20171120T225454Z
DESCRIPTION:We have a great meetup planned for the evening of Dec. 13! In-m
 emory computing experts from Hazelcast and GridGain Systems will be speakin
 g. And\, of course\, we’ll have great food\, drinks – and cool raffle prize
 s\, too! Please RSVP here so we can order the appropriate food and 
 beverages. https://www.google.com/url?q=http%3A%2F%2Fbit.ly%2F
 2AgZdpb\;sa=D\;ust=1513213199376000\;usg=AFQjCNGBz642sfzwQa8Hgs
 NyGLsL3adGXA" target="_blank">http://bit.ly/2AgZdpbSpeakers: Valentin (Val) Kulichenko\, GridGain Systems Fuad Malikov\, Hazelcast
  Talk one: (Hazelcast) Java SE 8 Stream API is a modern and functio
 nal API for processing Java Collections. Streams can do parallel processing
  by utilizing multi-core architecture\, without writing a single line of mu
 ltithreaded code. Hazelcast JET is a distributed\, high-performance stream 
 processing DAG engine\, which provides distributed Java 8 Stream API implem
 entation. This session will highlight this implementation of Stream API for
  big-data processing across many machines from the comfort of your Java App
 lication. With an explanation of internals of the implementation\, 
 I will give an introduction to the general design behind stream processing 
 using DAG (directed acyclic graph) engines and how an actor-based implement
 ation can provide in-memory performance while still leveraging industry-wid
 e known frameworks as Java Streams API.Talk two: (GridGain Syst
 ems) It’s well known that distributed systems rely very much on horizontal 
 scalability. The more machines in your cluster - the better performance of 
 your application\, right? Well\, not always. While a database can provide r
 ich capabilities to achieve lightning fast performance\, it’s an engineer's
  responsibility to use these capabilities properly as there are a lot of wa
 ys to mess things up.During this meetup\, Valentin Kulichenko\, Gri
 dGain System’s Lead Architect\, will talk about challenges and pitfalls one
  may face when architecting and developing a distributed system. Valentin w
 ill show how to take advantage of the affinity collocation concept that is 
 one of the most powerful and usually undervalued technique provided by dist
 ributed systems. He will take Apache Ignite as a database for his experimen
 ts covering these moments in particular:What is data affinity and w
 hy is it important for distributed systems? What is affinity colocation and
  how does it help to improve performance? How does affinity colocation affe
 cts execution of distributed computations and distributed SQL queries? And 
 more…After this talk\, you will have better understanding about how
  distributed systems work under the hood\, and will be able to better desig
 n your applications based on them.\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this
  section of the description.\n\nView your event at https://www.google.com/c
 alendar/event?action=VIEW=M2RrZ3Zxc2k5bGc1b3RxZTlwYzNtbzJxdm8gZGV2QGlnb
 ml0ZS5hcGFjaGUub3Jn=NjUjZ3JpZGdhaW4uY29tX2NpNG9xcm43YjlpYTRkcnRydXJxMDA
 0aWhzQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20zODQ1NjUwZDEyNDNiYTFlZDkzMDQwNzQ1MW
 YyZWUxYWRiYjZmMDRl=America/Chicago=en.\n-::~:~::~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20171213T230118Z
LOCATION:1172 Castro St\, Mountain View\, CA 94040\, USA
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:RSVP now for Dec. 13 Bay Area In-Memory Computing Meetup!
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: CacheMetrics update and rolling upgrades.

[Denis Magda]

Hello Pavel,

Could you share the signature of the new metrics with us hear? The community 
will be happy to provide a feedback.

What do you mean under the rolling upgrade? There is no such a feature in 
Ignite.

—
Denis

> On Dec 13, 2017, at 8:22 AM, Pavel Pereslegin  wrote:
> 
> Hi, Igniters!
> 
> I’m working on IGNITE-6333 [1] and I need to add two new metrics into
> CacheMetrics.
> As I see, versioning is not supported for now.
> Do I need to care about rolling upgrades?
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-6333

Re: Rework locking architecture for MVCC and transactional SQL

[Denis Magda]

Vladimir,

Thanks for a throughout overview and proposal.
 
> Also we could try employing tiered approach
> 1) Try to keep everything in-memory to minimize writes to blocks
> 2) Fallback to persistent lock data if certain threshold is reached.

What are the benefits of the backed-by-persistence approach in compare to the 
one based on tuples? Specifically:
- will the persistence approach work for both 3rd party and Ignite persistence?
- any performance impacts depending on a chosen method?
- what’s faster to implement?

—
Denis

> On Dec 13, 2017, at 2:10 AM, Vladimir Ozerov  wrote:
> 
> Igniters,
> 
> As you probably we know we work actively on MVCC [1] and transactional SQL
> [2] features which could be treated as a single huge improvement. We face a
> number of challenges and one of them is locking.
> 
> At the moment information about all locks is kept in memory on per-entry
> basis (see GridCacheMvccManager). For every locked key we maintain current
> lock owner (XID) and the list of would-be-owner transactions. When
> transaction is about to lock an entry two scenarios are possible:
> 1) If entry is not locked we obtain the lock immediately
> 2) if entry is locked we add current transaction to the wait list and jumps
> to the next entry to be locked. Once the first entry is released by
> conflicting transaction, current transaction becomes an owner of the first
> entry and tries to promote itself for subsequent entries.
> 
> Once all required locks are obtained, response is sent to the caller.
> 
> This approach doesn't work well for transactional SQL - if we update
> millions of rows in a single transaction we will simply run out of memory.
> To mitigate the problem other database vendors keep information about locks
> inside the tuples. I propose to apply the similar design as follows:
> 
> 1) No per-entry lock information is stored in memory anymore.
> 2) The list of active transactions are maintained in memory still
> 3) When TX locks an entry, it sets special marker to the tuple [3]
> 4) When TX meets already locked entry, it enlists itself to wait queue of
> conflicting transaction and suspends
> 5) When first transaction releases conflicting lock, it notifies and wakes
> up suspended transactions, so they resume locking
> 6) Entry lock data is cleared on transaction commit
> 7) Entry lock data is not cleared on rollback or node restart; Instead, we
> will could use active transactions list to identify invalid locks and
> overwrite them as needed.
> 
> Also we could try employing tiered approach
> 1) Try to keep everything in-memory to minimize writes to blocks
> 2) Fallback to persistent lock data if certain threshold is reached.
> 
> Thoughts?
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-3478
> [2] https://issues.apache.org/jira/browse/IGNITE-4191
> [3] Depends on final MVCC design - it could be per-tuple XID, undo vectors,
> per-block transaction lists, etc..
> 
> Vladimir.

Re: Separate code paths for Java 8 and Java 9

[Vladimir Ozerov]

Hi Andrey,

If it is possible to resolve all mentioned issues with static code blocks,
then this is definitely preferrable approach. Let's fix simple issues first
and see what to do with complex ones. Notably:
1) https://issues.apache.org/jira/browse/IGNITE-6740 - this call is on a
hot path, so reflection is not an option;
2) https://issues.apache.org/jira/browse/IGNITE-6736 - the only possible
way to fix it is to resort to ReentrantLock instead of synchronized. But
this could cause bloat and performance degradation for non-contented cases,
when synchronized might be faster.

On Wed, Dec 13, 2017 at 8:18 PM, Andrey Kuznetsov  wrote:

> Igniters,
>
> As [1] proposes, a couple of new modules with version-specific code should
> be created. While working on issues from [2] umbrella I saw no significant
> reasons to emerge separate modules; most requirements can be covered by
> tiny conditional code pieces in static init blocks of existing utility
> classes.
>
> Could someone share the ideas on the content of potential version-specific
> modules?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-6730
> [2] https://issues.apache.org/jira/browse/IGNITE-6728
>
> --
> Best regards,
>   Andrey Kuznetsov.
>

[GitHub] ignite pull request #3223: IGNITE-7189: Fixed ODBC table names in metadata

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-7189: Fixed ODBC table names in metadata



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

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

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

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


commit c0df7f244f453371e6d38284c3c486e8b1aa217d
Author: Igor Sapego 
Date:   2017-12-13T15:26:02Z

IGNITE-7189: Fixed

commit 57c2d0bd662ef770165a54ba9a7cff3b55530187
Author: Igor Sapego 
Date:   2017-12-13T17:49:56Z

IGNITE-7189: Added tests




---

Separate code paths for Java 8 and Java 9

[Andrey Kuznetsov]

Igniters,

As [1] proposes, a couple of new modules with version-specific code should
be created. While working on issues from [2] umbrella I saw no significant
reasons to emerge separate modules; most requirements can be covered by
tiny conditional code pieces in static init blocks of existing utility
classes.

Could someone share the ideas on the content of potential version-specific
modules?

[1] https://issues.apache.org/jira/browse/IGNITE-6730
[2] https://issues.apache.org/jira/browse/IGNITE-6728

-- 
Best regards,
  Andrey Kuznetsov.

How properly handle IgniteOOM

[Mikhail Cherkasov]

Hi all,

I faced with a problem that if Ignite has no memory and IgniteOOM was
thrown, there's no way to continues work with a cluster.

You cannot remove some part of data to free some space because during
removing Ignite tries to move pages to a free list and free list tries
to acquire more pages, but there's no more space for this.

Ignite can not revert transactions properly due to the same reason.
If  IgniteOOM occurs during transaction Ignite will try to revert already
applied changes and as result will move some pages to free list and there's
the same problem as above, no space for the free list too.

And you even cannot add more nodes, because after rebalancing ignite will
try to evict pages and this means again we need to a space for free list:
https://issues.apache.org/jira/browse/IGNITE-7019

Do you have ideas how we can properly handle this?

-- 
Thanks,
Mikhail.

[GitHub] ignite pull request #3222: IGNITE-7197 Avoid NPE in serviced() by waiting on...

[alamar]

GitHub user alamar opened a pull request:

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

IGNITE-7197 Avoid NPE in serviced() by waiting on latch.



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

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

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

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


commit 55cab23ab8561efef1fc144bd1fb827871f69654
Author: Ilya Kasnacheev 
Date:   2017-12-13T17:09:39Z

IGNITE-7197 Avoid NPE in serviced() by waiting on latch.




---

[GitHub] ignite pull request #3213: IGNITE-6495 performance measurement of decision t...

[asfgit]

Github user asfgit closed the pull request at:

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


---

CacheMetrics update and rolling upgrades.

[Pavel Pereslegin]

Hi, Igniters!

I’m working on IGNITE-6333 [1] and I need to add two new metrics into
CacheMetrics.
As I see, versioning is not supported for now.
Do I need to care about rolling upgrades?

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

[jira] [Created] (IGNITE-7197) Premature access to services() causes NullPointerException

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-7197:
---

 Summary: Premature access to services() causes NullPointerException
 Key: IGNITE-7197
 URL: https://issues.apache.org/jira/browse/IGNITE-7197
 Project: Ignite
  Issue Type: Bug
  Components: managed services
Affects Versions: 2.3
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev


{code}
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.serviceEntries(GridServiceProcessor.java:1289)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.serviceDescriptors(GridServiceProcessor.java:762)
at 
org.apache.ignite.internal.IgniteServicesImpl.serviceDescriptors(IgniteServicesImpl.java:203)
at 
org.apache.ignite.internal.visor.service.VisorServiceTask$VisorServiceJob.run(VisorServiceTask.java:60)
at 
org.apache.ignite.internal.visor.service.VisorServiceTask$VisorServiceJob.run(VisorServiceTask.java:44)
at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
{code}

Happens with non-Visor jobs and callables, too!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches

[Mikhail Cherkasov (JIRA)]

Mikhail Cherkasov created IGNITE-7196:
-

 Summary: Exchange can stuck and wait while new node restoring 
state from disk and starting caches
 Key: IGNITE-7196
 URL: https://issues.apache.org/jira/browse/IGNITE-7196
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.3
Reporter: Mikhail Cherkasov
Priority: Critical
 Fix For: 2.4


Exchange can stuck and wait while new node restoring state from disk and 
starting caches, there's a log snippet from a just joined new node that shows 
the issue:

[21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started 
exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0], 
crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1, 
customEvt=null, allowMerge=true]
[21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager] 
Resolved page store work directory: 
/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463
[21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager]
 Resolved write ahead log work directory: 
/mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463
[21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager]
 Resolved write ahead log archive directory: 
/mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463
[21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager]
 Started write-ahead log manager [mode=DEFAULT]
[21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] 
Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4 
KiB, checkpointBuffer=100.0 MiB]
[21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] 
Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6 
MiB, checkpointBuffer=896.0 MiB]
[21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
 Read checkpoint status 
[startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin,
 
endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin]
[21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
 Checking memory state [lastValidPos=FileWALPointer [idx=3582, 
fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer 
[idx=3629, fileOffset=50829700, len=9229, forceFlush=false], 
lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af]
[21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
 Ignite node stopped in the middle of checkpoint. Will restore memory state and 
finish checkpoint on node start.
[21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi]
 Accepted incoming communication connection [locAddr=/172.31.20.209:48100, 
rmtAddr=/172.31.17.115:57148]
[21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
 Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af, 
pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229, forceFlush=false]]
[21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager]
 Finished applying memory changes [changesApplied=165103, time=8189ms]
[21:36:22,403][INFO][grid-nio-worker-tcp-comm-1-#42%statement_grid%][TcpCommunicationSpi]
 Accepted incoming communication connection [locAddr=/172.31.20.209:48100, 
rmtAddr=/172.31.28.10:47964]
[21:36:23,414][INFO][grid-nio-worker-tcp-comm-2-#43%statement_grid%][TcpCommunicationSpi]
 Accepted incoming communication connection [locAddr=/172.31.20.209:48100, 
rmtAddr=/172.31.27.101:46000]
[21:36:33,019][WARNING][main][GridCachePartitionExchangeManager] Failed to wait 
for initial partition map exchange. Possible reasons are:
^-- Transactions in deadlock.
^-- Long running transactions (ignore if this is the case).
^-- Unreleased explicit locks.
[21:36:53,021][WARNING][main][GridCachePartitionExchangeManager] Still waiting 
for initial partition map exchange [fut=GridDhtPartitionsExchangeFuture 
[firstDiscoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=3ac1160e-0de4-41bc-a366-59292c9f03c1, addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 
172.31.20.209], sockAddrs=[/0:0:0:0:0:0:0:1%lo:48500, /127.0.0.1:48500, 
ip-172-31-20-209.eu-central-1.compute.internal/172.31.20.209:48500], 
discPort=48500, order=57, intOrder=36, lastExchangeTime=1512931012268, 
loc=true, ver=2.3.1#20171129-sha1:4b1ec0fe, isClient=false], topVer=57, 
nodeId8=3ac1160e, msg=null, type=NODE_JOINED, tstamp=1512930972992], 
crd=TcpDiscoveryNode [id=56c97317-26cf-43d2-bf76-0cab59c6fa5f, 
addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.31.27.101], 
sockAddrs=[/0:0:0:0:0:0:0:1%lo:48500, /127.0.0.1:48500, 

[jira] [Created] (IGNITE-7195) GridToStringBuilder should limit large collections output to first N elements

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-7195:
-

 Summary: GridToStringBuilder should limit large collections output 
to first N elements
 Key: IGNITE-7195
 URL: https://issues.apache.org/jira/browse/IGNITE-7195
 Project: Ignite
  Issue Type: Bug
Reporter: Yakov Zhdanov


GridToStringBuilder should limit large collections output to first N elements 
(otherwise, OOME is possible). N should be limited by 
IGNITE_TO_STRING_COLLECTION_LIMIT system property and should be 10 by default.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7194) Limit the number of collection elements printed in S.toString()

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-7194:


 Summary: Limit the number of collection elements printed in 
S.toString()
 Key: IGNITE-7194
 URL: https://issues.apache.org/jira/browse/IGNITE-7194
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Goncharuk






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7193) IgniteReflectionFactory does not handle primitive data types.

[Vyacheslav Koptilin (JIRA)]

Vyacheslav Koptilin created IGNITE-7193:
---

 Summary: IgniteReflectionFactory does not handle primitive data 
types.
 Key: IGNITE-7193
 URL: https://issues.apache.org/jira/browse/IGNITE-7193
 Project: Ignite
  Issue Type: Bug
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7192) JDBC: support FQDN to multiple IPs during connection establishment

[Alexey Popov (JIRA)]

Alexey Popov created IGNITE-7192:


 Summary: JDBC: support FQDN to multiple IPs during connection 
establishment
 Key: IGNITE-7192
 URL: https://issues.apache.org/jira/browse/IGNITE-7192
 Project: Ignite
  Issue Type: Improvement
  Components: jdbc
Affects Versions: 2.1
Reporter: Alexey Popov


Thin JDBC driver may have FQDN (host name) at a connection string.
Currently, it resolves this FQDN to one IP and tries to connect to this IP only.
It is better to try to connect to multiple IPs one-by-one if DNS returns 
multiple A-records (FQDN can be resolved to several IPs) until successful 
connection. It could give a simple fallback option for the JDBC thin driver 
users.

A similar functionality is already implemented in ODBC driver.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #3220: IGNITE-4191

[gvvinblade]

GitHub user gvvinblade reopened a pull request:

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

IGNITE-4191



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

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

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

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






---

[GitHub] ignite pull request #3220: IGNITE-4191

[gvvinblade]

Github user gvvinblade closed the pull request at:

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


---

[jira] [Created] (IGNITE-7191) JDBC: set socket buffer to 64k by default

[Alexey Popov (JIRA)]

Alexey Popov created IGNITE-7191:


 Summary: JDBC: set socket buffer to 64k by default
 Key: IGNITE-7191
 URL: https://issues.apache.org/jira/browse/IGNITE-7191
 Project: Ignite
  Issue Type: Improvement
  Components: jdbc
Affects Versions: 2.1
Reporter: Alexey Popov


TCP socket buffer size can significantly affect user-visible performance 
(actually, latency) for SQL queries, especially if Ignite cluster is run at the 
remote hosts. 
It is better to have 64k TCP socket buffer size (instead of default 8k) by 
default to avoid possible delays in TCP transport.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7190) Docker Hub official repository deployment

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-7190:


 Summary: Docker Hub official repository deployment
 Key: IGNITE-7190
 URL: https://issues.apache.org/jira/browse/IGNITE-7190
 Project: Ignite
  Issue Type: New Feature
Reporter: Peter Ivanov
Assignee: Peter Ivanov


Research possibility to integrate into Official Docker Hub Repositories.
Use 
https://docs.docker.com/docker-hub/official_repos/#how-do-i-create-a-new-official-repository
 as start.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7189) ODBC: ODBC return weird names for tables created with DDL

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-7189:
---

 Summary: ODBC: ODBC return weird names for tables created with DDL
 Key: IGNITE-7189
 URL: https://issues.apache.org/jira/browse/IGNITE-7189
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 2.3
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.4


If the table has been created by the {{CREATE TABLE}} statement, and then its 
metadata requested, returned names for tables are looking like the following:
{{SQL_PUBLIC_TABLE_NAME_00112233_4455_6677_8899_aabbccddeeff}}
Insetead of:
{{TABLE_NAME}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #3221: Ignite gg 13200

[apopovgg]

GitHub user apopovgg opened a pull request:

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

Ignite gg 13200



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

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

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

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


commit f1b9cdc0716a1b23f54d68ce0fe19eb85107567d
Author: Alexey Goncharuk 
Date:   2017-06-14T18:37:54Z

GG-12354: Partial fix of IGNITE-5473: Introduce troubleshooting logger.

commit beb2409cfe2045789443d47de735d879961d371e
Author: Andrey V. Mashenkov 
Date:   2017-06-23T09:26:06Z

GG-12352: Forcible node drop makes cluster instable in some cases.
Disable forcible node drop by default.

commit 802f18fc250cbae8959192c78bb28dc525ed3cf7
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Fix compilation

commit 39d2dec85a3c571dfdb1cd6189b53ae2413a5d22
Author: Andrey V. Mashenkov 
Date:   2017-06-23T10:41:30Z

Merge branch 'ignite-1.7.12-b2' into ignite-1.8.8

# Conflicts:
#   modules/core/src/main/java/org/apache/ignite/internal/GridTopic.java
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/communication/GridIoManager.java
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/communication/GridIoMessageFactory.java
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/communication/IgniteIoTestMessage.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheAdapter.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridDhtAtomicCache.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/task/GridTaskThreadContextKey.java
#   
modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java
#   
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteCacheTestSuite5.java

commit 96445156143b46b664f785b353463dd435ac342d
Author: Andrey V. Mashenkov 
Date:   2017-06-23T10:42:44Z

Merge remote-tracking branch 'origin/ignite-1.8.8' into ignite-1.8.8

# Conflicts:
#   
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteCacheTestSuite5.java

commit 7c569f15a80ab9301c21011d2c9159e311e46cef
Author: Andrey V. Mashenkov 
Date:   2017-06-23T10:48:10Z

Merge remote-tracking branch 'origin/ignite-1.8.7.p1' into ignite-1.8.8

commit a64339449be8fa602cab3f2868c5f74004a7b747
Author: Igor Sapego 
Date:   2017-06-23T13:57:49Z

IGNITE-4370: Implemented writing of batch of parameters for ODBC.

(cherry picked from commit c10be5780589cc84e7929e234e4411d515166e0b)
(cherry picked from commit d268b32cb252a5f06887d2b803d27ddc20ded95f)

commit cbe5df51c423568782e31245c7f1aa06c9ba3be1
Author: Igor Sapego 
Date:   2017-06-13T16:47:00Z

IGNITE-5478: ODBC: SQLNumParams now returns number of required parameters.

(cherry picked from commit b1c56a1)

(cherry picked from commit 4a8f295)

commit 9ad513e68b89e907f7db36a3f3f0daca0e5986e6
Author: Igor Sapego 
Date:   2017-06-23T14:06:40Z

IGNITE-5478: Fix for cherry pick

(cherry picked from commit a2a4ec1ee9794cb542f146a07c6c67002cad444e)

commit bfec212b1ece0e9e791de6dfb642324834fa77ca
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Partially reverted GG-12352.

commit 1abc14fdc4e39d8245c3e50fb2cf3d183df08021
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Partially reverted GG-12352.

commit cb95f7aa729fda19b4c3b7a5ada903a1e1bc2eab
Author: Andrey V. Mashenkov 
Date:   2017-06-23T16:08:00Z

Merge remote-tracking branch 'origin/ignite-1.7.12' into ignite-1.7.12

commit f59007f2c1221d8dd22abb0a9692b4abb31e87ad
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Partially reverted GG-12352.

commit 2c7d3c03cd36aee4f0985e674f550a62fc64d2db
Author: Andrey V. Mashenkov 
Date:   2017-06-23T17:11:00Z

Merge branch 'ignite-1.8.8' into ignite-1.9.4

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCachePreloaderAdapter.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtPartitionTopologyImpl.java
#   

[GitHub] ignite pull request #3220: IGNITE-4191

[gvvinblade]

GitHub user gvvinblade opened a pull request:

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

IGNITE-4191



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

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

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

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


commit f6e982540e65ab17d439dba990794f35616a30dd
Author: sboikov 
Date:   2017-08-30T09:45:40Z

ignite-3478

commit 275a85db5cd6923b36126166ae99b15e876192be
Author: sboikov 
Date:   2017-08-31T07:44:07Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit b7b9089f0102b8cab9942a9c887d93e9f26cc7d2
Author: sboikov 
Date:   2017-08-31T09:00:36Z

disco cache cleanup

commit 855c2d45794c300d41e386b4e6fa40736cc3e40d
Author: sboikov 
Date:   2017-08-31T09:09:58Z

Merge branch 'ignite-3478-1' into ignite-3478

commit 08be7310a93d3ce455215b97cf8ab1a2c3f0ab31
Author: sboikov 
Date:   2017-08-31T09:52:23Z

ignite-3478

commit fce2e31f0fd2f4f6a9944422e40408a0c65cfe90
Author: sboikov 
Date:   2017-09-04T08:13:50Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit d3c049952384750c5543a9f88b383c033ef74096
Author: sboikov 
Date:   2017-09-04T08:52:11Z

ignite-3478

commit e71ce1937a18dd32448e92b1038dc48d4cb6f8ab
Author: sboikov 
Date:   2017-09-04T10:16:03Z

ignite-3478

commit 5fac5b0965e97f8951e16e10ca9229a2e78ddb0c
Author: sboikov 
Date:   2017-09-05T10:16:44Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtTxPrepareFuture.java

commit 2e0c9c08e046e8d6af1b5358d9053eae999b1fb4
Author: sboikov 
Date:   2017-09-05T11:30:55Z

ignite-3478

commit e1e07ffdf2d711ba3e72f316f5a3970eff27372e
Author: sboikov 
Date:   2017-09-05T11:31:14Z

ignite-3478

commit cbada3934a386668da0b11d4de7d0f58a4d04dfe
Author: sboikov 
Date:   2017-09-05T11:49:49Z

ignite-3484

commit 5a82c68dcd1927bb6fded8b7def38c91ff6e145b
Author: sboikov 
Date:   2017-09-05T11:59:49Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit bc9134c94b7a738dc1664e96ca6eabb059f1c268
Author: sboikov 
Date:   2017-09-05T12:03:39Z

Merge branch 'ignite-3478' into ignite-3484

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/tree/AbstractDataInnerIO.java

commit b4bfcde78825c6517232e49d389bdb5de19f05a9
Author: sboikov 
Date:   2017-09-05T12:27:51Z

ignite-3484

commit 43834aaab9e2c3cd5fdd55289fdc4a9ff8ab6599
Author: sboikov 
Date:   2017-09-05T13:13:00Z

ignite-3478

commit d1b828095713fcadfa260cf94fef01b42a1b12fd
Author: sboikov 
Date:   2017-09-05T13:13:33Z

Merge branch 'ignite-3478' into ignite-3484

commit 6be6779b6336c36cd71eef0a25199a6a877ce6b5
Author: sboikov 
Date:   2017-09-05T13:47:11Z

ignite-3484

commit e3bba83256c1eb53c4b40fbd9ddba47fcf9d58d5
Author: sboikov 
Date:   2017-09-06T07:10:26Z

ignite-3484

commit dd0afb28466094b801506da8afa3601bfaebd853
Author: sboikov 
Date:   2017-09-06T07:30:04Z

ignite-3484

commit 27b87b413348b03986a463551db24b7726321732
Author: sboikov 
Date:   2017-09-06T08:19:18Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtTxPrepareFuture.java

commit dcaf8801accd6ee089849a82b2ccd558aec81895
Author: sboikov 
Date:   2017-09-06T08:19:30Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtTxPrepareFuture.java

commit c966451d0bf7059575de92bcfae43d72096ebce4
Author: sboikov 
Date:   2017-09-06T08:27:04Z

Merge branch 'ignite-3478' into ignite-3484

commit 91b9911731a387a3199ddbbc22704bc14af09995
Author: sboikov 
Date:   2017-09-06T09:22:22Z

ignite-3484

commit e40b4d9dcd6fe6c1cd2640bdd7116ca5a08ed781
Author: sboikov 
Date:   2017-09-07T09:12:32Z

ignite-3484

commit 41a1c571e6ba1765941e2f1679dc4ac1582275c4
Author: 

[GitHub] ignite pull request #3219: test baseline

[apopovgg]

GitHub user apopovgg opened a pull request:

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

test baseline



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

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

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

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


commit d427021f329292fb69d348ba949ad1f8f1e9089e
Author: Andrey V. Mashenkov 
Date:   2017-06-21T16:30:27Z

IGNITE-5552: ServiceProcessor recalculates all service assignments even if 
there is a pending topology change.

commit f1b9cdc0716a1b23f54d68ce0fe19eb85107567d
Author: Alexey Goncharuk 
Date:   2017-06-14T18:37:54Z

GG-12354: Partial fix of IGNITE-5473: Introduce troubleshooting logger.

commit beb2409cfe2045789443d47de735d879961d371e
Author: Andrey V. Mashenkov 
Date:   2017-06-23T09:26:06Z

GG-12352: Forcible node drop makes cluster instable in some cases.
Disable forcible node drop by default.

commit 802f18fc250cbae8959192c78bb28dc525ed3cf7
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Fix compilation

commit 39d2dec85a3c571dfdb1cd6189b53ae2413a5d22
Author: Andrey V. Mashenkov 
Date:   2017-06-23T10:41:30Z

Merge branch 'ignite-1.7.12-b2' into ignite-1.8.8

# Conflicts:
#   modules/core/src/main/java/org/apache/ignite/internal/GridTopic.java
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/communication/GridIoManager.java
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/communication/GridIoMessageFactory.java
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/communication/IgniteIoTestMessage.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheAdapter.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridDhtAtomicCache.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/task/GridTaskThreadContextKey.java
#   
modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java
#   
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteCacheTestSuite5.java

commit 96445156143b46b664f785b353463dd435ac342d
Author: Andrey V. Mashenkov 
Date:   2017-06-23T10:42:44Z

Merge remote-tracking branch 'origin/ignite-1.8.8' into ignite-1.8.8

# Conflicts:
#   
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteCacheTestSuite5.java

commit 7c569f15a80ab9301c21011d2c9159e311e46cef
Author: Andrey V. Mashenkov 
Date:   2017-06-23T10:48:10Z

Merge remote-tracking branch 'origin/ignite-1.8.7.p1' into ignite-1.8.8

commit a64339449be8fa602cab3f2868c5f74004a7b747
Author: Igor Sapego 
Date:   2017-06-23T13:57:49Z

IGNITE-4370: Implemented writing of batch of parameters for ODBC.

(cherry picked from commit c10be5780589cc84e7929e234e4411d515166e0b)
(cherry picked from commit d268b32cb252a5f06887d2b803d27ddc20ded95f)

commit cbe5df51c423568782e31245c7f1aa06c9ba3be1
Author: Igor Sapego 
Date:   2017-06-13T16:47:00Z

IGNITE-5478: ODBC: SQLNumParams now returns number of required parameters.

(cherry picked from commit b1c56a1)

(cherry picked from commit 4a8f295)

commit 9ad513e68b89e907f7db36a3f3f0daca0e5986e6
Author: Igor Sapego 
Date:   2017-06-23T14:06:40Z

IGNITE-5478: Fix for cherry pick

(cherry picked from commit a2a4ec1ee9794cb542f146a07c6c67002cad444e)

commit bfec212b1ece0e9e791de6dfb642324834fa77ca
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Partially reverted GG-12352.

commit 1abc14fdc4e39d8245c3e50fb2cf3d183df08021
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Partially reverted GG-12352.

commit cb95f7aa729fda19b4c3b7a5ada903a1e1bc2eab
Author: Andrey V. Mashenkov 
Date:   2017-06-23T16:08:00Z

Merge remote-tracking branch 'origin/ignite-1.7.12' into ignite-1.7.12

commit f59007f2c1221d8dd22abb0a9692b4abb31e87ad
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Partially reverted GG-12352.

commit 2c7d3c03cd36aee4f0985e674f550a62fc64d2db
Author: Andrey V. Mashenkov 
Date:   2017-06-23T17:11:00Z

Merge branch 'ignite-1.8.8' into ignite-1.9.4

# Conflicts:
#   

[jira] [Created] (IGNITE-7187) SQL TX: Near caches support

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-7187:


 Summary: SQL TX: Near caches support
 Key: IGNITE-7187
 URL: https://issues.apache.org/jira/browse/IGNITE-7187
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Igor Seliverstov


Currently near readers don't participate in SQL transactions, we need to notify 
near readers on updates.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7188) SQL TX: Retry strategy on lock conflicts

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-7188:


 Summary: SQL TX: Retry strategy on lock conflicts
 Key: IGNITE-7188
 URL: https://issues.apache.org/jira/browse/IGNITE-7188
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Igor Seliverstov


We need to provide some strategy to avoid lock conflicts (deadlocks), detect 
and hanle them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7186) SQL TX: Updates on backup nodes/Replicated caches support

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-7186:


 Summary: SQL TX: Updates on backup nodes/Replicated caches support
 Key: IGNITE-7186
 URL: https://issues.apache.org/jira/browse/IGNITE-7186
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Igor Seliverstov


Current TX implementation implies update backup partitions at the tx prepare 
state sending set of keys and update values from primary nodes. This approach 
works fine for Key-Value store but produces issues when we run SQL update 
without WHERE clause on a table of billions rows. We need to process somehow 
primary and backups partitions at the same time using mainly local query 
results.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7184) SQL TX: Support optimistic transactions

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-7184:


 Summary: SQL TX: Support optimistic transactions
 Key: IGNITE-7184
 URL: https://issues.apache.org/jira/browse/IGNITE-7184
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Igor Seliverstov


Support optimistic transactions



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7185) SQL TX: Updates during rebalancing.

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-7185:


 Summary: SQL TX: Updates during rebalancing.
 Key: IGNITE-7185
 URL: https://issues.apache.org/jira/browse/IGNITE-7185
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Igor Seliverstov


Crrently we map an update operation to data nodes and perform it on all the 
nodes simultaneously. It works fine on stable topology but produces many issues 
if the operation happens at the rebalance time because we cannot query data 
properly if some partitions are in moving state.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7183) SQL TX: Implicit transactions

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-7183:


 Summary: SQL TX: Implicit transactions
 Key: IGNITE-7183
 URL: https://issues.apache.org/jira/browse/IGNITE-7183
 Project: Ignite
  Issue Type: Task
Reporter: Igor Seliverstov


Implicit transaction has to be started on any SQL update in a transactional 
cache.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #3218: IGNITE-7079: Add examples for kNN classification ...

[zaleslaw]

GitHub user zaleslaw opened a pull request:

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

IGNITE-7079: Add examples for kNN classification and for kNN regression

1. Added two examples
2. Improved LabeledDataset
3. Added tests for these improvements.
4. Added helper class to split the given dataset on test and train subsets.

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

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

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

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


commit 2cb4f5f3da67ad077f837eeeda11baf44c101245
Author: zaleslaw 
Date:   2017-11-14T12:47:29Z

Refactored keys

commit 462719fef2364cd2aded23bb32edf4d0a53b9d7f
Author: zaleslaw 
Date:   2017-11-14T12:47:51Z

Added tests

commit c180c8c60a1b43a516cd7a045420bc1dc16adcdd
Author: zaleslaw 
Date:   2017-11-14T12:48:14Z

Added vectors

commit 39766ed0bfdb9a95118b7e0c59ec39a441307c0e
Author: zaleslaw 
Date:   2017-11-14T12:48:43Z

Refactored storages and matrices

commit b9deec6d3f71db8da45800ad8a6f0ec560a25294
Author: zaleslaw 
Date:   2017-11-14T12:49:11Z

Fixed issues with keys

commit 3dbbb20efccbc85bf8022b34935096d5310c9554
Author: zaleslaw 
Date:   2017-11-14T18:25:14Z

Added kNN classifier draft

commit 41ee88add4ebc31efa7a4e903ff4d78d92bd2e8a
Author: zaleslaw 
Date:   2017-11-15T16:59:44Z

Added loading from file

commit 68c82c7f3ac3c220f52f76ce0057032bc55b33fe
Author: zaleslaw 
Date:   2017-11-15T18:56:48Z

Added kNN regression draft

commit 552d9af6d9ec0ca5156a7b84457c93dc896946e3
Author: zaleslaw 
Date:   2017-11-16T11:28:41Z

Added different distances

commit b84d1b6ae284edaa510f7eefa84f5594dd1cb83e
Author: zaleslaw 
Date:   2017-11-17T14:44:05Z

Removed incorrect patch

commit 401a464c6bde19bbf1f11d0d32a2aea9facc
Author: zaleslaw 
Date:   2017-11-17T15:11:09Z

Added OLS Distributed support

commit a003cc22902afa2fdfcb1d90a29d07ff936a13be
Author: Zinoviev Alexey 
Date:   2017-11-21T16:32:25Z

Fix codestyle

commit 29014354df79f2ff6e46542420030c0f091566fc
Author: Zinoviev Alexey 
Date:   2017-11-26T14:01:39Z

Merge branch 'master' into ignite-6880

commit 12f081969baa25c49b0c55f74e3551c113ebb8d8
Author: Zinoviev Alexey 
Date:   2017-11-26T15:17:25Z

Added distances and test for them

commit 8a1cc76ed63c4d72a76af37423d8a197eafd6f31
Author: Zinoviev Alexey 
Date:   2017-11-27T15:44:41Z

Added LabeledDataset

commit 754208280ee929df8c317eb15c0a3071a63dc6f5
Author: Zinoviev Alexey 
Date:   2017-11-28T15:34:01Z

Added tests

commit c5c37304929d67aa9722d701d9b40b976198b812
Author: Zinoviev Alexey 
Date:   2017-11-28T15:52:53Z

Added tests

commit d282042fb4625159f65629fe1a9efa0e25831195
Author: Zinoviev Alexey 
Date:   2017-11-28T16:29:27Z

Added normalization

commit 52749bc9bcfe2d9ad50b92b0f392e2baa4a505f1
Author: Zinoviev Alexey 
Date:   2017-11-29T16:04:05Z

Added code style

commit ed78a89cf59d07de2781c755749ea97e041f8839
Author: Zinoviev Alexey 
Date:   2017-11-30T11:30:07Z

Added code style

commit 663a8e1a1ea875cfa8e7b31652a7aa7ec1acd668
Author: Zinoviev Alexey 
Date:   2017-11-30T11:36:08Z

Added code style

commit 7d22bcd33fcea3a7588c46368b5289d5b306db7f
Author: Zinoviev Alexey 
Date:   2017-12-07T11:01:43Z

Merge from master

commit 7a1ac3f3c10eeaa5f96b8ebba5a54aa6cced4e29
Author: Zinoviev Alexey 
Date:   2017-12-07T11:26:10Z

Merge branch 'master' into ignite-6880

commit 367e114b210e17e5dd1415db3ad162b932d830fa
Author: Zinoviev Alexey 
Date:   2017-12-07T14:12:22Z

Fixed comments

commit b304deb349a95a8d2f9e62cd53465824a85a13bf
Author: zaleslaw 
Date:   2017-12-08T10:43:08Z

Merge branch 'master' of https://github.com/apache/ignite

commit e3a4667ba40ff81c2e99d68ed2d93461b488b8dd
Author: zaleslaw 
Date:   2017-12-08T11:02:54Z

Merge branch 'master' into ignite-6880

commit 5069fcb7aa6510806c1ee60e0dbcfaf59d746091
Author: zaleslaw 
Date:   2017-12-08T11:15:49Z

Merge branch 'master' into ignite-6880

commit 879f750159ba2971e3ec96ca204e1797e4ed8817
Author: zaleslaw 
Date:  

[jira] [Created] (IGNITE-7182) Long sorting of pages collection on checkpoint begin can cause zero dropdown even with throttling enabled

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-7182:
--

 Summary: Long sorting of pages collection on checkpoint begin can 
cause zero dropdown even with throttling enabled
 Key: IGNITE-7182
 URL: https://issues.apache.org/jira/browse/IGNITE-7182
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Affects Versions: 2.3
Reporter: Ivan Rakov
Assignee: Dmitriy Pavlov
 Fix For: 2.4


Tests show that GridCacheDatabaseSharedManager#splitAndSortCpPagesIfNeeded call 
can last several seconds on nodes with big amount af memory (>10GB). We should 
optimize sorting algorithm, possibly making it multithreaded.
Another option to make pages write throttling more smooth is to get rid of this 
heuristic:
{noformat}
// Starting with 0.05 to avoid throttle right after checkpoint 
start
// 7/12 is maximum ratio of dirty pages
dirtyRatioThreshold = (dirtyRatioThreshold * 0.95 + 0.05) * 7 / 
12;
{noformat}
We should replace "magic" lower bound 0.05 * 7 / 12 with the real percentage of 
dirty pages at the moment of 
GridCacheDatabaseSharedManager.Checkpointer#markCheckpointBegin call return.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #3115: IGNITE-6423: PDS could be corrupted if partition ...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3217: IGNITE-7181 - Fix IGNITE-7086 doesn't work with P...

[dkarachentsev]

GitHub user dkarachentsev opened a pull request:

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

IGNITE-7181 - Fix IGNITE-7086 doesn't work with PESSIMISTIC REPEATABL…

…E_READ transaction

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

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

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

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


commit 13e9625e0821b74d8017d36ce84cd2f602283019
Author: dkarachentsev 
Date:   2017-12-13T11:06:57Z

IGNITE-7181 - Fix IGNITE-7086 doesn't work with PESSIMISTIC REPEATABLE_READ 
transaction




---

Rework locking architecture for MVCC and transactional SQL

[Vladimir Ozerov]

Igniters,

As you probably we know we work actively on MVCC [1] and transactional SQL
[2] features which could be treated as a single huge improvement. We face a
number of challenges and one of them is locking.

At the moment information about all locks is kept in memory on per-entry
basis (see GridCacheMvccManager). For every locked key we maintain current
lock owner (XID) and the list of would-be-owner transactions. When
transaction is about to lock an entry two scenarios are possible:
1) If entry is not locked we obtain the lock immediately
2) if entry is locked we add current transaction to the wait list and jumps
to the next entry to be locked. Once the first entry is released by
conflicting transaction, current transaction becomes an owner of the first
entry and tries to promote itself for subsequent entries.

Once all required locks are obtained, response is sent to the caller.

This approach doesn't work well for transactional SQL - if we update
millions of rows in a single transaction we will simply run out of memory.
To mitigate the problem other database vendors keep information about locks
inside the tuples. I propose to apply the similar design as follows:

1) No per-entry lock information is stored in memory anymore.
2) The list of active transactions are maintained in memory still
3) When TX locks an entry, it sets special marker to the tuple [3]
4) When TX meets already locked entry, it enlists itself to wait queue of
conflicting transaction and suspends
5) When first transaction releases conflicting lock, it notifies and wakes
up suspended transactions, so they resume locking
6) Entry lock data is cleared on transaction commit
7) Entry lock data is not cleared on rollback or node restart; Instead, we
will could use active transactions list to identify invalid locks and
overwrite them as needed.

Also we could try employing tiered approach
1) Try to keep everything in-memory to minimize writes to blocks
2) Fallback to persistent lock data if certain threshold is reached.

Thoughts?

[1] https://issues.apache.org/jira/browse/IGNITE-3478
[2] https://issues.apache.org/jira/browse/IGNITE-4191
[3] Depends on final MVCC design - it could be per-tuple XID, undo vectors,
per-block transaction lists, etc..

Vladimir.

IGNITE-1025 is ready for review (Need to print out warning if IP finder has a lot of addresses on Windows)

[Иван Федотов]

Hi, Igniters!
I've prepared PR [1] for the issue IGNITE-1025 "Need to print out warning
if IP finder has a lot of addresses on Windows" [2] . TeamCity tests look
good [3]. Could someone review it?
Thanks in advance!

[1]https://github.com/apache/ignite/pull/2966
[2]https://issues.apache.org/jira/browse/IGNITE-1025
[3]
https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=8753246349372607337=testDetails_Ignite20Tests=pull%2F2966%2Fhead

-- 
Ivan Fedotov.

ivanan...@gmail.com

[jira] [Created] (IGNITE-7181) Fix IGNITE-7086 doesn't work with PESSIMISTIC REPEATABLE_READ transaction

[Dmitry Karachentsev (JIRA)]

Dmitry Karachentsev created IGNITE-7181:
---

 Summary: Fix IGNITE-7086 doesn't work with PESSIMISTIC 
REPEATABLE_READ transaction
 Key: IGNITE-7181
 URL: https://issues.apache.org/jira/browse/IGNITE-7181
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitry Karachentsev
Assignee: Dmitry Karachentsev






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: IGNITE-4447 ready for review

[Дмитрий Рябов]

Hello.

Semyon, test passed.

PR (squashed and merged with master): https://github.com/apache/ignite/pull/3204
CI tests: 
https://ci.ignite.apache.org/viewLog.html?buildId=993439=buildResultsDiv=Ignite20Tests_IgniteCache5

2017-05-19 4:46 GMT+03:00 Вадим Опольский :
> Hi guys!
>
> Semyon, test suite Ignite Cache 5 with Cache150ClientsTest failed. Run it
> twice. But local it succesfully executed. What do you think about it ?
>
> http://ci.ignite.apache.org/viewLog.html?buildId=616787=buildResultsDiv=IgniteTests_IgniteCache5
>
> Vadim
>
> 2017-05-17 11:34 GMT+03:00 Вадим Опольский :
>
>> Hi Semyon!
>>
>> I had problem with starting TC test yesterday. Just have queued it -
>> http://ci.ignite.apache.org/project.html?projectId=IgniteTests_
>> IgniteTests=pull%2F1952%2Fmerge
>>
>> Vadim
>>
>> 2017-05-16 14:10 GMT+03:00 Semyon Boikov :
>>
>>> Hi Vadim,
>>>
>>> Did you check test pass on TeamCity in this suite, could you please
>>> provide
>>> link for related TeamCity run?
>>>
>>> Thanks
>>>
>>> On Tue, May 16, 2017 at 1:35 PM, Вадим Опольский 
>>> wrote:
>>>
>>> > Hi guys!
>>> >
>>> > IgniteCache150ClientsTest.java was removed from
>>> > IgniteClientTestSuite.java to IgniteCacheTestSuite.java. Single test
>>> suite
>>> > was deleted.
>>> >
>>> > Review please this fix - https://github.com/apache/ignite/pull/1952
>>> >
>>> > Vadim Opolskii
>>> >
>>> >
>>> >
>>> > 2017-05-15 11:38 GMT+03:00 Вадим Опольский :
>>> >
>>> > > Hi guys!
>>> > >
>>> > > Vladimir, is issue https://issues.apache.org/jira/browse/IGNITE-4447
>>> > > actual now?
>>> > >
>>> > > Which tests do u mean? Detail please.
>>> > >
>>> > > Vadim
>>> > >
>>> >
>>>
>>
>>

[jira] [Created] (IGNITE-7180) ODBC: add possibility to configure more than one address in connection string

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-7180:
-

 Summary: ODBC: add possibility to configure more than one address 
in connection string
 Key: IGNITE-7180
 URL: https://issues.apache.org/jira/browse/IGNITE-7180
 Project: Ignite
  Issue Type: Improvement
  Components: odbc
Affects Versions: 2.3
Reporter: Evgenii Zhuravlev
Assignee: Igor Sapego






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)