Re: jdbc vs jdbc2 packages

[Denis Magda]

Val, Igniters,

I still believe the thin client has a right for living. It’s ideal for use 
cases when someone attempts to connect to Ignite from a tool or some sort of 
interface and query the data or update it in non transactional fashion. A 
TCP/IP address as a connection string to the cluster is ideal for this scenario.

If someone decides to use JDBC programmatically and leverage from transactions 
then he will switch to the JDBC versions that starts a client node with a 
passed Ignite configuration.

How do you like this?

In general, it sounds like a right movement to replace REST with more flexible 
and, probably, unified protocol for thin client based JDBC implementation. But 
what if we extend REST a bit (supporting pagination for SELECTs and DML) at the 
first phase so that the thin client driver can be used right away in the 
scenarios I listed above? The rest of optimizations can be done after that.

—
Denis

> On Mar 23, 2017, at 7:24 PM, Valentin Kulichenko 
>  wrote:
> 
> I'm against keeping legacy thin client because:
> 
> - Having two ways to configure driver is unnecessary complication and very
> bad from usability standpoint.
> - It is much slower than client node, performance was the main driver
> behind its deprecation.
> 
> What we should do, is improve usability of the client node, this will be
> good improvement not only for JDBC driver. The list of required changes was
> covered earlier in the thread, I will check if we have tickets for all of
> them and provide a list.
> 
> -Val
> 
> On Thu, Mar 16, 2017 at 1:02 AM, Dmitriy Setrakyan 
> wrote:
> 
>> Denis, I completely agree that we should have a thin JDBC client. Can you
>> file a ticket?
>> 
>> On Wed, Mar 15, 2017 at 4:58 PM, Denis Magda  wrote:
>> 
>>> Frankly, during these two a couple of day I had a chance to play with Web
>>> Console and Ignite JDBC driver.
>>> 
>>> As many other users I referred to JDBC documentation in order to setup
>> the
>>> driver properly. However, then due to the recently reported issue I fell
>>> back to JDBC v 1 (thin client based):
>>> https://issues.apache.org/jira/browse/IGNITE-4829 <
>>> https://issues.apache.org/jira/browse/IGNITE-4829>
>>> 
>>> I was amazed how swift JDBC v 1 and sluggish JDBC v 2 which is default.
>>> Unfortunately, JDBC v 1 doesn’t support DML this is why I had hard time
>>> finding out a workaround for IGNITE-4829. But, in any case I fully
>> support
>>> reincarnation of JDBC v 1.
>>> 
>>> *Val*, as one of the most experienced folks who participated in this
>>> discussion, would you mind wrapping the discussion up in a form of a
>> ticket
>>> listing the design proposal?
>>> 
>>> —
>>> Denis
>>> 
 On Feb 10, 2017, at 4:47 PM, Dmitriy Setrakyan 
>>> wrote:
 
 I generally like the idea of supporting thin JDBC clients. Often it is
>>> not
 feasible to start a client node on JDBC side.
 
 On Fri, Feb 10, 2017 at 1:04 PM, Valentin Kulichenko <
 valentin.kuliche...@gmail.com> wrote:
 
> Yakov,
> 
> There are two separate aspects that we can improve:
> 
> 1. Message routing as you described. I agree it can be useful in some
> scenarios and I definitely not against this feature, but honestly I
>>> haven't
> seen a lot of requests for this so far.
> 2. Server can initiate connection with client. This really blows
>> users's
> minds :)
> 
> I only meant that the latter is much more critical in my view.
>>> Configuring
> port forwarding on the cluster can be complicated, but it absolutely
>>> makes
> sense, while doing the same on client just sounds crazy. Client should
>>> be
> able to just connect, without having public IP and without additional
> configuration on the router.
> 
> -Val
> 
> On Fri, Feb 10, 2017 at 1:58 AM, Yakov Zhdanov 
> wrote:
> 
>> Val, can you please explain your statement. You suggest users have
>> port
>> forwarding for dozens of nodes in their topologies so client can
>>> initiate
>> connect to any of them? I don't think this is possible and routing
>>> seems
> to
>> be the only possible option.
>> 
>> --Yakov
>> 
>> 2017-02-10 0:04 GMT+03:00 Valentin Kulichenko <
>> valentin.kuliche...@gmail.com
>>> :
>> 
>>> Yakov,
>>> 
>>> 1. Yes, I will file a ticket.
>>> 
>>> 4. I meant that server can currently initiate connection with
>> client,
> and
>>> that's the main problem here. Is there a way to avoid this? Message
>> routing
>>> you're referring to can also be useful in some cases, but much less
>>> critical.
>>> 
>>> -Val
>>> 
>>> On Wed, Feb 8, 2017 at 9:20 PM, Yakov Zhdanov <
>> yzhda...@gridgain.com>
>>> wrote:
>>> 
 Val,
 
 1. Our clients should stop require persistent store implementation

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

[Denis Magda]

Maxim, Andrey G., Igniters,

What if go further and remove CacheAtomicWriteOrderMode enum from the public 
API at all? I see no sense to keep it for the only one option left - PRIMARY.

Any objections?

—
Denis

> On Feb 27, 2017, at 8:09 AM, Kozlov Maxim  wrote:
> 
> Hi Igniters,
> 
> After remove CLOCK mode, CacheAtomicWriteOrderMode enum contains now only one 
> value PRIMARY. Andrey Gura, proposition remove CacheAtomicWriteOrderMode 
> enum. Will there be something special for this purpose is enum?
> 
> jira: https://issues.apache.org/jira/browse/IGNITE-4587 
> 
> 
> --
> Best Regards,
> Max K.
> 
> 
> 
> 

Re: ignite-3592 is ready fo review (Provide some kind of pluggable compression SPI support)

[Denis Magda]

Sergi, Vovan,

As SQL and binary marshaller maintainers could you plan to review the 
contribution?

—
Denis

> On Mar 29, 2017, at 4:44 PM, Vyacheslav Daradur  wrote:
> 
>> At which point does this step take place? Do we deserialize right when we
>> receive the object over the wire?
> When put it in cache, after marshalling.
> Covered by properly configured existing tests. [1][2][3]
> 
> 
>> Forgive me if I don't know the internals, but does this happen when SQL
>> queries are executed?
> Yes. Covered by tests[4]
> 
> [1]
> https://github.com/apache/ignite/pull/1650/files#diff-af9e2960a6c9f73fa56a5b3824b6b397
> [2]
> https://github.com/apache/ignite/pull/1650/files#diff-ed2aa7d56ed004ae9bc975edc9b8a9c2
> ]3]
> https://github.com/apache/ignite/pull/1650/files#diff-a4b76c24a5f9bc9e78d7cff0a7645328
> [4]
> https://github.com/apache/ignite/pull/1650/files#diff-c19a9df4058141d059bb577e75244764
> 
> 2017-03-29 23:16 GMT+03:00 Dmitriy Setrakyan :
> 
>> On Wed, Mar 29, 2017 at 11:57 AM, Vyacheslav Daradur 
>> wrote:
>> 
>>> Queries works with BinaryObjectImpl.
>>> 
>>> 1. In the full compression mode - compressed bytes sequence - will be
>>> decompressed at initialization of BinaryObjectImpl.
>>> 
>> 
>> At which point does this step take place? Do we deserialize right when we
>> receive the object over the wire?
>> 
>> 
>>> 2. With annotated fields compression - value of compressed fields will be
>>> decompress at deserializing on demand, for example when calls methods
>>> BinaryObjectImpl#field and BinaryObjectImpl#fieldByOrder
>>> 
>> 
>> Forgive me if I don't know the internals, but does this happen when SQL
>> queries are executed?
>> 
>> 
>>> 
>>> 2017-03-29 21:47 GMT+03:00 Dmitriy Setrakyan :
>>> 
 On Wed, Mar 29, 2017 at 11:44 AM, Vyacheslav Daradur <
>>> daradu...@gmail.com>
 wrote:
 
> Solution implemented in core-level and works with binary-marshaller.
> 
> If you about the cache queries - it works with compressed data.
> 
 
 Vyacheslav, can you please explain how the cache queries work with the
 compressed data?
 
>>> 
>>> 
>>> 
>>> --
>>> Best Regards, Vyacheslav
>>> 
>> 
> 
> 
> 
> -- 
> Best Regards, Vyacheslav

Re: Making News page more visible

[Denis Magda]

Prachi, as one of the site maintainers, would you mind contributing this?

Denis

On Wednesday, March 29, 2017, Tom Diederich 
wrote:

> Thanks, Denis! I agree that an anchor would make sense. Also really like
> the
> idea to add the social icons to make sharing fast and easy.
>
>
>
> --
> View this message in context: http://apache-ignite-
> developers.2346864.n4.nabble.com/Making-News-page-more-
> visible-tp15763p15927.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>

[GitHub] ignite pull request #1617: ignite-4141 JDBC driver should always set withKee...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Making News page more visible

[Tom Diederich]

Thanks, Denis! I agree that an anchor would make sense. Also really like the
idea to add the social icons to make sharing fast and easy. 



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Making-News-page-more-visible-tp15763p15927.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: ignite-3592 is ready fo review (Provide some kind of pluggable compression SPI support)

[Vyacheslav Daradur]

> At which point does this step take place? Do we deserialize right when we
> receive the object over the wire?
When put it in cache, after marshalling.
Covered by properly configured existing tests. [1][2][3]


> Forgive me if I don't know the internals, but does this happen when SQL
> queries are executed?
Yes. Covered by tests[4]

[1]
https://github.com/apache/ignite/pull/1650/files#diff-af9e2960a6c9f73fa56a5b3824b6b397
[2]
https://github.com/apache/ignite/pull/1650/files#diff-ed2aa7d56ed004ae9bc975edc9b8a9c2
]3]
https://github.com/apache/ignite/pull/1650/files#diff-a4b76c24a5f9bc9e78d7cff0a7645328
[4]
https://github.com/apache/ignite/pull/1650/files#diff-c19a9df4058141d059bb577e75244764

2017-03-29 23:16 GMT+03:00 Dmitriy Setrakyan :

> On Wed, Mar 29, 2017 at 11:57 AM, Vyacheslav Daradur 
> wrote:
>
> > Queries works with BinaryObjectImpl.
> >
> > 1. In the full compression mode - compressed bytes sequence - will be
> > decompressed at initialization of BinaryObjectImpl.
> >
>
> At which point does this step take place? Do we deserialize right when we
>  receive the object over the wire?
>
>
> > 2. With annotated fields compression - value of compressed fields will be
> > decompress at deserializing on demand, for example when calls methods
> > BinaryObjectImpl#field and BinaryObjectImpl#fieldByOrder
> >
>
> Forgive me if I don't know the internals, but does this happen when SQL
> queries are executed?
>
>
> >
> > 2017-03-29 21:47 GMT+03:00 Dmitriy Setrakyan :
> >
> > > On Wed, Mar 29, 2017 at 11:44 AM, Vyacheslav Daradur <
> > daradu...@gmail.com>
> > > wrote:
> > >
> > > > Solution implemented in core-level and works with binary-marshaller.
> > > >
> > > > If you about the cache queries - it works with compressed data.
> > > >
> > >
> > > Vyacheslav, can you please explain how the cache queries work with the
> > > compressed data?
> > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav
> >
>



-- 
Best Regards, Vyacheslav

Re: ignite-3592 is ready fo review (Provide some kind of pluggable compression SPI support)

[Dmitriy Setrakyan]

On Wed, Mar 29, 2017 at 11:57 AM, Vyacheslav Daradur 
wrote:

> Queries works with BinaryObjectImpl.
>
> 1. In the full compression mode - compressed bytes sequence - will be
> decompressed at initialization of BinaryObjectImpl.
>

At which point does this step take place? Do we deserialize right when we
 receive the object over the wire?


> 2. With annotated fields compression - value of compressed fields will be
> decompress at deserializing on demand, for example when calls methods
> BinaryObjectImpl#field and BinaryObjectImpl#fieldByOrder
>

Forgive me if I don't know the internals, but does this happen when SQL
queries are executed?


>
> 2017-03-29 21:47 GMT+03:00 Dmitriy Setrakyan :
>
> > On Wed, Mar 29, 2017 at 11:44 AM, Vyacheslav Daradur <
> daradu...@gmail.com>
> > wrote:
> >
> > > Solution implemented in core-level and works with binary-marshaller.
> > >
> > > If you about the cache queries - it works with compressed data.
> > >
> >
> > Vyacheslav, can you please explain how the cache queries work with the
> > compressed data?
> >
>
>
>
> --
> Best Regards, Vyacheslav
>

Re: Stable binary key representation

[Valentin Kulichenko]

I'm not saying there is no alternative solution. But let's implement it and
prove that it works first, and remove resolvers only after that.

-Val

On Wed, Mar 29, 2017 at 12:18 PM, Sergi Vladykin 
wrote:

> Guys, nothing is impossible if you know a bit about reflection in Java :)
>
> We had a look at the CacheKey class and it is easily replaceable.
>
> Sergi
>
>
>
> 2017-03-29 21:49 GMT+03:00 Dmitriy Setrakyan :
>
> > On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > "Hibernate key" is the CacheKey class I was referring to. It's provided
> > by
> > > Hibernate, not by user and not by us. So I'm not sure it's possible to
> > > replace it.
> > >
> >
> > If it is impossible to replace or get rid of the Hibernate key, is this
> > discussion valid at all?
> >
>

Re: Stable binary key representation

[Sergi Vladykin]

Guys, nothing is impossible if you know a bit about reflection in Java :)

We had a look at the CacheKey class and it is easily replaceable.

Sergi



2017-03-29 21:49 GMT+03:00 Dmitriy Setrakyan :

> On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > "Hibernate key" is the CacheKey class I was referring to. It's provided
> by
> > Hibernate, not by user and not by us. So I'm not sure it's possible to
> > replace it.
> >
>
> If it is impossible to replace or get rid of the Hibernate key, is this
> discussion valid at all?
>

Re: ignite-3592 is ready fo review (Provide some kind of pluggable compression SPI support)

[Vyacheslav Daradur]

Queries works with BinaryObjectImpl.

1. In the full compression mode - compressed bytes sequence - will be
decompressed at initialization of BinaryObjectImpl.

2. With annotated fields compression - value of compressed fields will be
decompress at deserializing on demand, for example when calls methods
BinaryObjectImpl#field and BinaryObjectImpl#fieldByOrder

2017-03-29 21:47 GMT+03:00 Dmitriy Setrakyan :

> On Wed, Mar 29, 2017 at 11:44 AM, Vyacheslav Daradur 
> wrote:
>
> > Solution implemented in core-level and works with binary-marshaller.
> >
> > If you about the cache queries - it works with compressed data.
> >
>
> Vyacheslav, can you please explain how the cache queries work with the
> compressed data?
>



-- 
Best Regards, Vyacheslav

Re: Stable binary key representation

[Dmitriy Setrakyan]

On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> "Hibernate key" is the CacheKey class I was referring to. It's provided by
> Hibernate, not by user and not by us. So I'm not sure it's possible to
> replace it.
>

If it is impossible to replace or get rid of the Hibernate key, is this
discussion valid at all?

Re: ignite-3592 is ready fo review (Provide some kind of pluggable compression SPI support)

[Dmitriy Setrakyan]

On Wed, Mar 29, 2017 at 11:44 AM, Vyacheslav Daradur 
wrote:

> Solution implemented in core-level and works with binary-marshaller.
>
> If you about the cache queries - it works with compressed data.
>

Vyacheslav, can you please explain how the cache queries work with the
compressed data?

Re: ignite-3592 is ready fo review (Provide some kind of pluggable compression SPI support)

[Vyacheslav Daradur]

Solution implemented in core-level and works with binary-marshaller.

If you about the cache queries - it works with compressed data.

2017-03-29 21:42 GMT+03:00 Dmitriy Setrakyan :

> On Wed, Mar 29, 2017 at 10:56 AM, Denis Magda  wrote:
>
> > Hello Vyacheslav, thanks for your efforts.
> >
> > Is there any special support for SQL? In the original discussion [1]
> > around this task the folks expressed several concerns about compression
> > usefulness w/o the ability to execute SQL queries over compressed data.
> In
> > general it makes sense to run the discussion in [1].
> >
> > [1] http://apache-ignite-developers.2346864.n4.nabble.
> > com/Data-compression-in-Ignite-2-0-td10099.html  > developers.2346864.n4.nabble.com/Data-compression-in-
> > Ignite-2-0-td10099.html>
> >
>
> I second Denis' concern. Compression is very useful, but we must be able to
> use SQL queries on the compressed data. One way would be to make sure that
> the indexes are not compressed, which would mean that we have to decompress
> the value to update indexes, or do the reverse - compress it only after we
> update the indexes.
>
> Sergi, what do you think?
>



-- 
Best Regards, Vyacheslav

Re: Stable binary key representation

[Valentin Kulichenko]

"Hibernate key" is the CacheKey class I was referring to. It's provided by
Hibernate, not by user and not by us. So I'm not sure it's possible to
replace it.

-Val

On Wed, Mar 29, 2017 at 11:36 AM, Dmitriy Setrakyan 
wrote:

> Alexey,
>
> Can you explain what is the "Hibernate key" and what is a "correct key
> class"? Are you suggesting that currently we don't require our users
> interested in Hibernate integration to provide a "correct key class"?
>
> D.
>
> On Wed, Mar 29, 2017 at 9:08 AM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > Guys,
> >
> > I stumbled across this ticket [1] and it seems to me that the whole
> > approach of identity resolvers is error-prone. If a key contains some
> data
> > that does not participate in equals() calculation, these fields may be as
> > well moved to the value object. Even with binary objects, key mutation
> > looks like an error-prone approach.
> >
> > I suggest we remove identity resolver in Ignite 2.0 and ask a user to
> > provide a correct implementation of a key. For the Hibernate
> integration, I
> > think a correct fix would be to replace the Hibernate key with another
> > correct key class.
> >
> > Thoughts?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-3429
> >
>

Re: ignite-3592 is ready fo review (Provide some kind of pluggable compression SPI support)

[Dmitriy Setrakyan]

On Wed, Mar 29, 2017 at 10:56 AM, Denis Magda  wrote:

> Hello Vyacheslav, thanks for your efforts.
>
> Is there any special support for SQL? In the original discussion [1]
> around this task the folks expressed several concerns about compression
> usefulness w/o the ability to execute SQL queries over compressed data. In
> general it makes sense to run the discussion in [1].
>
> [1] http://apache-ignite-developers.2346864.n4.nabble.
> com/Data-compression-in-Ignite-2-0-td10099.html  developers.2346864.n4.nabble.com/Data-compression-in-
> Ignite-2-0-td10099.html>
>

I second Denis' concern. Compression is very useful, but we must be able to
use SQL queries on the compressed data. One way would be to make sure that
the indexes are not compressed, which would mean that we have to decompress
the value to update indexes, or do the reverse - compress it only after we
update the indexes.

Sergi, what do you think?

Re: Stable binary key representation

[Valentin Kulichenko]

Alex,

How do you suggest to replace the CacheKey class? It's internal for
Hibernate and I'm not sure it's possible.

-Val

On Wed, Mar 29, 2017 at 11:09 AM, Denis Magda  wrote:

> I’m not sure we can simply discontinue the identity resolvers that were
> originally created for DML. *Vovan*, *Alex Paschenko*, please chime in and
> provide your thoughts. Don’t want us to make such decisions in haste.
>
> Alex G., in any case, assuming that the resolvers are still in 2.0 is
> there any other reason why we can’t leverage from them in our code in order
> to fix the mentioned Hibernate bug.
>
> —
> Denis
>
> > On Mar 29, 2017, at 10:38 AM, Sergi Vladykin 
> wrote:
> >
> > It looks like a good idea to drop identity resolvers for now and require
> > stable binary representation for keys in 2.0. Later if it will be really
> > needed we will be able to add them back.
> >
> > Sergi
> >
> > 2017-03-29 19:08 GMT+03:00 Alexey Goncharuk  >:
> >
> >> Guys,
> >>
> >> I stumbled across this ticket [1] and it seems to me that the whole
> >> approach of identity resolvers is error-prone. If a key contains some
> data
> >> that does not participate in equals() calculation, these fields may be
> as
> >> well moved to the value object. Even with binary objects, key mutation
> >> looks like an error-prone approach.
> >>
> >> I suggest we remove identity resolver in Ignite 2.0 and ask a user to
> >> provide a correct implementation of a key. For the Hibernate
> integration, I
> >> think a correct fix would be to replace the Hibernate key with another
> >> correct key class.
> >>
> >> Thoughts?
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-3429
> >>
>
>

Re: Stable binary key representation

[Denis Magda]

I’m not sure we can simply discontinue the identity resolvers that were 
originally created for DML. *Vovan*, *Alex Paschenko*, please chime in and 
provide your thoughts. Don’t want us to make such decisions in haste.

Alex G., in any case, assuming that the resolvers are still in 2.0 is there any 
other reason why we can’t leverage from them in our code in order to fix the 
mentioned Hibernate bug.

—
Denis

> On Mar 29, 2017, at 10:38 AM, Sergi Vladykin  wrote:
> 
> It looks like a good idea to drop identity resolvers for now and require
> stable binary representation for keys in 2.0. Later if it will be really
> needed we will be able to add them back.
> 
> Sergi
> 
> 2017-03-29 19:08 GMT+03:00 Alexey Goncharuk :
> 
>> Guys,
>> 
>> I stumbled across this ticket [1] and it seems to me that the whole
>> approach of identity resolvers is error-prone. If a key contains some data
>> that does not participate in equals() calculation, these fields may be as
>> well moved to the value object. Even with binary objects, key mutation
>> looks like an error-prone approach.
>> 
>> I suggest we remove identity resolver in Ignite 2.0 and ask a user to
>> provide a correct implementation of a key. For the Hibernate integration, I
>> think a correct fix would be to replace the Hibernate key with another
>> correct key class.
>> 
>> Thoughts?
>> 
>> [1] https://issues.apache.org/jira/browse/IGNITE-3429
>> 

Re: IGNITE-4188, savepoints with atomic cache?

[Denis Magda]

Sorry, I get lost in tickets.

Yes, IGNITE-2313 has to be completed in 2.0 if we want to makes this change.

—
Denis

> On Mar 29, 2017, at 2:12 AM, Дмитрий Рябов  wrote:
> 
> Savepoints marked for 2.1, exceptions for 2.0. Do you want me to make
> exceptions first?
> 
> 2017-03-29 11:24 GMT+03:00 Дмитрий Рябов :
> 
>> Finish savepoints or flag for atomic operations?
>> Not sure about savepoints. Exceptions - yes. https://issues.apache.
>> org/jira/browse/IGNITE-2313 isn't it?
>> 
>> 2017-03-29 2:12 GMT+03:00 Denis Magda :
>> 
>>> If we want to make the exception based approach the default one then the
>>> task has to be released in 2.0.
>>> 
>>> Dmitriy Ryabov, do you think you can finish it (dev, review, QA) by the
>>> code freeze data (April 14)?
>>> 
>>> —
>>> Denis
>>> 
 On Mar 28, 2017, at 11:57 AM, Dmitriy Setrakyan 
>>> wrote:
 
 On Tue, Mar 28, 2017 at 11:54 AM, Sergi Vladykin <
>>> sergi.vlady...@gmail.com>
 wrote:
 
> I think updating an Atomic cache from within a transaction perfectly
>>> makes
> sense. For example for some kind of operations logging and so forth.
>>> Still
> I agree that this can be error prone and forbidden by default. I agree
>>> with
> Yakov that by default we should throw an exception and have some kind
>>> of
> flag (on cache or on TX?) to be able to explicitly enable this
>>> behavior.
> 
 
 
 Agree, this sounds like a good idea.
>>> 
>>> 
>> 

Re: ignite-3592 is ready fo review (Provide some kind of pluggable compression SPI support)

[Denis Magda]

Hello Vyacheslav, thanks for your efforts.

Is there any special support for SQL? In the original discussion [1] around 
this task the folks expressed several concerns about compression usefulness w/o 
the ability to execute SQL queries over compressed data. In general it makes 
sense to run the discussion in [1].

[1] 
http://apache-ignite-developers.2346864.n4.nabble.com/Data-compression-in-Ignite-2-0-td10099.html
 


—
Denis

> On Mar 29, 2017, at 1:32 AM, Vyacheslav Daradur  wrote:
> 
> Hello everyone.
> 
> https://issues.apache.org/jira/browse/IGNITE-3592 is ready for review.
> ci.tests [1] look good.
> Upsource review was created.[2]
> 
> Solution provides 2 way to use compression.
> 1. Full compression mode.
> Switches in the IgniteConfiguration#fullCompressionMode field.
> Full compression means all data (metadata+value) of whole object will be
> compress at the end of marshalling.
> 
> 2. Annotated fields compression.
> Values of fields annotated by @BinaryCompression annotation will be
> compress at marshalling.
> Only value, header of whole object will not be compress.
> 
> There is an opportunity to use user compressor.
> It configures in the IgniteConfiguration#compressor field.
> There is the Compressor interface which user can implement.
> 
> Default implementation is using GZIP lib.
> There is one more implementation which use ZLIB  compression library
> (Deflater).
> 
> Also there is the more flexible version [3] with parameterized annotations,
> when we have several compressors and can choose them at runtime.
> But such freedom can provides many problems.
> 
> Feel free to contact me for fixes and improvements.
> 
> [1] http://ci.ignite.apache.org/viewLog.html?buildId=520503
> [2] http://reviews.ignite.apache.org/ignite/review/IGNT-CR-143
> [3]
> https://github.com/apache/ignite/pull/1650/commits/c7cf273d46bfe52fa57f1e296f3e649012b18572
> 
> -- 
> Best Regards, Vyacheslav

Re: Stable binary key representation

[Sergi Vladykin]

It looks like a good idea to drop identity resolvers for now and require
stable binary representation for keys in 2.0. Later if it will be really
needed we will be able to add them back.

Sergi

2017-03-29 19:08 GMT+03:00 Alexey Goncharuk :

> Guys,
>
> I stumbled across this ticket [1] and it seems to me that the whole
> approach of identity resolvers is error-prone. If a key contains some data
> that does not participate in equals() calculation, these fields may be as
> well moved to the value object. Even with binary objects, key mutation
> looks like an error-prone approach.
>
> I suggest we remove identity resolver in Ignite 2.0 and ask a user to
> provide a correct implementation of a key. For the Hibernate integration, I
> think a correct fix would be to replace the Hibernate key with another
> correct key class.
>
> Thoughts?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-3429
>

Re: putting entity into cache while commiting.Why!?

[Alexander Fedotov]

Hello Aleksey,

No, the enlisted entry won't be visible for other transactions. Dirty reads
are not allowed in Ignite.

Kind regards,
Alex

29 марта 2017 г. 7:36 PM пользователь "ALEKSEY KUZNETSOV" <
alkuznetsov...@gmail.com> написал:

Hello, Igniters! I have one more question to you. Will appreciate any help.
Consider cache with near , dht configured not null.
When we start commit transaction , in method
*org.apache.ignite.internal.processors.cache.distributed.
near.GridNearTxLocal#enlistWriteEntry*
we put newly created entry into cache by executing entryEx().
I wonder if this entry will became visible for other transactions!?
--

*Best Regards,*

*Kuznetsov Aleksey*

Re: IGNITE-2766 Spring Cache Manager ReConnect Issue

[Valentin Kulichenko]

Hi Rishi,

I will review in next couple of days.

-Val

On Tue, Mar 28, 2017 at 8:24 PM, Rishi Yagnik  wrote:

> Hi Val,
>
> Committed changes on IGNITE-2786, would like you to review the
> changes.Would you please review it ?
>
> Thanks,
>
> On Mon, Mar 27, 2017 at 6:11 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Rishi,
> >
> > You should be able to assign to tickets to yourself now.
> >
> > -Val
> >
> > On Mon, Mar 27, 2017 at 1:23 PM, Rishi Yagnik 
> > wrote:
> >
> > > Hi Val,
> > >
> > > My user name is ryagnik
> > >
> > > Thanks,
> > > Rishi
> > >
> > > On Mon, Mar 27, 2017 at 12:14 PM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Hi Rishi,
> > > >
> > > > What is your username in Jira? I will add you as a contributor.
> > > >
> > > > Also please go through [1] and [2] for all the details about our
> > process.
> > > >
> > > > [1] https://ignite.apache.org/community/contribute.html#contribute
> > > > [2] https://cwiki.apache.org/confluence/display/IGNITE/
> > > Development+Process
> > > >
> > > > -Val
> > > >
> > > > On Sun, Mar 26, 2017 at 5:56 PM, Rishi Yagnik  >
> > > > wrote:
> > > >
> > > > > Hi Val,
> > > > >
> > > > > I started working on it but could not assign issue to me, how do I
> > > assign
> > > > > ticket to my self ?
> > > > >
> > > > > Do I need contributor access to contribute the fix ?
> > > > >
> > > > > Please clarify..
> > > > >
> > > > > Thanks,
> > > > >
> > > > > On Fri, Mar 24, 2017 at 12:10 AM, Rishi Yagnik <
> > rishiyag...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Val,
> > > > > >
> > > > > > Sorry for the delay, I will work on the fix on weekend.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > >
> > > > > > On Mon, Mar 13, 2017 at 12:08 PM, Rishi Yagnik <
> > > rishiyag...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > >> Hi Val,
> > > > > >>
> > > > > >> I will work on it in my spare time..
> > > > > >>
> > > > > >> Take Care,
> > > > > >> Rishi
> > > > > >>
> > > > > >> > On Mar 13, 2017, at 10:54 AM, Valentin Kulichenko <
> > > > > >> valentin.kuliche...@gmail.com> wrote:
> > > > > >> >
> > > > > >> > Hi Rishi,
> > > > > >> >
> > > > > >> > Can you please assign the ticket to yourself and create a pull
> > > > request
> > > > > >> as
> > > > > >> > described in [1]?
> > > > > >> >
> > > > > >> > Let's follow the process :)
> > > > > >> >
> > > > > >> > [1] https://cwiki.apache.org/confluence/display/IGNITE/How+
> to+
> > > > > >> Contribute
> > > > > >> >
> > > > > >> > -Val
> > > > > >> >
> > > > > >> > On Sun, Mar 12, 2017 at 2:04 AM, ignite_dev2017 <
> > > > > rishiyag...@gmail.com>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> >> Hi Val,
> > > > > >> >>
> > > > > >> >> The fix which we applied as follows with SpringCacheManager -
> > > > > >> >>
> > > > > >> >> 1) Design was to listen for ignite re connect event
> > > > > >> >> 2) And clear the cache on reconnect
> > > > > >> >>
> > > > > >> >> See the following code below and let us know if this is
> > helpful -
> > > > > >> >>
> > > > > >> >> In afterPropertiesSet -
> > > > > >> >>
> > > > > >> >> //Handles the reconnect event, on server crashes OR network
> > > > failure,
> > > > > >> client
> > > > > >> >> connects to server and
> > > > > >> >>// destroy the cache
> > > > > >> >>IgnitePredicate lsnr = iEvt -> {
> > > > > >> >>LOGGER.info("Received discovery event [iEvt=" +
> > > > > iEvt.name()
> > > > > >> +
> > > > > >> >> ",
> > > > > >> >> discovery=" + iEvt.shortDisplay() + ']');
> > > > > >> >>
> > > > > >> >>caches.keySet().forEach(key -> {
> > > > > >> >>ignite.destroyCache(key);
> > > > > >> >>caches.remove(key);
> > > > > >> >>} );
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> Let me know if you see any side effects with the fix.
> > > > > >> >>
> > > > > >> >> Thanks,
> > > > > >> >> Rishi
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> --
> > > > > >> >> View this message in context: http://apache-ignite-
> > > > > >> >> developers.2346864.n4.nabble.com/IGNITE-2766-Spring-Cache-
> > > > > >> >> Manager-ReConnect-Issue-tp15362.html
> > > > > >> >> Sent from the Apache Ignite Developers mailing list archive
> at
> > > > > >> Nabble.com.
> > > > > >> >>
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Rishi Yagnik
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Rishi Yagnik
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Rishi Yagnik
> > >
> >
>
>
>
> --
> Rishi Yagnik
>

putting entity into cache while commiting.Why!?

[ALEKSEY KUZNETSOV]

Hello, Igniters! I have one more question to you. Will appreciate any help.
Consider cache with near , dht configured not null.
When we start commit transaction , in method
*org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal#enlistWriteEntry*
we put newly created entry into cache by executing entryEx().
I wonder if this entry will became visible for other transactions!?
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #1665: IGNITE-4617: Added field-access methods for Binar...

[isapego]

Github user isapego closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Stable binary key representation

[Alexey Goncharuk]

Guys,

I stumbled across this ticket [1] and it seems to me that the whole
approach of identity resolvers is error-prone. If a key contains some data
that does not participate in equals() calculation, these fields may be as
well moved to the value object. Even with binary objects, key mutation
looks like an error-prone approach.

I suggest we remove identity resolver in Ignite 2.0 and ask a user to
provide a correct implementation of a key. For the Hibernate integration, I
think a correct fix would be to replace the Hibernate key with another
correct key class.

Thoughts?

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

[jira] [Created] (IGNITE-4881) REPLICATED cache size is wrong after node left topology.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-4881:


 Summary: REPLICATED cache size is wrong after node left topology.
 Key: IGNITE-4881
 URL: https://issues.apache.org/jira/browse/IGNITE-4881
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.7
Reporter: Andrew Mashenkov
 Fix For: 2.0


After one of nodes leave topology, cache.size() returns wrong value until first 
write attempt.

PFA repro. Successfully reproduced on 1.7-1.9 and master.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Adding ML to Ignite, IGNITE-4572

[alpercakan]

Thank you for your reply. I will be watching this thread.

However, GSOC applications are due Monday. So, some suggestions for what to
write on the proposal would be great, if pull request will be later than
Monday. 



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Adding-ML-to-Ignite-IGNITE-4572-tp13936p15902.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: Adding ML to Ignite, IGNITE-4572

[nivanov]

Alper - we are very close to "pull request" our preliminary work into ignite
2.0 (finger crossed it will make it into it). Once we have it available in
the main ignite 2.0 branch there will be plenty of interesting tasks to
tackle. Stay tuned on this thread!



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Adding-ML-to-Ignite-IGNITE-4572-tp13936p15901.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

[GitHub] ignite pull request #1693: Ignite 4876

[kdudkov]

GitHub user kdudkov opened a pull request:

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

Ignite 4876



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

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

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

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


commit be36a49d374d25a4a4a2042304f3e63e4327c5b1
Author: Konstantin Dudkov 
Date:   2017-03-29T13:55:19Z

ignite-4876

commit b180b659e74b37f90d9193b7cf877d007c9bfe79
Author: Konstantin Dudkov 
Date:   2017-03-29T14:25:07Z

ignite-4876




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Getting Started with Apache Ignite - Part 1

[Dani Traphagen]

Fantastic guidance, I'll register on IMC - thanks Denis.
On Tue, Mar 28, 2017 at 4:22 PM Denis Magda  wrote:

> Dani, excellent job!
>
> *Prachi*, could you publish the article to DZone and update Ignite’s
> blogging page? Since this will be a series of posts don’t add DZone version
> of the article to Ignite’s page but rather add a link to the Dani’s own
> blog right away.
>
> *Dani*, to give more visibility to your work I would suggest registering
> your blog on IMC Planned aggregator:
> https://www.imcplanet.org 
>
> —
> Denis
>
> > On Mar 28, 2017, at 11:42 AM, Dani Traphagen  wrote:
> >
> > Hi Igniters,
> >
> > I'm working on a multi-part series on working with Apache Ignite and just
> > released my first post today.
> > 
> >
> > This first post gives a conceptual basis to working with Ignite while
> > follow up posts will work with code samples. Enjoy!
> >
> > Here's a direct link to the post: Getting Started to Apache Ignite -
> Part 1.
> > 
> >
> > Cheers,
> > Dani
> > --
> > Dani Traphagen | d...@gridgain.com
> > Solutions Architect
> > *GridGain*
>
> --
Dani Traphagen | d...@gridgain.com
Solutions Architect
*GridGain*

[GitHub] ignite pull request #1692: Ignite-4878

[endian675]

GitHub user endian675 opened a pull request:

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

Ignite-4878

Replace conns collection with ConcurrentLinkedDeque to avoid possible 
concurrent modification exception

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

$ git pull https://github.com/endian675/ignite ignite-4878-1

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

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


commit 744df0ff21711951820f8aea8f3fc846a6f137e3
Author: Michael Griggs 
Date:   2017-03-29T14:03:36Z

IGNITE-4878: replace Synchronized collection with ConcurrentLinkedDeque, to 
avoid popssible concurrent modification exception




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-4880) .NET: Rename Impl types

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4880:
--

 Summary: .NET: Rename Impl types
 Key: IGNITE-4880
 URL: https://issues.apache.org/jira/browse/IGNITE-4880
 Project: Ignite
  Issue Type: Improvement
Reporter: Pavel Tupitsyn


According to {{CA1711: Identifiers should not have incorrect suffix}} rule 
(https://msdn.microsoft.com/en-us/library/ms182247.aspx), {{Core}} suffix  
should be used instead of {{Impl}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #1689: IGNITE-4847

[endian675]

Github user endian675 closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-4879) System pool starvation while partition evicting.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-4879:


 Summary: System pool starvation while partition evicting.
 Key: IGNITE-4879
 URL: https://issues.apache.org/jira/browse/IGNITE-4879
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.7
Reporter: Andrew Mashenkov
Priority: Critical
 Fix For: 2.0


Some system pool threads is waiting for others made partition eviction.
We should change partition eviction in async way, to allow only one thread do 
useful job without blocking other threads.

Startpoint is clearAll() call in GridDhtLocalPartition.tryEvict() method.
TryEvict method is called synchronously during few basic operations that can 
stuck unexpectedly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4878) IgniteH2Indexing can throw java.util.ConcurrentModificationException

[Michael Griggs (JIRA)]

Michael Griggs created IGNITE-4878:
--

 Summary: IgniteH2Indexing can throw 
java.util.ConcurrentModificationException
 Key: IGNITE-4878
 URL: https://issues.apache.org/jira/browse/IGNITE-4878
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.9
Reporter: Michael Griggs
Assignee: Michael Griggs


>From the Collections#synchronizedCollection method:

{noformat}
 * It is imperative that the user manually synchronize on the returned
 * collection when traversing it via {@link Iterator}, {@link Spliterator}
 * or {@link Stream}:
 * 
 *  Collection c = Collections.synchronizedCollection(myCollection);
 * ...
 *  synchronized (c) {
 *  Iterator i = c.iterator(); // Must be in the synchronized block
 *  while (i.hasNext())
 * foo(i.next());
 *  }
 * 
 * Failure to follow this advice may result in non-deterministic behavior.
{noformat}




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4877) Add test covers get(key, type) in direct way (via SpringCache)

[Vyacheslav Daradur (JIRA)]

Vyacheslav Daradur created IGNITE-4877:
--

 Summary: Add test covers get(key, type) in direct way (via 
SpringCache)
 Key: IGNITE-4877
 URL: https://issues.apache.org/jira/browse/IGNITE-4877
 Project: Ignite
  Issue Type: Test
Reporter: Vyacheslav Daradur
Assignee: Vyacheslav Daradur
 Fix For: 2.0






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: IGNITE-4052 ready for review

[Nikolai Tikhonov]

Thank you for your contribution! Please, don't forget to move ticket in
"path available" state.

On Wed, Mar 29, 2017 at 10:46 AM, Вадим Опольский 
wrote:

> Hello everybody!
>
> Nikolay, the properties for mesos role and JUnit test were added.
>
> Review please the pull request - https://github.com/apache/igni
> te/pull/1662
>
> Vadim Opolski
>
> 2017-03-24 18:41 GMT+03:00 Nikolai Tikhonov :
>
>> Great! Looking forward to the contribution.
>>
>> On Fri, Mar 24, 2017 at 3:54 PM, Вадим Опольский 
>> wrote:
>>
>>> Nikolay, I will add properties for mesos role and unit test next week.
>>>
>>> -- Forwarded message --
>>> From: Вадим Опольский 
>>> Date: 2017-03-22 15:53 GMT+03:00
>>> Subject: Re: IGNITE-4052 ready for review
>>> To: dev@ignite.apache.org
>>>
>>>
>>> Nikolay, just changed status to "path available".
>>>
>>> 2017-03-22 15:44 GMT+03:00 Nikolai Tikhonov :
>>>
 Hi Вадим!

 Thank you for your contribution!
 Please change status of the ticket to "path available". I'll review your
 changes.

 Thanks,
 Nikolay

 On Wed, Mar 22, 2017 at 3:36 PM, Вадим Опольский 
 wrote:

 > Hello everybody!
 >
 > Nikolay,
 >  review please https://github.com/apache/ignite/pull/1662 .
 >
 > Added ability to configure current user parameters via system env
 > properties - "MESOS_USER".
 >
 > Vadim Opolski
 >
 >
 > -- Forwarded message --
 > From: Вадим Опольский 
 > Date: 2017-03-21 14:40 GMT+03:00
 > Subject: Assignee IGNITE-4052
 > To: dev@ignite.apache.org
 >
 >
 > Dear sirs !
 >
 > I want to resolve issue IGNITE-4052.
 >
 > https://issues.apache.org/jira/browse/IGNITE-4052
 >
 > Is it actual ?
 >
 > Vadim Opolski
 >
 >

>>>
>>>
>>>
>>
>

[GitHub] ignite pull request #1691: Ignite 4284 1.8.5

[dkarachentsev]

GitHub user dkarachentsev opened a pull request:

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

Ignite 4284 1.8.5



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

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

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

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


commit 9c6824b4f33fbdead64299d9e0c34365d5d4a570
Author: nikolay_tikhonov 
Date:   2016-11-24T13:27:05Z

IGNITE-3958 Fixed "Client node should not start rest processor".

commit 56998e704e9a67760c70481c10c56e72c0a866bb
Author: Konstantin Dudkov 
Date:   2016-10-28T13:27:34Z

ignite-4088 Added methods to create/destroy multiple caches. This closes 
#1174.

(cherry picked from commit f445e7b)

commit 3e2ccfd30427ba0552eea8667c0129ae5ace9c0b
Author: Igor Sapego 
Date:   2016-11-25T11:26:54Z

IGNITE-4299: Fixes for examples.

commit 6fbaef45af8f40062a95058df7ec0984c99035b9
Author: Konstantin Dudkov 
Date:   2016-11-25T10:58:58Z

IGNITE-4305 marshalling fix in GridNearAtomicSingleUpdateInvokeRequest

commit 1a2de51f5807a91ce0d5dff28f24ed5bf7abebbc
Author: Konstantin Dudkov 
Date:   2016-11-28T09:59:02Z

IGNITE-4305 marshalling fix

commit c06e4017771603df7118974758d3d6b9cadc41b5
Author: Eduard Shangareev 
Date:   2016-11-30T11:34:47Z

ignite-4332 Usage of cache.getEntry inside GridCacheQueryManager.runQuery 
causes to remote operations

commit 066691098797be8c01daa0e8dc2ba94d4ad73561
Author: sboikov 
Date:   2016-12-01T14:16:28Z

ignite-4344 Do not create offheap map on client nodes.

commit e9ace7730773a6d4a1d30b271854f1fe8a7ba632
Author: Alexey Kuznetsov 
Date:   2016-12-02T09:06:41Z

Improved exception handling.

commit 12bdd6a031a33eda004a66e73cee9628f073ed68
Author: Alexey Kuznetsov 
Date:   2016-12-02T09:09:29Z

Updated classnames.properties for running nodes in IDE.

commit 33dda46061aae73e5c138851cfdd5f49a1c254cb
Author: sboikov 
Date:   2016-12-02T09:13:38Z

ignite-4285 For serializable txs allow multiple threads to get read lock 
for the same key

commit cc13d9d155f70e22e08ef203ac64e5cc0aa0a50f
Author: dkarachentsev 
Date:   2016-11-28T08:30:14Z

IGNITE-4026: Fixed BinaryObjectBuilder.build() can fail if one of the 
fields is Externalizable, enum from binary object. This closes #1281. This 
closes #1289.

(cherry picked from commit 0b7c62d)

commit b4aedfd5350b4a318f1608596a171789513835a4
Author: Igor Sapego 
Date:   2016-12-02T17:10:09Z

IGNITE-4347: Fixed NPE.

commit acf20b32d8fb68e42b904b091fb2b943f4558cef
Author: sboikov 
Date:   2016-12-05T11:01:28Z

ignite-4296 Optimize GridDhtPartitionsSingleMessage processing
- optimized processing of GridDhtPartitionsSingleMessage
- minor optimizations for RendezvousAffinityFunction
 - fixed heartbeats sending in tcp discovery

commit 6ba1711a1fa10d8276974227491136070c3ed43a
Author: Anton Vinogradov 
Date:   2016-12-06T09:55:41Z

IGNITE-4242 ExchangeManager should wait for cache rebalancing in async way

commit 3df412e7f25aac8227b68cffe1577593a05d1431
Author: sboikov 
Date:   2016-12-07T09:25:32Z

ignite-2545 Optimization for GridCompoundFuture's futures iteration

commit f3db74f782c68c7f73ef3ef4390e010976493634
Author: Anton Vinogradov 
Date:   2016-12-07T10:15:37Z

IGNITE-4238: Added geospatial queries example (nolgpl examples hotfix)

commit 0d4a1b7381fece47ee480f3a06bff7c51a7fead4
Author: Alexey Kuznetsov 
Date:   2016-12-07T11:02:49Z

Improved exception handling for failed queries.

commit 56efb10c40fd4481d6a9dc00928e7beee1f164c5
Author: Anton Vinogradov 
Date:   2016-12-07T11:25:53Z

IGNITE-4353 Parent Cassandra module deployed on maven repository (hotfix: 
deploy to custom maven repository)

commit ac8602dbdf2bbf5b16a611eaf6d520a0a7b0010b
Author: Sergi Vladykin 
Date:   2016-08-15T13:46:54Z

ignite-3685 - fixed

commit bbaa79af8ef526b5d2684db0e3d71d60a8f1ebe7
Author: agura 
Date:   2016-12-07T16:36:11Z

IGNITE-3770 GridLogThrottle.warn ignores the exception

commit 18598574bb2992aa193eed1d72ca333a1e21ad72
Author: Andrey V. Mashenkov 
Date:   2016-12-08T09:36:07Z

GG-11746: Backport of IGNITE-4379:  Fixed broken local SqlFieldsQuery.

commit 671a77a2d81cac401765dddf25f30fba4e4ab17f
Author: sboikov 
Date:   2016-12-08T09:56:46Z

Re: [GridCachePartitionExchangeManager] Pending transaction deadlock detection futures

[Alexey Kuznetsov]

Val,

>> Does anyone have an idea why client mode in Visor affects behavior? I
thought we already forced client mode there, no?

Visor CMD was NOT reworked to client mode.
So Visor CMD starts server node in daemon mode.


On Wed, Mar 29, 2017 at 2:28 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> cross-posting to dev list.
>
> Guys,
>
> Does anyone have an idea why client mode in Visor affects behavior? I
> thought we already forced client mode there, no?
>
> Alexey, you should know the answer. Can you please take a look at this
> thread?
>
> -Val
>
>
> On Tue, Mar 28, 2017 at 7:02 AM, ght230  wrote:
>
>> Yes,I use custom build.
>>
>> Today I tried to set Ignition.setClientMode(true) for command "open" of
>> the
>> visorcmd.
>>
>> It seems the visorcmd will not stuck the whole cluster again.
>>
>> Is there anything wrong in "ClientMode" of the visorcmd?
>>
>>
>>
>> --
>> View this message in context: http://apache-ignite-users.705
>> 18.x6.nabble.com/GridCachePartitionExchangeManager-Pending-t
>> ransaction-deadlock-detection-futures-tp11362p11501.html
>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>
>
>


-- 
Alexey Kuznetsov

[jira] [Created] (IGNITE-4876) Tests: node stop should wait for cluster to see actual topology version

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-4876:


 Summary: Tests: node stop should wait for cluster to see actual 
topology version
 Key: IGNITE-4876
 URL: https://issues.apache.org/jira/browse/IGNITE-4876
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Goncharuk






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

serializable tx prepare future

[ALEKSEY KUZNETSOV]

Hi all !
In GridNearTxLocal while preparing phase in optimistic mode :
*org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal#prepareNearTxLocal*
 we check serializable() and create
GridNearOptimisticSerializableTxPrepareFuture
What is the point of serializable future ?
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: IGNITE-4188, savepoints with atomic cache?

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

Savepoints marked for 2.1, exceptions for 2.0. Do you want me to make
exceptions first?

2017-03-29 11:24 GMT+03:00 Дмитрий Рябов :

> Finish savepoints or flag for atomic operations?
> Not sure about savepoints. Exceptions - yes. https://issues.apache.
> org/jira/browse/IGNITE-2313 isn't it?
>
> 2017-03-29 2:12 GMT+03:00 Denis Magda :
>
>> If we want to make the exception based approach the default one then the
>> task has to be released in 2.0.
>>
>> Dmitriy Ryabov, do you think you can finish it (dev, review, QA) by the
>> code freeze data (April 14)?
>>
>> —
>> Denis
>>
>> > On Mar 28, 2017, at 11:57 AM, Dmitriy Setrakyan 
>> wrote:
>> >
>> > On Tue, Mar 28, 2017 at 11:54 AM, Sergi Vladykin <
>> sergi.vlady...@gmail.com>
>> > wrote:
>> >
>> >> I think updating an Atomic cache from within a transaction perfectly
>> makes
>> >> sense. For example for some kind of operations logging and so forth.
>> Still
>> >> I agree that this can be error prone and forbidden by default. I agree
>> with
>> >> Yakov that by default we should throw an exception and have some kind
>> of
>> >> flag (on cache or on TX?) to be able to explicitly enable this
>> behavior.
>> >>
>> >
>> >
>> > Agree, this sounds like a good idea.
>>
>>
>

[GitHub] ignite pull request #1690: Ignite 1.8.5

[dkarachentsev]

GitHub user dkarachentsev opened a pull request:

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

Ignite 1.8.5



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

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

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

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


commit 9c6824b4f33fbdead64299d9e0c34365d5d4a570
Author: nikolay_tikhonov 
Date:   2016-11-24T13:27:05Z

IGNITE-3958 Fixed "Client node should not start rest processor".

commit 56998e704e9a67760c70481c10c56e72c0a866bb
Author: Konstantin Dudkov 
Date:   2016-10-28T13:27:34Z

ignite-4088 Added methods to create/destroy multiple caches. This closes 
#1174.

(cherry picked from commit f445e7b)

commit 3e2ccfd30427ba0552eea8667c0129ae5ace9c0b
Author: Igor Sapego 
Date:   2016-11-25T11:26:54Z

IGNITE-4299: Fixes for examples.

commit 6fbaef45af8f40062a95058df7ec0984c99035b9
Author: Konstantin Dudkov 
Date:   2016-11-25T10:58:58Z

IGNITE-4305 marshalling fix in GridNearAtomicSingleUpdateInvokeRequest

commit 1a2de51f5807a91ce0d5dff28f24ed5bf7abebbc
Author: Konstantin Dudkov 
Date:   2016-11-28T09:59:02Z

IGNITE-4305 marshalling fix

commit c06e4017771603df7118974758d3d6b9cadc41b5
Author: Eduard Shangareev 
Date:   2016-11-30T11:34:47Z

ignite-4332 Usage of cache.getEntry inside GridCacheQueryManager.runQuery 
causes to remote operations

commit 066691098797be8c01daa0e8dc2ba94d4ad73561
Author: sboikov 
Date:   2016-12-01T14:16:28Z

ignite-4344 Do not create offheap map on client nodes.

commit e9ace7730773a6d4a1d30b271854f1fe8a7ba632
Author: Alexey Kuznetsov 
Date:   2016-12-02T09:06:41Z

Improved exception handling.

commit 12bdd6a031a33eda004a66e73cee9628f073ed68
Author: Alexey Kuznetsov 
Date:   2016-12-02T09:09:29Z

Updated classnames.properties for running nodes in IDE.

commit 33dda46061aae73e5c138851cfdd5f49a1c254cb
Author: sboikov 
Date:   2016-12-02T09:13:38Z

ignite-4285 For serializable txs allow multiple threads to get read lock 
for the same key

commit cc13d9d155f70e22e08ef203ac64e5cc0aa0a50f
Author: dkarachentsev 
Date:   2016-11-28T08:30:14Z

IGNITE-4026: Fixed BinaryObjectBuilder.build() can fail if one of the 
fields is Externalizable, enum from binary object. This closes #1281. This 
closes #1289.

(cherry picked from commit 0b7c62d)

commit b4aedfd5350b4a318f1608596a171789513835a4
Author: Igor Sapego 
Date:   2016-12-02T17:10:09Z

IGNITE-4347: Fixed NPE.

commit acf20b32d8fb68e42b904b091fb2b943f4558cef
Author: sboikov 
Date:   2016-12-05T11:01:28Z

ignite-4296 Optimize GridDhtPartitionsSingleMessage processing
- optimized processing of GridDhtPartitionsSingleMessage
- minor optimizations for RendezvousAffinityFunction
 - fixed heartbeats sending in tcp discovery

commit 6ba1711a1fa10d8276974227491136070c3ed43a
Author: Anton Vinogradov 
Date:   2016-12-06T09:55:41Z

IGNITE-4242 ExchangeManager should wait for cache rebalancing in async way

commit 3df412e7f25aac8227b68cffe1577593a05d1431
Author: sboikov 
Date:   2016-12-07T09:25:32Z

ignite-2545 Optimization for GridCompoundFuture's futures iteration

commit f3db74f782c68c7f73ef3ef4390e010976493634
Author: Anton Vinogradov 
Date:   2016-12-07T10:15:37Z

IGNITE-4238: Added geospatial queries example (nolgpl examples hotfix)

commit 0d4a1b7381fece47ee480f3a06bff7c51a7fead4
Author: Alexey Kuznetsov 
Date:   2016-12-07T11:02:49Z

Improved exception handling for failed queries.

commit 56efb10c40fd4481d6a9dc00928e7beee1f164c5
Author: Anton Vinogradov 
Date:   2016-12-07T11:25:53Z

IGNITE-4353 Parent Cassandra module deployed on maven repository (hotfix: 
deploy to custom maven repository)

commit ac8602dbdf2bbf5b16a611eaf6d520a0a7b0010b
Author: Sergi Vladykin 
Date:   2016-08-15T13:46:54Z

ignite-3685 - fixed

commit bbaa79af8ef526b5d2684db0e3d71d60a8f1ebe7
Author: agura 
Date:   2016-12-07T16:36:11Z

IGNITE-3770 GridLogThrottle.warn ignores the exception

commit 18598574bb2992aa193eed1d72ca333a1e21ad72
Author: Andrey V. Mashenkov 
Date:   2016-12-08T09:36:07Z

GG-11746: Backport of IGNITE-4379:  Fixed broken local SqlFieldsQuery.

commit 671a77a2d81cac401765dddf25f30fba4e4ab17f
Author: sboikov 
Date:   2016-12-08T09:56:46Z

ignite-4154 Fixed 

ignite-3592 is ready fo review (Provide some kind of pluggable compression SPI support)

[Vyacheslav Daradur]

Hello everyone.

https://issues.apache.org/jira/browse/IGNITE-3592 is ready for review.
ci.tests [1] look good.
Upsource review was created.[2]

Solution provides 2 way to use compression.
1. Full compression mode.
Switches in the IgniteConfiguration#fullCompressionMode field.
Full compression means all data (metadata+value) of whole object will be
compress at the end of marshalling.

2. Annotated fields compression.
Values of fields annotated by @BinaryCompression annotation will be
compress at marshalling.
Only value, header of whole object will not be compress.

There is an opportunity to use user compressor.
It configures in the IgniteConfiguration#compressor field.
There is the Compressor interface which user can implement.

Default implementation is using GZIP lib.
There is one more implementation which use ZLIB  compression library
(Deflater).

Also there is the more flexible version [3] with parameterized annotations,
when we have several compressors and can choose them at runtime.
But such freedom can provides many problems.

Feel free to contact me for fixes and improvements.

[1] http://ci.ignite.apache.org/viewLog.html?buildId=520503
[2] http://reviews.ignite.apache.org/ignite/review/IGNT-CR-143
[3]
https://github.com/apache/ignite/pull/1650/commits/c7cf273d46bfe52fa57f1e296f3e649012b18572

-- 
Best Regards, Vyacheslav

Re: IGNITE-4188, savepoints with atomic cache?

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

Finish savepoints or flag for atomic operations?
Not sure about savepoints. Exceptions - yes.
https://issues.apache.org/jira/browse/IGNITE-2313 isn't it?

2017-03-29 2:12 GMT+03:00 Denis Magda :

> If we want to make the exception based approach the default one then the
> task has to be released in 2.0.
>
> Dmitriy Ryabov, do you think you can finish it (dev, review, QA) by the
> code freeze data (April 14)?
>
> —
> Denis
>
> > On Mar 28, 2017, at 11:57 AM, Dmitriy Setrakyan 
> wrote:
> >
> > On Tue, Mar 28, 2017 at 11:54 AM, Sergi Vladykin <
> sergi.vlady...@gmail.com>
> > wrote:
> >
> >> I think updating an Atomic cache from within a transaction perfectly
> makes
> >> sense. For example for some kind of operations logging and so forth.
> Still
> >> I agree that this can be error prone and forbidden by default. I agree
> with
> >> Yakov that by default we should throw an exception and have some kind of
> >> flag (on cache or on TX?) to be able to explicitly enable this behavior.
> >>
> >
> >
> > Agree, this sounds like a good idea.
>
>

[GitHub] ignite pull request #1689: IGNITE-4847

[endian675]

GitHub user endian675 opened a pull request:

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

IGNITE-4847

ignite-4847 log4j2 2.8.1 upgrade

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

$ git pull https://github.com/endian675/ignite ignite-4847-1

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

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


commit 4a24d452e82054bbd516a87ab1316b72f713cecd
Author: Michael Griggs 
Date:   2017-03-21T08:53:51Z

IGNITE-4828: add a new hashing method to RendezvousAffinityFunction to 
improve distribution of keys within partitions

commit 399e27768e88adbe84ac80c7fc4e99d77d1361eb
Author: Michael Griggs 
Date:   2017-03-21T09:05:10Z

IGNITE-4828: improve explanation on javadoc

commit 9dd54c4c6588eb3b3d654e8832d0608cc4528a57
Author: Michael Griggs 
Date:   2017-03-21T09:08:45Z

IGNITE-4828: Add Javadoc for HashType enum

commit 8f339963cede9e8399472695885ae24578e747c5
Author: Michael Griggs 
Date:   2017-03-22T08:58:13Z

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

commit 99ac9a5747fe521e89e55a9010d909516f344e60
Author: Michael Griggs 
Date:   2017-03-23T13:12:52Z

IGNITE-4847: modify code to avoid using deprecated functions. All tests 
that currently pass in master pass on this branch

commit 424c5a558db34036266b571db8bf8d63ac7cb4ac
Author: Michael Griggs 
Date:   2017-03-23T14:15:25Z

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

commit 1de5913401fff729a80a634b2ae524582c261ea8
Author: Michael Griggs 
Date:   2017-03-29T07:59:49Z

Merge branch 'ignite-4847'




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

IGNITE-4052 ready for review

[Вадим Опольский]

Hello everybody!

Nikolay, the properties for mesos role and JUnit test were added.

Review please the pull request - https://github.com/apache/ignite/pull/1662

Vadim Opolski

2017-03-24 18:41 GMT+03:00 Nikolai Tikhonov :

> Great! Looking forward to the contribution.
>
> On Fri, Mar 24, 2017 at 3:54 PM, Вадим Опольский 
> wrote:
>
>> Nikolay, I will add properties for mesos role and unit test next week.
>>
>> -- Forwarded message --
>> From: Вадим Опольский 
>> Date: 2017-03-22 15:53 GMT+03:00
>> Subject: Re: IGNITE-4052 ready for review
>> To: dev@ignite.apache.org
>>
>>
>> Nikolay, just changed status to "path available".
>>
>> 2017-03-22 15:44 GMT+03:00 Nikolai Tikhonov :
>>
>>> Hi Вадим!
>>>
>>> Thank you for your contribution!
>>> Please change status of the ticket to "path available". I'll review your
>>> changes.
>>>
>>> Thanks,
>>> Nikolay
>>>
>>> On Wed, Mar 22, 2017 at 3:36 PM, Вадим Опольский 
>>> wrote:
>>>
>>> > Hello everybody!
>>> >
>>> > Nikolay,
>>> >  review please https://github.com/apache/ignite/pull/1662 .
>>> >
>>> > Added ability to configure current user parameters via system env
>>> > properties - "MESOS_USER".
>>> >
>>> > Vadim Opolski
>>> >
>>> >
>>> > -- Forwarded message --
>>> > From: Вадим Опольский 
>>> > Date: 2017-03-21 14:40 GMT+03:00
>>> > Subject: Assignee IGNITE-4052
>>> > To: dev@ignite.apache.org
>>> >
>>> >
>>> > Dear sirs !
>>> >
>>> > I want to resolve issue IGNITE-4052.
>>> >
>>> > https://issues.apache.org/jira/browse/IGNITE-4052
>>> >
>>> > Is it actual ?
>>> >
>>> > Vadim Opolski
>>> >
>>> >
>>>
>>
>>
>>
>

Re: distributed transaction of non-single coordinator

[ALEKSEY KUZNETSOV]

Hi! No, i dont have ticket for this.
In the ticket i have implemented methods that change transaction status to
STOP, thus letting it to commit transaction in another thread. In another
thread you r going to restart transaction in order to commit it.
The mechanism behind it is obvious : we change thread id to newer one in
ThreadMap, and make use of serialization of txState, transactions itself to
transfer them into another thread.


вт, 28 мар. 2017 г. в 20:15, Denis Magda :

> Aleksey,
>
> Do you have a ticket for this? Could you briefly list what exactly was
> done and how the things work.
>
> —
> Denis
>
> > On Mar 28, 2017, at 8:32 AM, ALEKSEY KUZNETSOV 
> wrote:
> >
> > Hi, Igniters! I 've made implementation of transactions of non-single
> > coordinator. Here you can start transaction in one thread and commit it
> in
> > another thread.
> > Take a look on it. Give your thoughts on it.
> >
> >
> https://github.com/voipp/ignite/pull/10/commits/3a3d90aa6ac84f125e4c3ce4ced4f269a695ef45
> >
> > пт, 17 мар. 2017 г. в 19:26, Sergi Vladykin :
> >
> >> You know better, go ahead! :)
> >>
> >> Sergi
> >>
> >> 2017-03-17 16:16 GMT+03:00 ALEKSEY KUZNETSOV  >:
> >>
> >>> we've discovered several problems regarding your "accumulation"
> >>> approach.These are
> >>>
> >>>   1. perfomance issues when transfering data from temporary cache to
> >>>   permanent one. Keep in mind big deal of concurent transactions in
> >>> Service
> >>>   commiter
> >>>   2. extreme memory load when keeping temporary cache in memory
> >>>   3. As long as user is not acquainted with ignite, working with cache
> >>>   must be transparent for him. Keep this in mind. User's node can
> >> evaluate
> >>>   logic with no transaction at all, so we should deal with both types
> of
> >>>   execution flow : transactional and non-transactional.Another one
> >>> problem is
> >>>   transaction id support at the user node. We would have handled all
> >> this
> >>>   issues and many more.
> >>>   4. we cannot pessimistically lock entity.
> >>>
> >>> As a result, we decided to move on building distributed transaction. We
> >> put
> >>> aside your "accumulation" approach until we realize how to solve
> >>> difficulties above .
> >>>
> >>> чт, 16 мар. 2017 г. в 16:56, Sergi Vladykin  >:
> >>>
>  The problem "How to run millions of entities, and millions of
> >> operations
> >>> on
>  a single Pentium3" is out of scope here. Do the math, plan capacity
>  reasonably.
> 
>  Sergi
> 
>  2017-03-16 15:54 GMT+03:00 ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> >>> :
> 
> > hmm, If we have millions of entities, and millions of operations,
> >> would
>  not
> > this approache lead to memory overflow and perfomance degradation
> >
> > чт, 16 мар. 2017 г. в 15:42, Sergi Vladykin <
> >> sergi.vlady...@gmail.com
>  :
> >
> >> 1. Actually you have to check versions on all the values you have
> >>> read
> >> during the tx.
> >>
> >> For example if we have [k1 => v1, k2 => v2] and do:
> >>
> >> put(k1, get(k2) + 5)
> >>
> >> We have to remember the version for k2. This logic can be
> >> relatively
> > easily
> >> encapsulated in a framework atop of Ignite. You need to implement
> >> one
>  to
> >> make all this stuff usable.
> >>
> >> 2. I suggest to avoid any locking here, because you easily will end
> >>> up
> > with
> >> deadlocks. If you do not have too frequent updates for your keys,
> >> optimistic approach will work just fine.
> >>
> >> Theoretically in the Committer Service you can start a thread for
> >> the
> >> lifetime of the whole distributed transaction, take a lock on the
> >> key
> > using
> >> IgniteCache.lock(K key) before executing any Services, wait for all
> >>> the
> >> services to complete, execute optimistic commit in the same thread
>  while
> >> keeping this lock and then release it. Notice that all the Ignite
> >> transactions inside of all Services must be optimistic here to be
> >>> able
>  to
> >> read this locked key.
> >>
> >> But again I do not recommend you using this approach until you
> >> have a
> >> reliable deadlock avoidance scheme.
> >>
> >> Sergi
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 2017-03-16 12:53 GMT+03:00 ALEKSEY KUZNETSOV <
> >>> alkuznetsov...@gmail.com
> > :
> >>
> >>> Yeah, now i got it.
> >>> There are some doubts on this approach
> >>> 1) During optimistic commit phase, when you assure no one altered
> >>> the
> >>> original values, you must check versions of other dependent keys.
> >>> How
> >> could
> >>> we obtain those keys(in an automative manner, of course) ?
> >>> 2) How could we lock a key before some Service A introduce
> >>