[jira] [Created] (IGNITE-1884) .Net: JNI local ref can't be accessed from another thread

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1884:
---

 Summary: .Net: JNI local ref can't be accessed from another thread
 Key: IGNITE-1884
 URL: https://issues.apache.org/jira/browse/IGNITE-1884
 Project: Ignite
  Issue Type: Bug
  Components: interop
Affects Versions: 1.1.4
Reporter: Pavel  Tupitsyn
Assignee: Pavel  Tupitsyn
 Fix For: 1.5


Documentation: 
https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html

{code}
Local references are only valid in the thread in which they are created. The 
native code must not pass local references from one thread to another.
{code}

We have two places where we DO pass local JNI reference to another thread:
* CacheParallelLoadStoreAdapter
* CacheTestStore.LoadCache

For some reason it has worked for us before.
But renamings in IGNITE-1881 have caused test execution order to change, and 
these store tests cause process crash.

To reproduce, BinaryBuilderSelfTest (former PortableApiSelfTest) has to be 
executed before store tests. All other tests can be excluded. 100% repro rate: 
"FATAL ERROR in native method: Bad global or local ref passed to JNI".




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

Re: Ignite-1.5 Release

[Raul Kripalani]

Sorry I haven't made an appearance in this thread yet.

> 6. MQTT streamer
> https://issues.apache.org/jira/browse/IGNITE-535

Yes, it was merged to master before the ignite-1.5 was created.

I'd like to add:

Camel Streamer => https://issues.apache.org/jira/browse/IGNITE-1790
-- I'll merge this as soon as I finished with the OSGi tickets with demand.

OSGi Manifests, Karaf features and possible ClassLoaderCodec SPI (or
whatever agreement we arrive to in mailing lists and Wiki)
-- https://issues.apache.org/jira/browse/IGNITE-1527
-- https://issues.apache.org/jira/browse/IGNITE-1877
-- I'm working actively on these two features.

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

On Mon, Nov 2, 2015 at 1:35 PM, Yakov Zhdanov  wrote:

> Guys,
>
> I think we can start preparation to Ignite-1.5 release which will include
> many interesting features:
>
> 1. Portable object API
> https://issues.apache.org/jira/browse/IGNITE-1486
>
> 2. Ignite.NET and Ignite C++
> https://issues.apache.org/jira/browse/IGNITE-1282
>
> 3. Optimistic serializable transactions
> https://issues.apache.org/jira/browse/IGNITE-1607
>
> 4. Distributed SQL joins - we will be able to query non-collocated data as
> well
> https://issues.apache.org/jira/browse/IGNITE-1232
>
> 5. Enhanced Oracle and IBM JDK interoperability
> https://issues.apache.org/jira/browse/IGNITE-1526
>
> 6. MQTT streamer
> https://issues.apache.org/jira/browse/IGNITE-535
>
> 7. Continuous query failover
> https://issues.apache.org/jira/browse/IGNITE-426
>
> 8. Significant transactional cache performance optimizations - I will merge
> these changes from 'ignite-1.4-slow-server-debug' today or tomorrow.
>
> 9. Many stability and fault-tolerance fixes.
>
> 10. I would also like to include distributed Semaphore. Vladislav, any
> chance you can finish with it this week?
> https://issues.apache.org/jira/browse/IGNITE-
> 638
>
> Thanks to everyone involved! Guys, esp. assignees of mentioned issues,
> please respond to this email and let us know when can we expect your
> changes being merged to master and release branch?
>
> Can someone create ignite-1.5 release branch?
>
> --Yakov
>

Re: Ignite-1.5 Release

[Alexey Goncharuk]

Guys,

A quick update on the release status.

I have spotted several potential slowdowns that I would like to add to 1.5
release. I am currently working in a separate branch and preliminary
testing showed that we can get about 4-5% performance improvement in tx-put
benchmark. There are other potential improvements that I did not benchmark
yet, but I believe it may add another 4-5% for the same benchmark.

Also, as Vladimir noticed, there is IGNITE-1377 issue that is critical for
the release. I can take a closer look at it once I finish with the
performance improvements, however if there is anyone who can handle it now
- it would be great!

2015-11-10 16:36 GMT+03:00 Yakov Zhdanov :

> Vladislav, do you have any updates for
> https://issues.apache.org/jira/browse/IGNITE-638? Or any questions?
>
> --Yakov
>
> 2015-11-02 22:23 GMT+03:00 Vladisav Jelisavcic :
>
> > >10. I would also like to include distributed Semaphore. Vladislav, any
> > >chance you can finish with it this week?
> > >https://issues.apache.org/jira/browse/IGNITE-
> > >638
> >
> > I will have it done by thursday.
> >
> > Best regards,
> > Vladisav
> >
> > On Mon, Nov 2, 2015 at 6:40 PM, Dmitriy Setrakyan  >
> > wrote:
> >
> > > On Mon, Nov 2, 2015 at 6:58 AM, M G  wrote:
> > >
> > > > Can/will this include
> > https://issues.apache.org/jira/browse/IGNITE-1681
> > > ?
> > > >
> > >
> > > I don’t see why not. Would be nice if one of the committers could pick
> up
> > > the review for this patch.
> > >
> > >
> > > >
> > > > On Mon, Nov 2, 2015 at 1:51 PM, Anton Vinogradov <
> > > avinogra...@gridgain.com
> > > > >
> > > > wrote:
> > > >
> > > > > Branch ignite-1.5 created.
> > > > >
> > > > > On Mon, Nov 2, 2015 at 4:39 PM, Anton Vinogradov <
> > > > avinogra...@gridgain.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > I assume that correct link at 10th feature is
> > > > > > https://issues.apache.org/jira/browse/IGNITE-638
> > > > > >
> > > > > > On Mon, Nov 2, 2015 at 4:35 PM, Yakov Zhdanov <
> yzhda...@apache.org
> > >
> > > > > wrote:
> > > > > >
> > > > > >> Guys,
> > > > > >>
> > > > > >> I think we can start preparation to Ignite-1.5 release which
> will
> > > > > include
> > > > > >> many interesting features:
> > > > > >>
> > > > > >> 1. Portable object API
> > > > > >> https://issues.apache.org/jira/browse/IGNITE-1486
> > > > > >>
> > > > > >> 2. Ignite.NET and Ignite C++
> > > > > >> https://issues.apache.org/jira/browse/IGNITE-1282
> > > > > >>
> > > > > >> 3. Optimistic serializable transactions
> > > > > >> https://issues.apache.org/jira/browse/IGNITE-1607
> > > > > >>
> > > > > >> 4. Distributed SQL joins - we will be able to query
> non-collocated
> > > > data
> > > > > as
> > > > > >> well
> > > > > >> https://issues.apache.org/jira/browse/IGNITE-1232
> > > > > >>
> > > > > >> 5. Enhanced Oracle and IBM JDK interoperability
> > > > > >> https://issues.apache.org/jira/browse/IGNITE-1526
> > > > > >>
> > > > > >> 6. MQTT streamer
> > > > > >> https://issues.apache.org/jira/browse/IGNITE-535
> > > > > >>
> > > > > >> 7. Continuous query failover
> > > > > >> https://issues.apache.org/jira/browse/IGNITE-426
> > > > > >>
> > > > > >> 8. Significant transactional cache performance optimizations - I
> > > will
> > > > > >> merge
> > > > > >> these changes from 'ignite-1.4-slow-server-debug' today or
> > tomorrow.
> > > > > >>
> > > > > >> 9. Many stability and fault-tolerance fixes.
> > > > > >>
> > > > > >> 10. I would also like to include distributed Semaphore.
> Vladislav,
> > > any
> > > > > >> chance you can finish with it this week?
> > > > > >> https://issues.apache.org/jira/browse/IGNITE-
> > > > > >> 638
> > > > > >>
> > > > > >> Thanks to everyone involved! Guys, esp. assignees of mentioned
> > > issues,
> > > > > >> please respond to this email and let us know when can we expect
> > your
> > > > > >> changes being merged to master and release branch?
> > > > > >>
> > > > > >> Can someone create ignite-1.5 release branch?
> > > > > >>
> > > > > >> --Yakov
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[GitHub] ignite pull request: IGNITE-1566: fix + new test.

[iveselovskiy]

GitHub user iveselovskiy opened a pull request:

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

IGNITE-1566: fix + new test.



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

$ git pull https://github.com/iveselovskiy/ignite ignite-1566

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

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


commit 719803c3203e5558eb8e4348ea58b31e9b0c7c52
Author: iveselovskiy 
Date:   2015-11-10T18:27:23Z

IGNITE-1566: fix + new test.




---
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: OSGi migration may require a special marshaller

[Andrey Kornev]

Raul,

Could you please be a bit more specific about the nature of your disagreement? 
Is the proposed SPI not generic enough? Or, is it just the naming?

As per Romain's suggestion, could you please just make sure the SPI is hooked 
into the new marshalling implementation and  a no-op codec implementation is 
available in time for the 1.5 release? This would be the first step toward full 
OSGi support in 1.6.

Thanks
Andrey

> From: ra...@apache.org
> Date: Tue, 10 Nov 2015 18:22:59 +
> Subject: Re: OSGi migration may require a special marshaller
> To: dev@ignite.apache.org
> 
> Hi Romain,
> 
> The implementation I have in mind won't be costly. I'm working on it this
> week.
> 
> I still don't agree with a ClassLoaderCodec SPI as-is. If we create an SPI
> it should be for more generic hinting applicable in other circumstances
> during serialisation with other frameworks and what not.
> 
> Otherwise, we should not create a pluggable SPI at all and simply implement
> an option. As a matter of fact, with the last solution I proposed I don't
> think there will be any edge cases at all where users would need to create
> their own "ClassLoaderCodec" at all.
> 
> Regards,
> 
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
> 
> On Tue, Nov 10, 2015 at 3:06 PM, Romain Gilles 
> wrote:
> 
> > To be honest Raoul, I'm more interesting in the interface (SPI) declaration
> > than the implementation. If you can do it for the 1.5 I'm ok. Otherwise I
> > ready to start it by introducing the interface and implementing the dummy
> > version for non OSGi environment.
> >
> > It will free me to implement a temporary OSGi version by the time you are
> > done with the overall IGNITE-1270 tasks.
> >
> > Thanks,
> >
> > Romain
> >
> > Le mar. 10 nov. 2015 à 15:42, Raul Kripalani  a écrit :
> >
> > > Hi Romain,
> > >
> > > If you don't mind, I'm working on the entire OSGi integration including
> > the
> > > serialisation technique.
> > >
> > > I'll ping you if I need help.
> > >
> > > Thanks for your collaboration,
> > >
> > > *Raúl Kripalani*
> > > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> > > Messaging Engineer
> > > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > > http://blog.raulkr.net | twitter: @raulvk
> > >
> > > On Tue, Nov 10, 2015 at 1:50 PM, Romain Gilles 
> > > wrote:
> > >
> > > > Hi,
> > > > I have put my comments. Hope they will make the things progress :)
> > > > Should I start to implement this ticket or should I wait and see if
> > Raoul
> > > > want to take it?
> > > >
> > > > Romain
> > > >
> > > > Le mar. 10 nov. 2015 à 02:58, Dmitriy Setrakyan  > >
> > > a
> > > > écrit :
> > > >
> > > > > Thanks Raul, great points! I have created a ticket for the
> > > > > class-loader-detection design, described on wiki:
> > > > >
> > > > > https://issues.apache.org/jira/browse/IGNITE-1877
> > > > >
> > > > > D.
> > > > >
> > > > > On Mon, Nov 9, 2015 at 3:42 PM, Raul Kripalani 
> > > wrote:
> > > > >
> > > > > > Hey Romain,
> > > > > >
> > > > > > I've updated the design proposal in the Wiki with my input. Could
> > you
> > > > > > please have a look and let me know what you think?
> > > > > >
> > > > > > I'll implement a proof of concept of my proposed
> > > > > marshalling/unmarshalling
> > > > > > strategy and push it to Git so you can take it for a spin.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > *Raúl Kripalani*
> > > > > > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big
> > Data
> > > > and
> > > > > > Messaging Engineer
> > > > > > http://about.me/raulkripalani |
> > > > http://www.linkedin.com/in/raulkripalani
> > > > > > http://blog.raulkr.net | twitter: @raulvk
> > > > > >
> > > > > > On Fri, Nov 6, 2015 at 4:05 PM, Romain Gilles <
> > > romain.gil...@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > > I will put some sample code this WE. I'm exhausted sorry for the
> > > > > delay...
> > > > > > > Romain
> > > > > > >
> > > > > > > Le ven. 6 nov. 2015 à 00:45, Andrey Kornev <
> > > andrewkor...@hotmail.com
> > > > >
> > > > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > We've made an attempt to formalize the approach to Ignite's
> > OSGi
> > > > > > > > enablement:
> > > > > > > >
> > > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/OSGI+Compatibility.
> > > > > > > > Please have a look and feel free to provide your positive
> > > feedback
> > > > > :)))
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > Andrey
> > > > > > > >
> > > > > > > > > From: dsetrak...@apache.org
> > > > > > > > > Date: Wed, 4 Nov 2015 09:26:17 -0800
> > 

Re: OSGi migration may require a special marshaller

[Raul Kripalani]

Hi Romain,

The implementation I have in mind won't be costly. I'm working on it this
week.

I still don't agree with a ClassLoaderCodec SPI as-is. If we create an SPI
it should be for more generic hinting applicable in other circumstances
during serialisation with other frameworks and what not.

Otherwise, we should not create a pluggable SPI at all and simply implement
an option. As a matter of fact, with the last solution I proposed I don't
think there will be any edge cases at all where users would need to create
their own "ClassLoaderCodec" at all.

Regards,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

On Tue, Nov 10, 2015 at 3:06 PM, Romain Gilles 
wrote:

> To be honest Raoul, I'm more interesting in the interface (SPI) declaration
> than the implementation. If you can do it for the 1.5 I'm ok. Otherwise I
> ready to start it by introducing the interface and implementing the dummy
> version for non OSGi environment.
>
> It will free me to implement a temporary OSGi version by the time you are
> done with the overall IGNITE-1270 tasks.
>
> Thanks,
>
> Romain
>
> Le mar. 10 nov. 2015 à 15:42, Raul Kripalani  a écrit :
>
> > Hi Romain,
> >
> > If you don't mind, I'm working on the entire OSGi integration including
> the
> > serialisation technique.
> >
> > I'll ping you if I need help.
> >
> > Thanks for your collaboration,
> >
> > *Raúl Kripalani*
> > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> > Messaging Engineer
> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > http://blog.raulkr.net | twitter: @raulvk
> >
> > On Tue, Nov 10, 2015 at 1:50 PM, Romain Gilles 
> > wrote:
> >
> > > Hi,
> > > I have put my comments. Hope they will make the things progress :)
> > > Should I start to implement this ticket or should I wait and see if
> Raoul
> > > want to take it?
> > >
> > > Romain
> > >
> > > Le mar. 10 nov. 2015 à 02:58, Dmitriy Setrakyan  >
> > a
> > > écrit :
> > >
> > > > Thanks Raul, great points! I have created a ticket for the
> > > > class-loader-detection design, described on wiki:
> > > >
> > > > https://issues.apache.org/jira/browse/IGNITE-1877
> > > >
> > > > D.
> > > >
> > > > On Mon, Nov 9, 2015 at 3:42 PM, Raul Kripalani 
> > wrote:
> > > >
> > > > > Hey Romain,
> > > > >
> > > > > I've updated the design proposal in the Wiki with my input. Could
> you
> > > > > please have a look and let me know what you think?
> > > > >
> > > > > I'll implement a proof of concept of my proposed
> > > > marshalling/unmarshalling
> > > > > strategy and push it to Git so you can take it for a spin.
> > > > >
> > > > > Regards,
> > > > >
> > > > > *Raúl Kripalani*
> > > > > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big
> Data
> > > and
> > > > > Messaging Engineer
> > > > > http://about.me/raulkripalani |
> > > http://www.linkedin.com/in/raulkripalani
> > > > > http://blog.raulkr.net | twitter: @raulvk
> > > > >
> > > > > On Fri, Nov 6, 2015 at 4:05 PM, Romain Gilles <
> > romain.gil...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > > I will put some sample code this WE. I'm exhausted sorry for the
> > > > delay...
> > > > > > Romain
> > > > > >
> > > > > > Le ven. 6 nov. 2015 à 00:45, Andrey Kornev <
> > andrewkor...@hotmail.com
> > > >
> > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > We've made an attempt to formalize the approach to Ignite's
> OSGi
> > > > > > > enablement:
> > > > > > >
> > > >
> https://cwiki.apache.org/confluence/display/IGNITE/OSGI+Compatibility.
> > > > > > > Please have a look and feel free to provide your positive
> > feedback
> > > > :)))
> > > > > > >
> > > > > > > Thanks
> > > > > > > Andrey
> > > > > > >
> > > > > > > > From: dsetrak...@apache.org
> > > > > > > > Date: Wed, 4 Nov 2015 09:26:17 -0800
> > > > > > > > Subject: Re: OSGi migration may require a special marshaller
> > > > > > > > To: dev@ignite.apache.org
> > > > > > > >
> > > > > > > > On Wed, Nov 4, 2015 at 9:07 AM, Romain Gilles <
> > > > > romain.gil...@gmail.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Dmitriy,
> > > > > > > > > I found this post that explain how to find a bundle based
> on
> > > its
> > > > > > bundle
> > > > > > > > > name and version.
> > > > > > > > > This post explain for the past to now how to do it in the
> > > > standard
> > > > > > way
> > > > > > > with
> > > > > > > > > "pull" approach:
> > > > > https://www.eclipse.org/forums/index.php/t/205719/
> > > > > > > > > Regarding the version of OSGi you want to support then some
> > > > > solutions
> > > > > > > will
> > > > > > > > > works some others will not.
> > > > > > > 

[jira] [Created] (IGNITE-1885) Ignite ZooKeeper: Upgrade Curator to 2.9.1

[JIRA]

Raúl Kripalani created IGNITE-1885:
--

 Summary: Ignite ZooKeeper: Upgrade Curator to 2.9.1
 Key: IGNITE-1885
 URL: https://issues.apache.org/jira/browse/IGNITE-1885
 Project: Ignite
  Issue Type: Improvement
  Components: ignite-zookeeper
Affects Versions: ignite-1.4
Reporter: Raúl Kripalani
Assignee: Raúl Kripalani
 Fix For: 1.5


Upgrade the Apache Curator dependencies to 2.9.1.



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

Ignite interpreter for Zeppelin

[Konstantin Boudnik]

Guys,

we are working to have Zeppelin as a part of upcoming Bigtop 1.1 stack. Does
anyone here has/can share with us the interpreter.json content for Ignite, so
we don't need to re-invent the wheel?

Thanks in advance!
-- 
Take care,
Cos
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
Cos' pubkey: http://people.apache.org/~cos/cos.asc

  Wisdom of the hour 

You will have domestic happiness and faithful friends.


signature.asc
Description: Digital signature

[jira] [Created] (IGNITE-1886) NPE in H2 when running query with subselects

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-1886:
---

 Summary: NPE in H2 when running query with subselects
 Key: IGNITE-1886
 URL: https://issues.apache.org/jira/browse/IGNITE-1886
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Valentin Kulichenko
Priority: Critical
 Fix For: 1.5


Test reproducing the issue is attached. NPE is thrown as a result (see below).

Corresponding user@ thread: 
http://apache-ignite-users.70518.x6.nabble.com/Does-Ignite-support-nested-SQL-Queries-td1714.html

{noformat}
Exception in thread "main" javax.cache.CacheException: class 
org.apache.ignite.IgniteException: Failed to parse query: SELECT a.* FROM 
(SELECT CASE WHEN u.id < 100 THEN u.id ELSE ug.id END id FROM "UserCache".user 
u, userorder ug WHERE u.id = ug.usrid) a, (SELECT CASE WHEN og.goodid < 5 THEN 
100 ELSE og.goodid END id FROM userorder ug, "OrderGoodCache".ordergood og 
WHERE ug.id = og.orderid) b WHERE a.id = b.id
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:636)
at 
org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
Caused by: class org.apache.ignite.IgniteException: Failed to parse query: 
SELECT a.* FROM (SELECT CASE WHEN u.id < 100 THEN u.id ELSE ug.id END id FROM 
"UserCache".user u, userorder ug WHERE u.id = ug.usrid) a, (SELECT CASE WHEN 
og.goodid < 5 THEN 100 ELSE og.goodid END id FROM userorder ug, 
"OrderGoodCache".ordergood og WHERE ug.id = og.orderid) b WHERE a.id = b.id
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:641)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:627)
... 6 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to parse 
query: SELECT a.* FROM (SELECT CASE WHEN u.id < 100 THEN u.id ELSE ug.id END id 
FROM "UserCache".user u, userorder ug WHERE u.id = ug.usrid) a, (SELECT CASE 
WHEN og.goodid < 5 THEN 100 ELSE og.goodid END id FROM userorder ug, 
"OrderGoodCache".ordergood og WHERE ug.id = og.orderid) b WHERE a.id = b.id
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1510)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:634)
... 7 more
Caused by: javax.cache.CacheException: Failed to parse query: SELECT a.* FROM 
(SELECT CASE WHEN u.id < 100 THEN u.id ELSE ug.id END id FROM "UserCache".user 
u, userorder ug WHERE u.id = ug.usrid) a, (SELECT CASE WHEN og.goodid < 5 THEN 
100 ELSE og.goodid END id FROM userorder ug, "OrderGoodCache".ordergood og 
WHERE ug.id = og.orderid) b WHERE a.id = b.id
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:938)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:636)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:634)
at 
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1492)
... 8 more
Caused by: org.h2.jdbc.JdbcSQLException: General error: 
"java.lang.NullPointerException" [5-175]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:332)
at org.h2.message.DbException.get(DbException.java:161)
at org.h2.message.DbException.convert(DbException.java:284)
at org.h2.message.DbException.toSQLException(DbException.java:257)
at org.h2.message.TraceObject.logAndConvert(TraceObject.java:368)
at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:270)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:935)
... 12 more
Caused by: java.lang.NullPointerException
at org.h2.expression.Function.getCost(Function.java:2391)
at org.h2.expression.Comparison.getCost(Comparison.java:480)
at org.h2.expression.ConditionAndOr.optimize(ConditionAndOr.java:133)
at org.h2.expression.ConditionAndOr.optimize(ConditionAndOr.java:131)
at org.h2.command.dml.Select.prepare(Select.java:813)
at 

Re: GIT branch audit

[Konstantin Boudnik]

Branch deletion moratorium is a temp. thing. Should be lifted once they figure
out a couple of things... Shouldn't be set in the first place, IMO

On Mon, Nov 09, 2015 at 01:59PM, Artem Shutak wrote:
> Igniters,
> 
> Since no one can delete any branch Apache Git repo I've been created
> https://cwiki.apache.org/confluence/display/IGNITE/Git+branches+to+delete
> with information about "out-dated" branches.
> 
> I think we should track "Branches to delete" there and then ask Apache
> Infra for batch deletion based on the page information.
> 
> Thoughts?
> 
> 
> 
> -- Artem --
> 
> On Tue, Oct 20, 2015 at 7:46 PM, Dmitriy Setrakyan 
> wrote:
> 
> > Thanks Artem,
> >
> > My only concern here is that we don’t remove any *unmerged* branches. Even
> > if the ticket was closed, it is possible that we forgot to merge. I ask
> > that before deleting a branch, we take an extra step to verify that the
> > changes are in the master.
> >
> > D.
> >
> > On Tue, Oct 20, 2015 at 8:16 AM, Artem Shutak 
> > wrote:
> >
> > > Folks,
> > >
> > > I've reviewed branches.
> > >
> > > Branches under [1] refer to already Closed tickets (61 branches).
> > > Branches under [2] don't refer to any Jira (34 branches).
> > >
> > > I think someone with commiter-rights should remove branches from [1].
> > > Branches from [2] should be deleted by branch creators.
> > >
> > > [1]
> > > ignite-1010 Wrong result for ServiceExample when it start without remote
> > > node  ignite-1182
> > > control-center-agent: user should be able to specify loggin configuration
> > >  ignite-1197
> > > GridDhtInvalidPartitionException in GridDhtLocalPartition.release
> > >  ignite-187
> > GridManager
> > > should be able to add custom attributes
> > >  ignite-274 Cleanup
> > > Visor
> > > code with "TODO GG-9141"
> > >  ignite-275
> > > Rework Visor events collector logic to be flexible
> > >  ignite-282 Restore
> > > IgfsSizeSelfTest test
> > >  ignite-285
> > > Near cache entry is not removed after READ_COMMITTED transaction
> > >  ignite-560-1 Assert
> > in
> > > GridCacheMapEntry.innerUpdate (invalid entry)
> > >  ignite-663 Need fix
> > > build under jdk 8. 
> > > ignite-737
> > > ClusterGroup.forDataNodes() returns empty cluster group for daemon node
> > >  ignite-80 Hangs on
> > > queue
> > > creation in multinode tests
> > >  ignite-80-1 Hangs on
> > > queue creation in multinode tests
> > >  ignite-889 Value is
> > not
> > > loaded from store in pessimistic transaction if loadPreviousValue is
> > false
> > >  ignite-983 Add
> > > translation of primitive types to object types.
> > >  ignite-1159 Redundant
> > > MVCC queue iteration may be removed
> > >  ignite-45-streaming
> > > Support start/close/destroy cache at runtime
> > >  ignite-970 Restore IPC
> > > shared memory TCP communication SPI
> > >  ignite-1002
> > > Deserialized
> > > CachesFilter doesn't have reference to Ignite instance
> > >  ignite-728 Need to
> > > reimplement CREATE-TIME-TTL as eviction policy
> > >  ignite-868 Fix
> > > GridUpdateNotifierSelfTest.testNotifier
> > >  ignite-956 Make
> > version
> > > of scalar compatible with scala 2.10
> > >  ignite-456 [Public
> > TC]
> > > Need to complete patch validation mechanism.
> > >  ignite-488 Configure
> > > TeamCity to run suites on demand under java8
> > >  ignite-648-failover
> > > Implement framework for multi JVM unit tests
> > >  ignite-648-fix
> > > Implement
> > > framework for multi JVM unit tests
> > >  ignite-648-putAll
> > > Implement framework for multi JVM unit tests
> > >  ignite-664 [TC] Need
> > to
> > > split Ignite cache suite
> > > 

Re: IGNITE-1681: loadAll threshold is not configurable for CacheStoreBalancingWrapper

[M G]

Hi Denis

I'm looking at it now

Regards
Mike

On Tue, Nov 10, 2015 at 11:19 AM, Denis Magda  wrote:

> Michael,
>
> Would you mind finishing that task? You should add a couple of tests to
> validate that everything works is expected. I've put all the info into the
> ticket.
>
>
> Regards,
> Denis
>

OSGi Manifest headers and feature repository pushed (IGNITE-1527)

[Raul Kripalani]

Hi all,

Just to inform you that I've pushed the POM changes to generate the OSGi
Manifest for all Java modules except: gce, cloud, hadoop, log4j2, spark,
yarn, mesos, as the prove a bit more difficult for different reasons each.

Some modules are bundles (e.g. mqtt, zookeeper, kafka, etc.) while others
are fragments (indexing, jta, geospatial, spring, ssh). The criteria to
choose between bundle or fragment was whether or not the module contained
internal processors that ignite-code would have to discover.

I also created a features repository under modules/osgi-karaf/features.

If you perform a complete build of the ignite-1527 branch, you should be
able to install the different modules via the features repository. It has
been tested against Karaf 4.0.2:

karaf@root()> feature:repo-add
mvn:org.apache.ignite/ignite-osgi-karaf-features/1.5.0-SNAPSHOT/xml/features
karaf@root()> feature:install ignite-core
karaf@root()> feature:install ignite-mqtt

The ignite-log4j feature spits out a strange message which I'll debug
tomorrow.

Regards,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

Fwd: LOCAL CACHE MODE Configuration settings

[Valentin Kulichenko]

Igniters,

While investigating this issue reported by user, I noticed that LOCAL cache
is fully destroyed when close() is called, which is inconsistent with other
cache modes. Is there any reason for this?

-Val

-- Forwarded message --
From: vkulichenko 
Date: Tue, Nov 10, 2015 at 3:03 PM
Subject: Re: LOCAL CACHE MODE Configuration settings
To: u...@ignite.apache.org


This happens because you use try-with-resources statement and therefore
close
the cache after populating it:

try (IgniteCache myCache =
Ignition.ignite().getOrCreateCache("MY_CACHE")) {
...
}

Local cache is completely destroyed in this case, while partitioned just
closes the current cache reference. I'm not sure why it's implemented this
way and I will start a discussion on dev@.

But anyway, just avoid closing the cache unless you want to destroy it and
it will work for you.

-Val



--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/LOCAL-CACHE-MODE-Configuration-settings-tp1875p1922.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

[GitHub] ignite pull request: Ignite 1681

[endian675]

GitHub user endian675 opened a pull request:

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

Ignite 1681



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

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

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

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


commit 099966a54dd447a66254723493a7f8600a9537d2
Author: agura 
Date:   2015-11-05T00:43:33Z

Dogpile effect tests for CacheStoreBalancingWrapper

commit f88a81e60897e79efc7aea48c73f48ffa786ec5a
Author: M Griggs 
Date:   2015-11-10T22:08:06Z

Make parameter publicly configurable

commit cd9edb333d50f4f6119cdd13b797b1548cf5537b
Author: M Griggs 
Date:   2015-11-10T22:36:13Z

Revert "Make parameter publicly configurable"

This reverts commit f88a81e60897e79efc7aea48c73f48ffa786ec5a.

commit 520b81c0cc3fb72cb792d48382017db777eaaf59
Author: M Griggs 
Date:   2015-11-10T22:48:02Z

Add code to pass parameter in constructor

commit 1988225a0939f35ba70420ab6e40e0336d309ced
Author: M Griggs 
Date:   2015-11-10T22:54:28Z

Merge branch 'ignite-1681' of https://github.com/agura/incubator-ignite 
into ignite-1681

commit a8f1b2267d24fedffe5a86b79fe35d6800c6149a
Author: M Griggs 
Date:   2015-11-10T23:12:59Z

Add test for custom threshold in CacheStoreBalancingWrapper

commit 8d5cfa91e010d008a044e6bd50b5c6f217c4901c
Author: M Griggs 
Date:   2015-11-10T23:13:46Z

Merge branch 'ignite-1681' of https://github.com/endian675/ignite into 
ignite-1681




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

[endian675]

GitHub user endian675 opened a pull request:

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

Ignite 1681



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

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

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

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


commit 099966a54dd447a66254723493a7f8600a9537d2
Author: agura 
Date:   2015-11-05T00:43:33Z

Dogpile effect tests for CacheStoreBalancingWrapper

commit f88a81e60897e79efc7aea48c73f48ffa786ec5a
Author: M Griggs 
Date:   2015-11-10T22:08:06Z

Make parameter publicly configurable

commit cd9edb333d50f4f6119cdd13b797b1548cf5537b
Author: M Griggs 
Date:   2015-11-10T22:36:13Z

Revert "Make parameter publicly configurable"

This reverts commit f88a81e60897e79efc7aea48c73f48ffa786ec5a.

commit 520b81c0cc3fb72cb792d48382017db777eaaf59
Author: M Griggs 
Date:   2015-11-10T22:48:02Z

Add code to pass parameter in constructor

commit 1988225a0939f35ba70420ab6e40e0336d309ced
Author: M Griggs 
Date:   2015-11-10T22:54:28Z

Merge branch 'ignite-1681' of https://github.com/agura/incubator-ignite 
into ignite-1681

commit a8f1b2267d24fedffe5a86b79fe35d6800c6149a
Author: M Griggs 
Date:   2015-11-10T23:12:59Z

Add test for custom threshold in CacheStoreBalancingWrapper

commit 8d5cfa91e010d008a044e6bd50b5c6f217c4901c
Author: M Griggs 
Date:   2015-11-10T23:13:46Z

Merge branch 'ignite-1681' of https://github.com/endian675/ignite into 
ignite-1681




---
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-1878) Implement support to package manager for vendor libs

[Dmitriyff (JIRA)]

Dmitriyff created IGNITE-1878:
-

 Summary: Implement support to package manager for vendor libs
 Key: IGNITE-1878
 URL: https://issues.apache.org/jira/browse/IGNITE-1878
 Project: Ignite
  Issue Type: Sub-task
Affects Versions: 1.5
Reporter: Dmitriyff
Assignee: Dmitriyff
 Fix For: 1.6






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

[GitHub] ignite pull request: ignite-1817 Deprecate RandomEvictionPolicy an...

[agura]

Github user agura closed the pull request at:

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


---
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: About the newbie bug #IGNITE-881

[Yakov Zhdanov]

Hi Ken!

My idea was to quit using distributed atomic long, but switch to invokes
that change values atomically. In most cases this can work over atomic
cache and provide faster performance.

Does anyone in community have comments?

--Yakov

2015-11-10 10:49 GMT+03:00 Ken Cheng :

> Hi Yakov Zhdanov,
>
> I am going to work on the bug
> https://issues.apache.org/jira/browse/IGNITE-881.
> you commented as
>
> # Move handling logic to GridCacheCommandHandler
>
> but I found there is already a class do the same thing
>
> in the DataStructuresCommandHandler.java
>
>
> Can you give more clue about this bug?
>
>
> Thanks,
> kcheng
>

Re: 127.0.0.1 in VmIpFinder

[Denis Magda]

Val,

I've tried to run the nodes using the configuration discussed below on 
OS X Yosemity.

Works perfectly fine, both nodes joined the topology and see each other.

Will try to check on OS X El Captain a bit later.

BTW, the problem may be in IPv6. I googled for post [1]. The issue 
discussed there is not completely the same but quite similar.

Could you disable IPv6 on your side and see whether it works or not?

[1] 
http://superuser.com/questions/830920/curl-local-host-names-on-mac-os-x-yosemite


--
Denis

On 11/6/2015 4:35 AM, Andrey Gura wrote:

I tried it on Linux and Windows 7.

On Fri, Nov 6, 2015 at 3:51 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:


Thanks, Andrey. What OS are you on? Can someone try this on Mac?

For me second node can't join because it can't connect to 127.0.0.1:47500
for some reason. I can't do this with telnet either, which is confusing
because the first one binds to 0.0.0.0 and therefore should be accessible
via all interfaces.

-Val

On Thu, Nov 5, 2015 at 4:45 PM, Andrey Gura  wrote:


Val,

I do it every day and do not have any problems. I tried it now on newest
master branch and again - no problems.

I just comment one line and uncomment other in config:

 
class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">

 

 
 
 
 127.0.0.1:47500..47509
 
 
 



On Fri, Nov 6, 2015 at 2:27 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:


Igniters,

I just tried to switch from multicast to VM IP finder in

example-ignite.xml

and nodes stopped joining each other. If I start two servers, they both
start with order=1; if I start a server and then a client, the client

never

joins.

Can someone else try to do this and see if it's reproduced? For me this
behavior seems very confusing. And actually it means that our examples
don't work out of the box with disabled multicast.

This user seems to have the same issue:



http://apache-ignite-users.70518.x6.nabble.com/Unable-to-connect-to-Local-Node-Only-td1852.html

-Val




--
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com

IGNITE-1681: loadAll threshold is not configurable for CacheStoreBalancingWrapper

[Denis Magda]

Michael,

Would you mind finishing that task? You should add a couple of tests to 
validate that everything works is expected. I've put all the info into 
the ticket.



Regards,
Denis

[jira] [Created] (IGNITE-1880) .Net: Intermittent "Invalid global JNI handle passed to DeleteGlobalRef"

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1880:
---

 Summary: .Net: Intermittent "Invalid global JNI handle passed to 
DeleteGlobalRef"
 Key: IGNITE-1880
 URL: https://issues.apache.org/jira/browse/IGNITE-1880
 Project: Ignite
  Issue Type: Bug
  Components: interop
Affects Versions: 1.5
Reporter: Pavel  Tupitsyn
Assignee: Pavel  Tupitsyn
 Fix For: 1.5


Example of a failure: http://94.72.60.102/viewLog.html?buildId=565513

{code}
[18:07:47] : [Step 10/11] FATAL ERROR in native method: Invalid global JNI 
handle passed to DeleteGlobalRef
[18:07:47] : [Step 10/11] FATAL ERROR in native method: Bad global or local 
ref passed to JNI
{code}

UnmanagedTarget class releases JNI handles in finalizer.
Finalizers run at non-deterministic time. Due to some irrelevant changes there 
may be failures sometimes. Need to ensure that we do not release the same 
handle twice, and that we pass correct handles from unmanaged code.



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

[jira] [Created] (IGNITE-1881) .Net: Rename "portable" to "binary/binarizable"

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1881:
---

 Summary: .Net: Rename "portable" to "binary/binarizable"
 Key: IGNITE-1881
 URL: https://issues.apache.org/jira/browse/IGNITE-1881
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: 1.5
Reporter: Pavel  Tupitsyn
Assignee: Pavel  Tupitsyn
 Fix For: 1.5


https://issues.apache.org/jira/browse/IGNITE-1845 addressed these renames in 
Core, need to do the same in the rest of the codebase.



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

Re: OSGi migration may require a special marshaller

[Dmitriy Setrakyan]

Gentlemen,

I have several comments below…

On Tue, Nov 10, 2015 at 11:52 AM, Raul Kripalani  wrote:

> Andrey, I already specified some points of my disagreement in the Wiki. In
> my previous email I also said: "If we create an SPI it should be for more
> generic hinting applicable in other circumstances during serialisation with
> other frameworks and what not."
>

We should not use the SPI acronym liberally, as SPIs have a totally
different meaning in Ignite. The ClassLoaderCodec should just be a setter
on IgniteConfiguration, not a full-blown SPI.


> What I don't understand is the interest in an SPI for something that
> appears to have been solved by just transmitting the package version and
> using the correct logic on the receiving side to locate the appropriate
> Bundle and its classloader, as I explained in the wiki. That's a fully
> deterministic way of solving this problem.


Raul, we cannot be adding package name and version in all cases, as it will
have a negative impact on performance, especially when there is an
*optimistic* approach that requires no over-the-wire overhead whatsoever.

As I already mentioned before, the default implementation *must* be the
optimistic one, since Ignite is measured based on its performance first and
foremost.

This is the main reason why we actually need an API like ClassLoaderCodec,
so it can have more than one implementation.


> To me, creating an SPI targeted to OSGi class loading doesn't solve any
> problem. We don’t need that much flexibility. A different story would be to
> provide a mechanism to compute generic serialisation/deserialisation
> context data, but you guys already rejected this need in the Wiki.
>

I don’t see how a ClassLoaderCodec is specific to OSGI at all. It does not
have OSGI in its name and should be useful in other cases where custom
class-loading is required.

I would say, however, that ClassLoaderCodec should be specific to
class-loader detection only, and we should not overburden it with other
semantics solved elsewhere in Ignite. For example, custom
serialization/deserialization is handled in Binaryzable interface, much in
the same way as Java solves it with Externalizable interface.

Raul, if you disagree, can you please provide your reasoning here?


> With regards to the naming, sorry to be blunt, but ClassLoaderCodec is an
> awful name. It implies that we are serialising a class loader. Wikipedia
> definition for Codec: "A codec is a device or computer program capable of
> encoding or decoding a digital data stream or signal." ClassLoaderCodec
> would mean "a coder/decoder for a ClassLoader". And we would have not been
> doing that; we would have just calculated and transmitted context data to
> aid deserialisation, i.e. "hints", not a classloader.
>

Naming discussions are always passionate :)

Raul, personally I understand your sentiments, but to be honest I dislike
the names you are proposing even more. I still consider ClassLoaderCodec to
be the most elegant name here, considering all the other options I have
seen. It is concise and symmetric. I am open to changing it, but it must be
for the better, not for the worse.


> If you don't mind, could we please pause this discussion until I get a
> proof of concept working these days? And then we can discuss over an actual
> implementation to get consensus. I'd rather invest my time in that manner.
>

I see your point, but I still felt compelled to reply, especially because
of possible performance impact of the proposed design. Let’s make sure that
we follow the 80/20 rule and keep the default implementation suitable for
80% of use cases with zero performance overhead.


> When is Ignite 1.5 due?
>

Given what I am seeing in the 1.5 release thread, I think we are
realistically looking at the end of next week. Having said that, I would be
against artificially forcing this change into 1.5, especially given the
amount of controversy it generated.

Let’s postpone it for 1.6.


>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>
> On Tue, Nov 10, 2015 at 7:23 PM, Andrey Kornev 
> wrote:
>
> > Raul,
> >
> > Could you please be a bit more specific about the nature of your
> > disagreement? Is the proposed SPI not generic enough? Or, is it just the
> > naming?
> >
> > As per Romain's suggestion, could you please just make sure the SPI is
> > hooked into the new marshalling implementation and  a no-op codec
> > implementation is available in time for the 1.5 release? This would be
> the
> > first step toward full OSGi support in 1.6.
> >
> > Thanks
> > Andrey
> >
> > > From: ra...@apache.org
> > > Date: Tue, 10 Nov 2015 18:22:59 +
> > > Subject: Re: OSGi migration may require a special marshaller
> > > To: dev@ignite.apache.org
> > >
> > > Hi Romain,
> 

[GitHub] ignite pull request: IGNITE-1880 .Net: Intermittent "Invalid globa...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1880 .Net: Intermittent "Invalid global JNI handle passed to 
DeleteGlobalRef"



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

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

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

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


commit 61da28e828566d131e006933b883ef649902bec1
Author: Pavel Tupitsyn 
Date:   2015-11-10T12:40:39Z

IGNITE-1880 .Net: Intermittent "Invalid global JNI handle passed to 
DeleteGlobalRef"




---
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-1881 .Net: Rename "portable" to "binar...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1881 .Net: Rename "portable" to "binary/binarizable"



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

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

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

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


commit 6cc948aa2238b5282ce49e41996e1c23dd114ca6
Author: Pavel Tupitsyn 
Date:   2015-11-05T13:32:43Z

Java renamings

commit 10195a364b5e87fda6d9bbc62685b9dba838d903
Author: Pavel Tupitsyn 
Date:   2015-11-05T13:35:55Z

Fix configs

commit e6d8d825c7f291bdd70228abb20119df0ba0a984
Author: Pavel Tupitsyn 
Date:   2015-11-05T13:57:57Z

wip renamings

commit a9ca759fd5fac7bc861f12babd6a810eb001fa3b
Author: Pavel Tupitsyn 
Date:   2015-11-05T13:58:04Z

wip

commit 4845bfc8f31a13ed595a5d66d7bbcc193bd9f3d6
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:01:26Z

wip renamings

commit d3bfddf8e0e6b134634d1d0abc8ae1155be31cba
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:14:10Z

wip renaming

commit e25e5ff10f3836f5033e68d88c592b95b3743cd4
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:17:04Z

wip

commit 59e71594ee19e6e5721f87d5832682b27bde405a
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:19:24Z

wip

commit fc4666f6d47f81df5b0c86f1a9d60d7430a06486
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:22:00Z

Moving from Portable to Binary folders

commit 3728748d9657ca6e70b84bc905c28950763cca2a
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:25:40Z

Fix namespaces

commit 262a8c563b0848cb67f561eba50154d51ae0521f
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:31:36Z

wip

commit 55de255e33db9b3f0c96e8e688b115212a444dfc
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:33:29Z

wip

commit af5c05dbd564e5f85ce71743a5cc391622d496d5
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:37:44Z

wip

commit ee9002013ba30e4ee2b4a45e0408c366283fc0c7
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:38:39Z

wip

commit e04d909dc56f9637276823120b219d8645e3724d
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:39:23Z

wip

commit 214fd1db936abd980a68918ed89488a3246a9328
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:44:56Z

wip

commit 2ce02c1a5449eade45fc386ec52af3d87fb4d08b
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:49:20Z

wip

commit ae25492c4b497ca8964a6084f85e580ecb3408db
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:50:20Z

wip

commit 7c25ebc7515e0b9cfe181cceff3634e6f7c10ef1
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:51:07Z

wip

commit 533719baa5aaec08fd85b159a431d862b43da411
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:54:39Z

wip

commit 0566bcde848366aba6c86524a23ad8f5f7e90c46
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:55:35Z

wip

commit 6c4f2dac118cb8608bb3859307392a91047f4eea
Author: Pavel Tupitsyn 
Date:   2015-11-05T14:57:17Z

wip

commit cd48ad4235e49835d5eee47afc09c6b56540fc2d
Author: Pavel Tupitsyn 
Date:   2015-11-05T15:19:24Z

wip

commit e7ce19fdb0df7ee179dd4e08e12f1cd5cba09f2b
Author: Pavel Tupitsyn 
Date:   2015-11-05T15:28:04Z

wip

commit b58ee7170ef94ffed747b502cb22742cfc50366d
Author: Pavel Tupitsyn 
Date:   2015-11-05T15:29:56Z

Core project done

commit 3f3eec53ab295dd1954e4ff65f243a6fa652024e
Author: Pavel Tupitsyn 
Date:   2015-11-05T15:30:47Z

wip examples

commit 99b441768d24eb372084991f33ee38c145a4eaef
Author: Pavel Tupitsyn 
Date:   2015-11-05T15:33:51Z

Examples done

commit 0b5ad20d10b79bde254dd975b3aa9e8b051a1975
Author: Pavel Tupitsyn 
Date:   2015-11-05T15:38:12Z

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

Conflicts:

modules/core/src/main/java/org/apache/ignite/platform/dotnet/PlatformDotNetBinaryConfiguration.java

commit f25d41d1724903c1cace01f62c05be8535a9cb39
Author: Pavel Tupitsyn 
Date:   2015-11-05T15:53:13Z

Fixing tests

commit 9b1ed69709cad85b94cb74c5a7f25b1646387e4e
Author: Pavel Tupitsyn 
Date:   2015-11-05T15:55:25Z

Fixing tests




---
If your project 

[GitHub] ignite pull request: Ignite 1681

[endian675]

Github user endian675 closed the pull request at:

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


---
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: OSGi migration may require a special marshaller

[Romain Gilles]

Hi,
I have put my comments. Hope they will make the things progress :)
Should I start to implement this ticket or should I wait and see if Raoul
want to take it?

Romain

Le mar. 10 nov. 2015 à 02:58, Dmitriy Setrakyan  a
écrit :

> Thanks Raul, great points! I have created a ticket for the
> class-loader-detection design, described on wiki:
>
> https://issues.apache.org/jira/browse/IGNITE-1877
>
> D.
>
> On Mon, Nov 9, 2015 at 3:42 PM, Raul Kripalani  wrote:
>
> > Hey Romain,
> >
> > I've updated the design proposal in the Wiki with my input. Could you
> > please have a look and let me know what you think?
> >
> > I'll implement a proof of concept of my proposed
> marshalling/unmarshalling
> > strategy and push it to Git so you can take it for a spin.
> >
> > Regards,
> >
> > *Raúl Kripalani*
> > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> > Messaging Engineer
> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > http://blog.raulkr.net | twitter: @raulvk
> >
> > On Fri, Nov 6, 2015 at 4:05 PM, Romain Gilles 
> > wrote:
> >
> > > Hi,
> > > I will put some sample code this WE. I'm exhausted sorry for the
> delay...
> > > Romain
> > >
> > > Le ven. 6 nov. 2015 à 00:45, Andrey Kornev 
> a
> > > écrit :
> > >
> > > > Hello,
> > > >
> > > > We've made an attempt to formalize the approach to Ignite's OSGi
> > > > enablement:
> > > >
> https://cwiki.apache.org/confluence/display/IGNITE/OSGI+Compatibility.
> > > > Please have a look and feel free to provide your positive feedback
> :)))
> > > >
> > > > Thanks
> > > > Andrey
> > > >
> > > > > From: dsetrak...@apache.org
> > > > > Date: Wed, 4 Nov 2015 09:26:17 -0800
> > > > > Subject: Re: OSGi migration may require a special marshaller
> > > > > To: dev@ignite.apache.org
> > > > >
> > > > > On Wed, Nov 4, 2015 at 9:07 AM, Romain Gilles <
> > romain.gil...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hi Dmitriy,
> > > > > > I found this post that explain how to find a bundle based on its
> > > bundle
> > > > > > name and version.
> > > > > > This post explain for the past to now how to do it in the
> standard
> > > way
> > > > with
> > > > > > "pull" approach:
> > https://www.eclipse.org/forums/index.php/t/205719/
> > > > > > Regarding the version of OSGi you want to support then some
> > solutions
> > > > will
> > > > > > works some others will not.
> > > > > > There is an other way to do this stuff without using those "pull"
> > > style
> > > > > > approach based on BundleTracker. If you want I can give you the
> > code
> > > > to do
> > > > > > it with BundlTracker. I think with this solution you will
> support a
> > > > wider
> > > > > > range of OSGi version.
> > > > > >
> > > > >
> > > > > Romain, if you can provide a generic code sample to look up a
> > > ClassLoader
> > > > > in OSGI based on manifest properties, would be great.
> > > > >
> > > > >
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-1882) Rename BinaryTypeIdMapper to BinaryIdMapper

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1882:
---

 Summary: Rename BinaryTypeIdMapper to BinaryIdMapper
 Key: IGNITE-1882
 URL: https://issues.apache.org/jira/browse/IGNITE-1882
 Project: Ignite
  Issue Type: Task
  Components: general, interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.5


BinaryTypeIdMapper is wrong name because it suggests type ID mapping, while it 
maps both type and field IDs.



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

[jira] [Created] (IGNITE-1883) Test path to swap files of a cache during cache creating

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-1883:
-

 Summary: Test path to swap files of a cache during cache creating
 Key: IGNITE-1883
 URL: https://issues.apache.org/jira/browse/IGNITE-1883
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: ignite-1.4
Reporter: Sergey Kozlov
Assignee: Yakov Zhdanov
Priority: Minor
 Fix For: 1.6


Long name of cache (and long path to IGNITE home) may be a reason of following 
failures if cache configured with swap:
{noformat}
Exception in thread "main" org.apache.ignite.cache.CachePartialUpdateException: 
Failed to update keys (retry update if possible).: [1]
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1615)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:1750)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1024)
at 
org.apache.ignite.examples.datagrid.CachePutGetExample.putGet(CachePutGetExample.java:72)
at 
org.apache.ignite.examples.datagrid.CachePutGetExample.main(CachePutGetExample.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
Caused by: class 
org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException: 
Failed to update keys (retry update if possible).: [1]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.addFailedKeys(GridNearAtomicUpdateFuture.java:1186)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.onResult(GridNearAtomicUpdateFuture.java:657)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.onResult(GridNearAtomicUpdateFuture.java:351)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:2458)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:123)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:253)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:251)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:540)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:273)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:197)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:76)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:159)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to 
update keys on primary node.
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKey(GridNearAtomicUpdateResponse.java:348)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:1884)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1180)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1060)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:2441)