Docker image

[Valentin Kulichenko]

Nikolay,

As far as I know you were creating Docker images for Ignite.

I just opened it [1] and noticed that the version is 1.0.0 there. Is there
a reason for this? Can we switch it to the latest?

[1] https://hub.docker.com/r/apacheignite/ignite/~/dockerfile/

-Val

[jira] [Created] (IGNITE-2497) Cache query fails with assertion after client reconnected

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-2497:
-

 Summary: Cache query fails with assertion after client reconnected
 Key: IGNITE-2497
 URL: https://issues.apache.org/jira/browse/IGNITE-2497
 Project: Ignite
  Issue Type: Bug
Reporter: Yakov Zhdanov


Reproduced locally with 
{{org.apache.ignite.internal.processors.cache.IgniteClientReconnectCacheQueriesFailoverTest#testReconnectCacheQueries}}

Logs
{noformat}
[18:33:18,462][INFO 
][disco-event-worker-#184%cache.IgniteClientReconnectCacheQueriesFailoverTest3%][GridDiscoveryManager]
 Client node reconnected to topology: TcpDiscoveryNode 
[id=91bbc518-67e7-4da1-b92f-b72d304f1d1f, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:0], discPort=0, order=62, intOrder=0, 
lastExchangeTime=1453991574943, loc=true, ver=1.5.1#19700101-sha1:, 
isClient=true]
[18:33:18,462][INFO 
][disco-event-worker-#184%cache.IgniteClientReconnectCacheQueriesFailoverTest3%][GridDiscoveryManager]
 Topology snapshot [ver=62, servers=3, clients=1, CPUs=8, heap=3.0GB]
[18:33:18,463][INFO 
][disco-event-worker-#184%cache.IgniteClientReconnectCacheQueriesFailoverTest3%][root]
 Reconnected: DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=91bbc518-67e7-4da1-b92f-b72d304f1d1f, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:0], discPort=0, order=62, intOrder=0, 
lastExchangeTime=1453991574943, loc=true, ver=1.5.1#19700101-sha1:, 
isClient=true], topVer=62, nodeId8=91bbc518, msg=Client node reconnected: 
TcpDiscoveryNode [id=91bbc518-67e7-4da1-b92f-b72d304f1d1f, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:0], discPort=0, order=62, intOrder=0, 
lastExchangeTime=1453991574943, loc=true, ver=1.5.1#19700101-sha1:, 
isClient=true], type=CLIENT_NODE_RECONNECTED, tstamp=1453991598459]

[18:33:18,987][WARN 
][disco-event-worker-#41%cache.IgniteClientReconnectCacheQueriesFailoverTest0%][GridDiscoveryManager]
 Node FAILED: TcpDiscoveryNode [id=91bbc518-67e7-4da1-b92f-b72d304f1d1f, 
addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:0], discPort=0, order=62, intOrder=33, 
lastExchangeTime=1453991598416, loc=false, ver=1.5.1#19700101-sha1:, 
isClient=true]
[18:33:18,988][WARN 
][disco-event-worker-#88%cache.IgniteClientReconnectCacheQueriesFailoverTest1%][GridDiscoveryManager]
 Node FAILED: TcpDiscoveryNode [id=91bbc518-67e7-4da1-b92f-b72d304f1d1f, 
addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:0], discPort=0, order=62, intOrder=33, 
lastExchangeTime=1453991598416, loc=false, ver=1.5.1#19700101-sha1:, 
isClient=true]
[18:33:18,986][INFO 
][test-runner-#196%cache.IgniteClientReconnectCacheQueriesFailoverTest%][root] 
Fail client: 91bbc518-67e7-4da1-b92f-b72d304f1d1f
[18:33:18,988][INFO 
][disco-event-worker-#41%cache.IgniteClientReconnectCacheQueriesFailoverTest0%][GridDiscoveryManager]
 Topology snapshot [ver=63, servers=3, clients=0, CPUs=8, heap=3.0GB]
[18:33:18,988][INFO 
][disco-event-worker-#88%cache.IgniteClientReconnectCacheQueriesFailoverTest1%][GridDiscoveryManager]
 Topology snapshot [ver=63, servers=3, clients=0, CPUs=8, heap=3.0GB]
[18:33:18,990][INFO 
][disco-event-worker-#138%cache.IgniteClientReconnectCacheQueriesFailoverTest2%][GridDiscoveryManager]
 Topology snapshot [ver=63, servers=3, clients=0, CPUs=8, heap=3.0GB]
[18:33:18,990][WARN 
][disco-event-worker-#138%cache.IgniteClientReconnectCacheQueriesFailoverTest2%][GridDiscoveryManager]
 Node FAILED: TcpDiscoveryNode [id=91bbc518-67e7-4da1-b92f-b72d304f1d1f, 
addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:0], discPort=0, order=62, intOrder=33, 
lastExchangeTime=1453991598416, loc=false, ver=1.5.1#19700101-sha1:, 
isClient=true]
[18:33:18,992][INFO 
][exchange-worker-#44%cache.IgniteClientReconnectCacheQueriesFailoverTest0%][GridCachePartitionExchangeManager]
 Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
[topVer=63, minorTopVer=0], evt=NODE_FAILED, 
node=91bbc518-67e7-4da1-b92f-b72d304f1d1f]
[18:33:18,992][INFO 
][exchange-worker-#90%cache.IgniteClientReconnectCacheQueriesFailoverTest1%][GridCachePartitionExchangeManager]
 Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
[topVer=63, minorTopVer=0], evt=NODE_FAILED, 
node=91bbc518-67e7-4da1-b92f-b72d304f1d1f]
[18:33:18,994][INFO ][test-operation-thread-1][root] Ignore error: 
javax.cache.CacheException: Failed to fetch data from node: 
6b548954-4d39-4160-8801-367a65c1
[18:33:18,994][INFO 
][exchange-worker-#140%cache.IgniteClientReconnectCacheQueriesFailoverTest2%][GridCachePartitionExchangeManager]
 Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion 
[topVer=63, minorTopVer=0], evt=NODE_FAILED, 
node=91bbc518-67e7-4da1-b92f-b72d304f1d1f]
[18:33:18,995][INFO 
][tcp-client-disco-msg-worker-#26%cache.IgniteClientReconnectCacheQueriesFailoverTest3%][IgniteClientReconnectAbstractTest$TestTcpDiscoverySpi]
 Client node disconnected from cluster, will try to reconnect with new id 

Re: Cassandra cache store [IGNITE-1371]

[Alexey Kuznetsov]

I like Val suggestion.

Also in this case we could move external things like Kryo into separate
module/dependency (for those who do not want to depend on Kryo).
This could be "ignite-cassandra-kryo" module that will contain smth. like
"KryoPersistenceCallback".

Thoughts?


On Fri, Jan 29, 2016 at 10:27 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Alexey, Igor,
>
> Binary format is internal format used by Ignite, it can't be used directly
> or outside of Ignite. So there is no way and no reason to have special
> binary serializer in Cassandra store implementation. If user wants to save
> BinaryObject as a BLOB to the store (to later load it back to Ignite), he
> can set CacheConfiguration.setStoreKeepBinary(true) flag and cache will
> give BinaryObject to the store without deserializing it.
>
> Actually, I'm looking at the current API and I don't like
> PersistenceStrategy enum and Serializer interface. I understand what you
> try to achieve here and it makes sense to me, but the abstraction is not
> generic enough in my opinion. We give user only two options, but what if he
> needs something else? For example, he may need to add special processing
> for some specific fields (make some conversions, etc.).
>
> I propose to change it a bit and do something like this:
>
> interface PersistenceCallback {
> CassandraData onWrite(K key, V value);
> IgniteBiTuple onRead(CassandraData);
> }
>
> CassandraData is an entity that Cassandra should be able to write and load
> (essentially, set of column values). We can reuse something from Cassandra
> API here if that's possible (I'm not familiar enough with Cassandra to make
> specific suggestions right away) or create our own.
>
> We will have a default implementation that will introspect POJOs. The one
> that converts value to BLOB can be also provided out of the box. And user
> is free to implement his own logic.
>
> All namings and API itself are arguable, of course, but I hope that idea is
> clear.
>
> Thoughts?
>
> On Thu, Jan 28, 2016 at 12:41 AM, Alexey Kuznetsov <
> akuznet...@gridgain.com>
> wrote:
>
> > During review I faced the problem, that I have not enough experience to
> > answer.
> >
> > So, it will be great, if someone who has deep experience with Binary
> > marshaller could help us.
> >
> > ---
> >
> > > How about such limitations of Binary Marshaller:
> >
> > > 1) Fields or types with the same name hash are not allowed.
> > > 2) BinaryObject format does not allow same field names on different
> > levels of a class hierarchy.
> > > 3) Externalizable interface is ignored by default. If BinaryObject
> format
> > is used, Externalizable
> > >  classes will be written the same way as if they were Serializable,
> > without writeExternal() and
> > > readExternal() methods. If for some reason this does not work for you,
> > you should implement
> > > Binarylizable interface for your classes, plug in a custom
> > BinarySerializer or switch to the
> > > OptimizedMarshaller.
> >
> > > There are no such limitations in Kryo and Java serialization.
> >
> > > The next concern is that you need *Ignite Core* module, which is rather
> > huge (about 7.3MB) if
> > >  you want to build ETL script which will consume data persisted into
> > Cassandra by Ignite Binary
> > >  Marshaller.
> >
> > > By the way, does Ignite plan to support backward compatibility for data
> > persisted using Binary
> > >  Marshaller? I mean the situation when some objects were persisted into
> > Cassandra using old
> > >  version of Binary Marshaller and then Ignite cluster was upgraded to
> new
> > version. Kryo and
> > >  Java serialization handles this situation and provides backward
> > compatibility.
> >
> > > May be it's better just to add one more serializer implementation which
> > will use Binary Marshaller?
> >
> > > By the way are there any samples in the code how to use Binary
> Marshaller
> > just to
> > > serialize/deserialize arbitrary object? Binary Marshaller documentation
> > says that all such
> > >  operation performed internally inside Ignite when we using
> BinaryObject,
> > but in my case I am
> > >  interested in rather low-level serialization/deserialization API/
> >
> > Regards,
> > Igor Rudyak
> >
> > 
> > Hi Igor!
> >
> > I moved discussion to dev list.
> >
> > >>> The next concern is that you need *Ignite Core* module
> > We could not avoid adding this module because All base cache store
> classes
> > declared in that module, so I think this module will *be always
> imported*.
> >
> > As for other points, I hope community will help us.
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> >
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Re: Proxy serialization issue

[Valentin Kulichenko]

Yes, this happens because in a single JVM the dynamic proxy class is
available for Class.forName, but for multi-jvm case this is not true. We
should additionally write information about the implemented interfaces and
manually recreate the proxy during unmarshalling. But the problem is that
it's not a compatible change. In binary marshaller there is a protocol
version, so should be OK, but we don't have it for optimized marshaller,
right?

-Val

On Thu, Jan 28, 2016 at 12:21 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> This is correct, I took the original test that existed for Optimized
> marshaller and copied it for Binary marshaller. Was not aware of multi-jvm
> specifics. Just ran the provided example with Optimized marshaller - it
> does not work either.
>
> 2016-01-28 11:08 GMT+03:00 Denis Magda :
>
> > To my knowledge Alex G. was taking care of this initial issue.
> >
> > This particular one is reproduced only in multi JVM mode.
> >
> > --
> > Denis
> >
> >
> > On 1/28/2016 2:59 AM, Dmitriy Setrakyan wrote:
> >
> >> Who was originally responsible for fixing the Proxy serialization issue?
> >>
> >> On Wed, Jan 27, 2016 at 4:07 AM, Denis Magda 
> wrote:
> >>
> >> Igniters,
> >>>
> >>> A end user reported on the issue related to proxy
> >>> serialization/deserialization
> >>> https://issues.apache.org/jira/browse/IGNITE-2450
> >>>
> >>> Could someone experienced in marshalling take a look at this? Seems
> that
> >>> the original proxy related issue wasn't fully fixed.
> >>>
> >>> --
> >>> Denis
> >>>
> >>>
> >>>
> >>>
> >
>

Re: Draining collocated IgniteQueue on a node when it's stored

[Valentin Kulichenko]

Denis,

Yes, this is not supported now, because user doesn't know the underlying
cache name. Here is the ticket:
https://issues.apache.org/jira/browse/IGNITE-1144

-Val

On Thu, Jan 28, 2016 at 2:12 AM, Denis Magda  wrote:

> Igniteres,
>
> Seems that the documentation contains a wrong example on how it's possible
> to drain a collocated queue [1].
>
> According to it, this can be easily done by sending a closure on a node
> that holds it
>
> // Drain queue on the node where the queue is cached.
> ignite.compute().affinityRun("cacheName","queueName",queuePoller);
>
>
> However, in my understanding this is incorrect information cause such an
> approach won't work.
>
> Can anybody comment on this? Do we have any ticket that will allow to add
> an ability for draining of collocated queues?
>
> [1] https://apacheignite.readme.io/docs/queue-and-set#bounded-queues
>
> --
> Denis
>

Re: Proxy serialization issue

[Dmitriy Setrakyan]

In my view we should go ahead and fix it. How can we break something that
never worked?

On Thu, Jan 28, 2016 at 11:00 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Yes, this happens because in a single JVM the dynamic proxy class is
> available for Class.forName, but for multi-jvm case this is not true. We
> should additionally write information about the implemented interfaces and
> manually recreate the proxy during unmarshalling. But the problem is that
> it's not a compatible change. In binary marshaller there is a protocol
> version, so should be OK, but we don't have it for optimized marshaller,
> right?
>
> -Val
>
> On Thu, Jan 28, 2016 at 12:21 AM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > This is correct, I took the original test that existed for Optimized
> > marshaller and copied it for Binary marshaller. Was not aware of
> multi-jvm
> > specifics. Just ran the provided example with Optimized marshaller - it
> > does not work either.
> >
> > 2016-01-28 11:08 GMT+03:00 Denis Magda :
> >
> > > To my knowledge Alex G. was taking care of this initial issue.
> > >
> > > This particular one is reproduced only in multi JVM mode.
> > >
> > > --
> > > Denis
> > >
> > >
> > > On 1/28/2016 2:59 AM, Dmitriy Setrakyan wrote:
> > >
> > >> Who was originally responsible for fixing the Proxy serialization
> issue?
> > >>
> > >> On Wed, Jan 27, 2016 at 4:07 AM, Denis Magda 
> > wrote:
> > >>
> > >> Igniters,
> > >>>
> > >>> A end user reported on the issue related to proxy
> > >>> serialization/deserialization
> > >>> https://issues.apache.org/jira/browse/IGNITE-2450
> > >>>
> > >>> Could someone experienced in marshalling take a look at this? Seems
> > that
> > >>> the original proxy related issue wasn't fully fixed.
> > >>>
> > >>> --
> > >>> Denis
> > >>>
> > >>>
> > >>>
> > >>>
> > >
> >
>

Re: Ignite Readme.IO UX issue

[Dmitriy Setrakyan]

Hi Yujie Li,

Can you please suggest what official github backup function you would like
us to enable? I can’t find anything directly in Github, other than just a
zip download.

Thanks,
D.

On Wed, Jan 27, 2016 at 4:05 AM, 李玉珏@163 <18624049...@163.com> wrote:

> Hi:
>
> I have seen the changes in the document. I also found that part of the
> DataGrid has added a new section called "Lock".
> I maintain manual approach is, first from github document backup find
> changes, then according to the change point to find the online version of
> the difference and according to the online version do translation to ensure
> document consistency, because I know there is a part of the document is not
> open.
> So, I would like to have the official github backup function, otherwise I
> can't know what parts of the document have changed.
>
> 在 16/1/27 11:11, Dmitriy Setrakyan 写道:
>
> The version that corresponds to the documentation translated in Chinese is
>> 1.5.0-b1:
>> https://apacheignite.readme.io/v1.5-b1
>>
>> The new v.1.5 contains mainly the following changes:
>> - Hadoop and Spark were moved to a separate space:
>> https://apacheignite-fs.readme.io/docs
>> - Every category has an overview session now, e.g. Clustering, Data
>> Structures, etc.
>>
>> You should be able to compare the GIT repos to apply the changes. Let me
>> know if you have more questions.
>>
>> D.
>>
>> On Tue, Jan 26, 2016 at 4:13 AM, 李玉珏@163 <18624049...@163.com> wrote:
>>
>> Hi：
>>>
>>> I found that there was update on the online manual, but the GitHub backup
>>> is not updated.What is the reason?
>>>
>>> Https://github.com/apacheignite/documentation/tree/v1.5
>>>
>>> I was through the GitHub document to update the Chinese version of the
>>> document, if you do not have this backup, I can not know that the
>>> document
>>> has been adjusted.
>>>
>>> 在 16/1/26 01:28, Dmitriy Setrakyan 写道:
>>>
>>> Hadoop/IGFS documentation is being refactored right now. Could be a side
>>>
 effect of what you were observing.

 Btw, everyone with login to readme can file a support issue. However, I
 would not do it yet, while Prachi is still working on refactoring.

 D.

 On Mon, Jan 25, 2016 at 6:51 AM, Alexey Kuznetsov <
 akuznet...@gridgain.com>
 wrote:

 Hi!

> Does someone knows it is possible or not to "sync" left pane with
> documentation categories and right pane with content of some selected
> category?
>
> For example: https://apacheignite.readme.io/docs/igfs
>
> I see some IGFS documentation, but on the left pane I do not see
> selected
> category "IGFS", I need to scroll down. This is very annoying when you
> are
> reading several related topics - you need to scroll every time.
>
> As I know readme.io is a kind of CMS, so who knows how to open an
> issue
> for
> them?
> Do they have any kind of JIRA / mail list / support forum?
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>
>
>
>>>
>
>

[GitHub] ignite pull request: IGNITE-2453 Fixed single primary and single b...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2487) Revert button doesn't appear on removing item from the any table

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-2487:
--

 Summary: Revert button doesn't appear on removing item from the 
any table
 Key: IGNITE-2487
 URL: https://issues.apache.org/jira/browse/IGNITE-2487
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Alexey Kuznetsov


Remove address from Addresses




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Proxy serialization issue

[Alexey Goncharuk]

This is correct, I took the original test that existed for Optimized
marshaller and copied it for Binary marshaller. Was not aware of multi-jvm
specifics. Just ran the provided example with Optimized marshaller - it
does not work either.

2016-01-28 11:08 GMT+03:00 Denis Magda :

> To my knowledge Alex G. was taking care of this initial issue.
>
> This particular one is reproduced only in multi JVM mode.
>
> --
> Denis
>
>
> On 1/28/2016 2:59 AM, Dmitriy Setrakyan wrote:
>
>> Who was originally responsible for fixing the Proxy serialization issue?
>>
>> On Wed, Jan 27, 2016 at 4:07 AM, Denis Magda  wrote:
>>
>> Igniters,
>>>
>>> A end user reported on the issue related to proxy
>>> serialization/deserialization
>>> https://issues.apache.org/jira/browse/IGNITE-2450
>>>
>>> Could someone experienced in marshalling take a look at this? Seems that
>>> the original proxy related issue wasn't fully fixed.
>>>
>>> --
>>> Denis
>>>
>>>
>>>
>>>
>

Cassandra cache store [IGNITE-1371]

[Alexey Kuznetsov]

During review I faced the problem, that I have not enough experience to
answer.

So, it will be great, if someone who has deep experience with Binary
marshaller could help us.

---

> How about such limitations of Binary Marshaller:

> 1) Fields or types with the same name hash are not allowed.
> 2) BinaryObject format does not allow same field names on different
levels of a class hierarchy.
> 3) Externalizable interface is ignored by default. If BinaryObject format
is used, Externalizable
>  classes will be written the same way as if they were Serializable,
without writeExternal() and
> readExternal() methods. If for some reason this does not work for you,
you should implement
> Binarylizable interface for your classes, plug in a custom
BinarySerializer or switch to the
> OptimizedMarshaller.

> There are no such limitations in Kryo and Java serialization.

> The next concern is that you need *Ignite Core* module, which is rather
huge (about 7.3MB) if
>  you want to build ETL script which will consume data persisted into
Cassandra by Ignite Binary
>  Marshaller.

> By the way, does Ignite plan to support backward compatibility for data
persisted using Binary
>  Marshaller? I mean the situation when some objects were persisted into
Cassandra using old
>  version of Binary Marshaller and then Ignite cluster was upgraded to new
version. Kryo and
>  Java serialization handles this situation and provides backward
compatibility.

> May be it's better just to add one more serializer implementation which
will use Binary Marshaller?

> By the way are there any samples in the code how to use Binary Marshaller
just to
> serialize/deserialize arbitrary object? Binary Marshaller documentation
says that all such
>  operation performed internally inside Ignite when we using BinaryObject,
but in my case I am
>  interested in rather low-level serialization/deserialization API/

Regards,
Igor Rudyak


Hi Igor!

I moved discussion to dev list.

>>> The next concern is that you need *Ignite Core* module
We could not avoid adding this module because All base cache store classes
declared in that module, so I think this module will *be always imported*.

As for other points, I hope community will help us.

-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

[GitHub] ignite pull request: IGNITE-1355 Potential NPE in CacheAffinityPro...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: MyBatis and Apache Ignite integration

[Denis Magda]

Roman,

Perfect, thanks a lot! Please work close with Eduardo if you need to 
know more details on myBatis.


--
Denis

On 1/28/2016 12:45 PM, Roman Shtykh wrote:

Denis,

I will take care of this integration.

-Roman

On Tuesday, January 26, 2016 1:16 AM, Denis Magda  wrote:



HI All,

I've opened an Ignite ticket with tasks description [1]

Is there anyone in Apache Ignite community who is interested in this
kind of work and will be able to complete it in the nearest couple of weeks?

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

Regards,
Denis

On 1/23/2016 11:28 AM, dma...@gridgain.com wrote:

Hi Eduardo,

It's nice to hear from you! Thanks the help and details!

Absolutely agree with you that the interface is straightforward and I
don't see any difficulties that can arise during its implementation.
I'll open an Apache Ignite JIRA ticket soon describing the integration
details and hope that someone from Ignite community will pick it up
the next week starting working on the plugin.

As per the hosting I would host everything on MyBatis GitHub repo as
it is already done for other plugins and in addition would add a
documentation to Apache Ignite [1]. This way both MyBatis and Ignite
community will be aware about the integration and we don't need to
host the plugin in different repos.

I've copied Ignite dev community to the discussion -
dev@ignite.apache.org. So please make sure that this dev list is
copied when you reply ;)

If someone else from either MyBatis or Ignite community has any
thoughts on this topic please share.

[1] https://apacheignite.readme.io

Regards,
Denis

On Saturday, January 23, 2016 at 12:46:08 AM UTC+3, Eduardo wrote:

 Hi Denis,

 First of all. Wellcome to the list!

 AFAIK all the cache integration plugins have been developed by
 ourselves. The interface is quite easy so the task is usualy
 pretty straight forward.

 I will be very happy to help with the integration! I would suggest
 creating a new repo and work on it. Probably it will be better
 that that someone from the Ignite project builds the plugin and we
 provide information about how the interface works.

 Regarding the future hosting, I suppose there will be no problem
 in hosting the new project at our home in Github but is also
 perfect that you host it as part of the ignite project. No problem
 at all with any option!

 Looking forward to starting! :)

 2016-01-21 10:30 GMT+01:00 :

 Hi MyBatis community!

 I'm a committer and PMC of Apache Ignite [1] project and
 writing to you on behalf of our community (+ CC-ed) to discuss
 an integration between our projects that should be useful for
 both sides.

 In short, Apache Ignite is a high-performance, integrated and
 distributed in-memory platform for computing and transacting
 on large-scale data sets in real-time, orders of magnitude
 faster than possible with traditional disk-based or flash
 technologies.
 Inside of our community we see a growing interest in a field
 of usage MyBatis along with Apache Ignite. There are use cases
 when developers/users wants to use Apache Ignite as MyBatis
 second level cache. Since such an interest is growing
 constantly we think that it's a right time to make this happen.

 As I see MyBatis already supports second level cache for
 Redis, Hazelcast and Ehcache.

 How do you usually add such components? Were they added by
 MyBatis guys or were developed by guys from Redis, Hazelcast,
 etc.?

 [1] https://ignite.apache.org/

 Regards,
 Denis

 --
 You received this message because you are subscribed to the
 Google Groups "mybatis-user" group.
 To unsubscribe from this group and stop receiving emails from
 it, send an email to mybatis-user...@googlegroups.com
 .
 For more options, visit https://groups.google.com/d/optout
 .


--
You received this message because you are subscribed to a topic in the
Google Groups "mybatis-user" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/mybatis-user/CxSqG1dprm4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
mybatis-user+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.

[jira] [Created] (IGNITE-2486) exception on Save SSL configuration

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-2486:
--

 Summary: exception on Save SSL configuration
 Key: IGNITE-2486
 URL: https://issues.apache.org/jira/browse/IGNITE-2486
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Alexey Kuznetsov


SSL configuration, set Key store file and Save
{code}
14:59:13.015 Error: element[0] is undefined
TooltipFactory@https://staging-console.gridgain.com/app.min.js:57923:17
PopoverFactory@https://staging-console.gridgain.com/app.min.js:59845:28
showPopoverMessage@https://staging-console.gridgain.com/common-module.js:599:30
validate@https://staging-console.gridgain.com/all.js:1452:1
$scope.saveItem@https://staging-console.gridgain.com/all.js:1515:21
anonymous/fn@https://staging-console.gridgain.com/app.min.js line 92971 > 
Function:2:450
ngEventHandler/https://staging-console.gridgain.com/app.min.js:96719:21
$RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:94583:22
$RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:94606:26
ngEventHandler/<@https://staging-console.gridgain.com/app.min.js:96724:21
jQuery.event.dispatch@https://staging-console.gridgain.com/app.min.js:126814:25
jQuery.event.add/elemData.handle@https://staging-console.gridgain.com/app.min.js:126685:91
1 app.min.js:92177:24
consoleLog/<() app.min.js:92177
$ExceptionHandlerProvider/this.$get

[jira] [Created] (IGNITE-2488) Investigate possible Hibernate Ignite L2 Cache performance issues

[Denis Magda (JIRA)]

Denis Magda created IGNITE-2488:
---

 Summary: Investigate possible Hibernate Ignite L2 Cache 
performance issues
 Key: IGNITE-2488
 URL: https://issues.apache.org/jira/browse/IGNITE-2488
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.5.0.final
Reporter: Denis Magda


The ticket is opened as a part of the discussion happened on StackOverflow [1].

There is a suspicion that Ignite L2 cache has some performance bottlenecks.

Need to reproduce and investigate.

[1] 
http://stackoverflow.com/questions/34534251/ignite-for-hibernate-l2-is-extremely-slow/34551411#34551411



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: MyBatis and Apache Ignite integration

[Roman Shtykh]

Denis,

I will take care of this integration.

-Roman

On Tuesday, January 26, 2016 1:16 AM, Denis Magda  wrote:



HI All,

I've opened an Ignite ticket with tasks description [1]

Is there anyone in Apache Ignite community who is interested in this 
kind of work and will be able to complete it in the nearest couple of weeks?

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

Regards,
Denis

On 1/23/2016 11:28 AM, dma...@gridgain.com wrote:
> Hi Eduardo,
>
> It's nice to hear from you! Thanks the help and details!
>
> Absolutely agree with you that the interface is straightforward and I 
> don't see any difficulties that can arise during its implementation.
> I'll open an Apache Ignite JIRA ticket soon describing the integration 
> details and hope that someone from Ignite community will pick it up 
> the next week starting working on the plugin.
>
> As per the hosting I would host everything on MyBatis GitHub repo as 
> it is already done for other plugins and in addition would add a 
> documentation to Apache Ignite [1]. This way both MyBatis and Ignite 
> community will be aware about the integration and we don't need to 
> host the plugin in different repos.
>
> I've copied Ignite dev community to the discussion - 
> dev@ignite.apache.org. So please make sure that this dev list is 
> copied when you reply ;)
>
> If someone else from either MyBatis or Ignite community has any 
> thoughts on this topic please share.
>
> [1] https://apacheignite.readme.io
>
> Regards,
> Denis
>
> On Saturday, January 23, 2016 at 12:46:08 AM UTC+3, Eduardo wrote:
>
> Hi Denis,
>
> First of all. Wellcome to the list!
>
> AFAIK all the cache integration plugins have been developed by
> ourselves. The interface is quite easy so the task is usualy
> pretty straight forward.
>
> I will be very happy to help with the integration! I would suggest
> creating a new repo and work on it. Probably it will be better
> that that someone from the Ignite project builds the plugin and we
> provide information about how the interface works.
>
> Regarding the future hosting, I suppose there will be no problem
> in hosting the new project at our home in Github but is also
> perfect that you host it as part of the ignite project. No problem
> at all with any option!
>
> Looking forward to starting! :)
>
> 2016-01-21 10:30 GMT+01:00 :
>
> Hi MyBatis community!
>
> I'm a committer and PMC of Apache Ignite [1] project and
> writing to you on behalf of our community (+ CC-ed) to discuss
> an integration between our projects that should be useful for
> both sides.
>
> In short, Apache Ignite is a high-performance, integrated and
> distributed in-memory platform for computing and transacting
> on large-scale data sets in real-time, orders of magnitude
> faster than possible with traditional disk-based or flash
> technologies.
> Inside of our community we see a growing interest in a field
> of usage MyBatis along with Apache Ignite. There are use cases
> when developers/users wants to use Apache Ignite as MyBatis
> second level cache. Since such an interest is growing
> constantly we think that it's a right time to make this happen.
>
> As I see MyBatis already supports second level cache for
> Redis, Hazelcast and Ehcache.
>
> How do you usually add such components? Were they added by
> MyBatis guys or were developed by guys from Redis, Hazelcast,
> etc.?
>
> [1] https://ignite.apache.org/
>
> Regards,
> Denis
>
> -- 
> You received this message because you are subscribed to the
> Google Groups "mybatis-user" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to mybatis-user...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout
> .
>
>
> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "mybatis-user" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/mybatis-user/CxSqG1dprm4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> mybatis-user+unsubscr...@googlegroups.com 
> .

> For more options, visit https://groups.google.com/d/optout.

Re: Proxy serialization issue

[Denis Magda]

To my knowledge Alex G. was taking care of this initial issue.

This particular one is reproduced only in multi JVM mode.

--
Denis

On 1/28/2016 2:59 AM, Dmitriy Setrakyan wrote:

Who was originally responsible for fixing the Proxy serialization issue?

On Wed, Jan 27, 2016 at 4:07 AM, Denis Magda  wrote:


Igniters,

A end user reported on the issue related to proxy
serialization/deserialization
https://issues.apache.org/jira/browse/IGNITE-2450

Could someone experienced in marshalling take a look at this? Seems that
the original proxy related issue wasn't fully fixed.

--
Denis

Re: Ignite documentation: keep 1.6 docs in sync with 1.5

[Denis Magda]

Got it.

Copy-pasted recent changes done for cache query docs.

I've heard that IGFS related docs were changed in 1.5.
Ivan, Vladimir, is this so? If yes then please apply the same changes 
into 1.6 docs.


--
Denis

On 1/27/2016 8:06 PM, Dmitriy Setrakyan wrote:

There is no easy way other than the same old copy-n-paste. To my knowledge,
readme team is working on automating this process.

D.

On Wed, Jan 27, 2016 at 4:25 AM, Denis Magda  wrote:


Igniters,

Some of you have already been working on features that will be available
in the next release 1.6 and adding documentation to the doc versioned 1.6.
[1]

In the same time the community improves docs for version 1.5 (Hadoop +
IGFS, queries, etc.). These changes are not reflected automatically in 1.6
docs.

Does anybody know an easy way to merge the changes from 1.5 to 1.6 docs?

[1] https://apacheignite.readme.io/v1.6

--
Denis

[GitHub] ignite pull request: IGNITE-1355: Fix Potential NPE in CacheAffini...

[ashutakGG]

Github user ashutakGG closed the pull request at:

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


---
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-2489) 'save' button allow to save cluster with fields with invalid value

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-2489:
--

 Summary: 'save' button allow to save cluster with fields with 
invalid value
 Key: IGNITE-2489
 URL: https://issues.apache.org/jira/browse/IGNITE-2489
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Alexey Kuznetsov


# set invalid value for any item
# click Save



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request: IGNITE-2273

[ilantukh]

GitHub user ilantukh opened a pull request:

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

IGNITE-2273



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

$ git pull https://github.com/ilantukh/ignite ignite-2273

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

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


commit 24514125b67e8f8361ab1ce14dc0376719922880
Author: Ilya Lantukh 
Date:   2016-01-28T12:03:06Z

ignite-2273 : Optimized usage of Arrays.asList().




---
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.
---

[GitHub] ignite pull request: ignite-2325 - Fixing assertion on prepare fut...

[agoncharuk]

Github user agoncharuk closed the pull request at:

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


---
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-2492) .NET: Peer assembly loading

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2492:
--

 Summary: .NET: Peer assembly loading
 Key: IGNITE-2492
 URL: https://issues.apache.org/jira/browse/IGNITE-2492
 Project: Ignite
  Issue Type: New Feature
  Components: interop
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
 Fix For: 1.7


Similar to peer class loading in Java, we can provide a possibility to load 
assemblies on already started nodes, so that a node can execute jobs that are 
not present on other nodes.

Considerations:
* Can we unload assemblies after use to free memory? This requires a separate 
AppDomain, can we work with that?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2493) Get rid fo sun.misc.Cleaner in PlatformMemoryPool.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2493:
---

 Summary: Get rid fo sun.misc.Cleaner in PlatformMemoryPool.
 Key: IGNITE-2493
 URL: https://issues.apache.org/jira/browse/IGNITE-2493
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.6






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request: ignite-2325 - Fixing assertion on prepare fut...

[agoncharuk]

GitHub user agoncharuk opened a pull request:

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

ignite-2325 - Fixing assertion on prepare future remap.



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

$ git pull https://github.com/agoncharuk/ignite ignite-2325

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

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


commit 45cd04de64dfd14d10248bd08e9d4dee6625b082
Author: Alexey Goncharuk 
Date:   2015-12-30T13:01:26Z

ignite-2325 - Fixing assertion on prepare future remap.




---
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.
---

[GitHub] ignite pull request: IGNITE-2469: ODBC processor simplified.

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-2469: ODBC processor simplified.



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

$ git pull https://github.com/isapego/ignite ignite-2469

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

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


commit 27596864c51d87d71c6b1d6ec86e9e37e79f2948
Author: isapego 
Date:   2016-01-28T11:42:48Z

IGNITE-2469: Refactored ODBC requests handling.

commit d8e60282720ca2e5c1de9ea74a71aeff7a7c82c4
Author: isapego 
Date:   2016-01-28T12:04:51Z

IGNITE-2469: Removed unnecessary imports.

commit 3d18a7b16be7b9b7e337a47a5b4421ce522fd2a4
Author: isapego 
Date:   2016-01-28T12:42:18Z

IGNITE-2469: Removed OdbcTcpServer.

commit 29c7584fadba73c380418692d206000c12844f4c
Author: isapego 
Date:   2016-01-28T13:23:23Z

IGNITE-2469: OdbcTcpNioListener removed.




---
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.
---

Draining collocated IgniteQueue on a node when it's stored

[Denis Magda]

Igniteres,

Seems that the documentation contains a wrong example on how it's 
possible to drain a collocated queue [1].


According to it, this can be easily done by sending a closure on a node 
that holds it


// Drain queue on the node where the queue is cached.
ignite.compute().affinityRun("cacheName","queueName",queuePoller);


However, in my understanding this is incorrect information cause such an 
approach won't work.


Can anybody comment on this? Do we have any ticket that will allow to 
add an ability for draining of collocated queues?


[1] https://apacheignite.readme.io/docs/queue-and-set#bounded-queues

--
Denis

[GitHub] ignite pull request: IGNITE-2396 - Fixed service deployment on cac...

[agoncharuk]

Github user agoncharuk closed the pull request at:

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


---
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-2490) Confirmation about unsaved changes appears unexpectedly

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-2490:
--

 Summary: Confirmation about unsaved changes appears unexpectedly
 Key: IGNITE-2490
 URL: https://issues.apache.org/jira/browse/IGNITE-2490
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov


Open Model page and then click on Clusters.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request: IGNITE-2396 - Fixed service deployment for dy...

[agoncharuk]

GitHub user agoncharuk opened a pull request:

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

IGNITE-2396 - Fixed service deployment for dynamic cache creation.



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

$ git pull https://github.com/agoncharuk/ignite ignite-2396

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

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


commit d708e874d6e1a4c939043e5af79639a8460a7ff0
Author: Alexey Goncharuk 
Date:   2016-01-28T10:13:46Z

IGNITE-2396 - Fixed service deployment for dynamic cache creation.




---
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: Cassandra cache store [IGNITE-1371]

[Valentin Kulichenko]

Alexey, Igor,

Binary format is internal format used by Ignite, it can't be used directly
or outside of Ignite. So there is no way and no reason to have special
binary serializer in Cassandra store implementation. If user wants to save
BinaryObject as a BLOB to the store (to later load it back to Ignite), he
can set CacheConfiguration.setStoreKeepBinary(true) flag and cache will
give BinaryObject to the store without deserializing it.

Actually, I'm looking at the current API and I don't like
PersistenceStrategy enum and Serializer interface. I understand what you
try to achieve here and it makes sense to me, but the abstraction is not
generic enough in my opinion. We give user only two options, but what if he
needs something else? For example, he may need to add special processing
for some specific fields (make some conversions, etc.).

I propose to change it a bit and do something like this:

interface PersistenceCallback {
CassandraData onWrite(K key, V value);
IgniteBiTuple onRead(CassandraData);
}

CassandraData is an entity that Cassandra should be able to write and load
(essentially, set of column values). We can reuse something from Cassandra
API here if that's possible (I'm not familiar enough with Cassandra to make
specific suggestions right away) or create our own.

We will have a default implementation that will introspect POJOs. The one
that converts value to BLOB can be also provided out of the box. And user
is free to implement his own logic.

All namings and API itself are arguable, of course, but I hope that idea is
clear.

Thoughts?

On Thu, Jan 28, 2016 at 12:41 AM, Alexey Kuznetsov 
wrote:

> During review I faced the problem, that I have not enough experience to
> answer.
>
> So, it will be great, if someone who has deep experience with Binary
> marshaller could help us.
>
> ---
>
> > How about such limitations of Binary Marshaller:
>
> > 1) Fields or types with the same name hash are not allowed.
> > 2) BinaryObject format does not allow same field names on different
> levels of a class hierarchy.
> > 3) Externalizable interface is ignored by default. If BinaryObject format
> is used, Externalizable
> >  classes will be written the same way as if they were Serializable,
> without writeExternal() and
> > readExternal() methods. If for some reason this does not work for you,
> you should implement
> > Binarylizable interface for your classes, plug in a custom
> BinarySerializer or switch to the
> > OptimizedMarshaller.
>
> > There are no such limitations in Kryo and Java serialization.
>
> > The next concern is that you need *Ignite Core* module, which is rather
> huge (about 7.3MB) if
> >  you want to build ETL script which will consume data persisted into
> Cassandra by Ignite Binary
> >  Marshaller.
>
> > By the way, does Ignite plan to support backward compatibility for data
> persisted using Binary
> >  Marshaller? I mean the situation when some objects were persisted into
> Cassandra using old
> >  version of Binary Marshaller and then Ignite cluster was upgraded to new
> version. Kryo and
> >  Java serialization handles this situation and provides backward
> compatibility.
>
> > May be it's better just to add one more serializer implementation which
> will use Binary Marshaller?
>
> > By the way are there any samples in the code how to use Binary Marshaller
> just to
> > serialize/deserialize arbitrary object? Binary Marshaller documentation
> says that all such
> >  operation performed internally inside Ignite when we using BinaryObject,
> but in my case I am
> >  interested in rather low-level serialization/deserialization API/
>
> Regards,
> Igor Rudyak
>
> 
> Hi Igor!
>
> I moved discussion to dev list.
>
> >>> The next concern is that you need *Ignite Core* module
> We could not avoid adding this module because All base cache store classes
> declared in that module, so I think this module will *be always imported*.
>
> As for other points, I hope community will help us.
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

[jira] [Created] (IGNITE-2496) Add new remote listener on а сlientNode must be performed synchronously

[Alexey Stelmak (JIRA)]

Alexey Stelmak created IGNITE-2496:
--

 Summary: Add new remote listener on а сlientNode must be performed 
synchronously
 Key: IGNITE-2496
 URL: https://issues.apache.org/jira/browse/IGNITE-2496
 Project: Ignite
  Issue Type: Bug
  Components: messaging
Reporter: Alexey Stelmak


Current behavior: When you add a new remote listener on the client node, the 
addition takes place asynchronously, without waiting for confirmation from the 
client node.
Required behavior: When you add a new listener on the client node, we need to 
wait for confirmation from the client node.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2498) Offheap memory + peer class loading = ClassNotFoundException

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-2498:
---

 Summary: Offheap memory + peer class loading = 
ClassNotFoundException
 Key: IGNITE-2498
 URL: https://issues.apache.org/jira/browse/IGNITE-2498
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Valentin Kulichenko
Priority: Blocker
 Fix For: 1.6


With offheap memory and peer class loading, cache tries to deserialize value on 
server, even if binary format is used.

To reproduce start a node using {{ignite.sh}} and run attached 
{{OffheapP2PTest}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

IMC Summit: call for papers

[Dmitriy Setrakyan]

Just in case if anyone in the community is interested:

-
The call for speaking proposals for the In-Memory Computing Summit 2016
 closes
February 3rd. The conference is May 23-24 at the Grand Hyatt San Francisco
in Union Square. This event was created for developers, decision makers and
visionaries to network and learn about technologies, solutions and
real-world use cases for in-memory computing.

Speaking proposals for topics related to in-memory computing such as the
following (or topics you suggest) are encouraged:

   - Architecture and design
   - Use cases
   - Performance optimization
   - In-memory computing for Big Data analytics
   - In-memory computing and Apache Spark
   - In-memory computing and Apache Ignite
   - In-memory streaming
   - Scalable machine learning
   - Hardware considerations for in-memory computing
   - New in-memory computing solutions

Submit your proposal now at http://imcsummit.org/speaker-proposals/
 by
the February 3 deadline.

[GitHub] ignite pull request: IGNITE-2324 .NET: Code analysis

[ptupitsyn]

Github user ptupitsyn closed the pull request at:

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


---
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-2494) Collect TX cache memory metrics for local execution.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2494:
---

 Summary: Collect TX cache memory metrics for local execution.
 Key: IGNITE-2494
 URL: https://issues.apache.org/jira/browse/IGNITE-2494
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Ilya Lantukh
Priority: Critical
 Fix For: 1.6


We need to collect both throughput and memory allocation logs for the following 
parameters:
1) PRIMARY_SYNC vs FULL_SYNC
2) Client vs data node
3) Threads: 1, cores/2, cores



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2495) ODBC: One-row queries can not be fetched.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-2495:
---

 Summary: ODBC: One-row queries can not be fetched.
 Key: IGNITE-2495
 URL: https://issues.apache.org/jira/browse/IGNITE-2495
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Affects Versions: 1.5.0.final
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.6


Any SQL query that contain only one row in rowset return {{NO_DATA}} when 
fetched.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request: IGNITE-1759 .Net: Guid read/write is not plat...

[ptupitsyn]

Github user ptupitsyn closed the pull request at:

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


---
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.
---

[GitHub] ignite pull request: IGNITE-1759 .Net: Make guid read/write platfo...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1759 .Net: Make guid read/write platform-safe.



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

$ git pull https://github.com/ptupitsyn/ignite ignite-1759

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

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


commit 52698b17068475536752c9ec9e6cc0a36b18ebaa
Author: ptupitsyn 
Date:   2015-10-21T17:28:47Z

wip todos

commit 77132979501ba32f27cc31f35bdedee1ddaa3486
Author: ptupitsyn 
Date:   2015-10-22T09:04:10Z

Endianness issue fixed

commit d5173706035a45936993902156198c41f88b8ce6
Author: ptupitsyn 
Date:   2015-10-22T09:41:20Z

WriteGuidBytewise

commit 3996dc01e3fbf05ceebc25d5a8a04ec977bc5ec6
Author: ptupitsyn 
Date:   2015-10-22T10:07:12Z

wip

commit 022300a1421359d57a598189f91787fd62532b47
Author: ptupitsyn 
Date:   2015-10-22T10:09:34Z

GetIsGuidSequentialPacked improved check

commit 6733894c879bf139002a4340858f7979ca48d16b
Author: ptupitsyn 
Date:   2015-10-22T10:11:24Z

wip

commit ddc5fc4c3f2f1425c39f0692c2d29c43d7239ef4
Author: ptupitsyn 
Date:   2015-10-22T10:11:59Z

Merge remote-tracking branch 'remotes/upstream/ignite-1282' into ignite-1759

commit fb490ba6e9a01ebeb404a54ac3f2b8bbeaaa70d8
Author: Pavel Tupitsyn 
Date:   2015-11-11T10:46:02Z

Merge remote-tracking branch 'remotes/upstream/ignite-1282' into ignite-1759

Conflicts:
modules/platforms/dotnet/Apache.Ignite.Core/Impl/Binary/BinaryUtils.cs

commit a4da6b3d06728bbd0ece6ce613d438151220ed58
Author: Pavel Tupitsyn 
Date:   2015-11-11T10:46:11Z

fix merge

commit b1747a4efa03f9d7d137a3336f5451eb694f2781
Author: Pavel Tupitsyn 
Date:   2016-01-28T14:17:05Z

Merge remote-tracking branch 'remotes/upstream/master' into ignite-1759

commit b843c175deedb41906e047fcd1fa9da5ae1be965
Author: Pavel Tupitsyn 
Date:   2016-01-28T14:20:53Z

renaming

commit 30acdff64d8b86cd0846779acd28c4db0be34c43
Author: Pavel Tupitsyn 
Date:   2016-01-28T14:27:21Z

Unit test added




---
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.
---

[GitHub] ignite pull request: IGNITE-2324 Fixed remaining code analysis war...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-2324 Fixed remaining code analysis warnings

Missing docs, unused directives

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

$ git pull https://github.com/ptupitsyn/ignite ignite-2324-1

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

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


commit 2532c8c953fe85c31ebd2e89c001143a07f7e5ca
Author: Pavel Tupitsyn 
Date:   2016-01-28T13:33:08Z

Fixing warnings

commit cf9aa84928021c3eaaaeb3f14d99b48d21ce4c9d
Author: Pavel Tupitsyn 
Date:   2016-01-28T13:36:52Z

wip

commit 2db23a32a06f678c3fc27f3405c6377dfd0dac0f
Author: Pavel Tupitsyn 
Date:   2016-01-28T13:37:44Z

wip

commit 38a40f342c6ac3c9792ff16ab721b2fee541012f
Author: Pavel Tupitsyn 
Date:   2016-01-28T13:41:44Z

Fix XML comments




---
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: Importing Ignite source into Eclipse

[Edouard Chevalier]

in response to 
http://apache-ignite-developers.2346864.n4.nabble.com/Importing-Ignite-source-into-Eclipse-tp2074p2077.html 
. (I don't know how to retrieve mail number from nabble).



I can handle this jira, as i am used to eclipse (and had problems while 
importing ignite :-)) and would like to still used it to go on contributing.

Edouard