Re: Ignite-1.5 Release

[Anton Vinogradov]

Branch ignite-1.5 created.

On Mon, Nov 2, 2015 at 4:39 PM, Anton Vinogradov 
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  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-1835 .Net: Use thread-local pool to st...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1835 .Net: Use thread-local pool to store schemas in PortableWriter



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

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

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

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


commit aa5cf8cb507c1e65794b6ed92b970a40221be3cf
Author: Pavel Tupitsyn 
Date:   2015-11-02T13:55:43Z

wip

commit ebad1d6b93ef27b45c405753a1df5a0500cffb3c
Author: Pavel Tupitsyn 
Date:   2015-11-02T14:40:22Z

wip

commit b885ef55f6d4d030a7e5d9275159b16117c9f92b
Author: Pavel Tupitsyn 
Date:   2015-11-02T14:47:44Z

wip

commit e5219b872eb4dc0e72d30c426d167ce759c6e741
Author: Pavel Tupitsyn 
Date:   2015-11-02T14:48:22Z

wip error handling

commit 19cc6e3b7d5856191b58d1469b17cd86f5469303
Author: Pavel Tupitsyn 
Date:   2015-11-02T14:52:35Z

wip hashing

commit 131dccda57f6d234f245d507567ef82d6ad7328f
Author: Pavel Tupitsyn 
Date:   2015-11-02T15:00:01Z

Cache threadLocal holder before access

commit 9d491a3271da5b10e8e29fe38c4e737b16c69a33
Author: Pavel Tupitsyn 
Date:   2015-11-02T15:07:14Z

Builder error handling

commit 3b180903fbf6ce7dd3b488cb7833b4014881c1c7
Author: Pavel Tupitsyn 
Date:   2015-11-02T15:15:51Z

Fix builder

commit 1aea3106dfbbca529ddd10d540900f1aa3faeb42
Author: Pavel Tupitsyn 
Date:   2015-11-02T15:17:00Z

wip

commit 90515132cd42b5e5136801d568cfd61de38044fd
Author: Pavel Tupitsyn 
Date:   2015-11-02T15:20:06Z

Builder error handling

commit 8c2f09e72903137d1dfb854676155f865be5e1da
Author: Pavel Tupitsyn 
Date:   2015-11-02T15:24:10Z

Merge from 1282

commit 1c3833742a5545f5d598fbe53a00b1f10833
Author: Pavel Tupitsyn 
Date:   2015-11-02T15:24:21Z

Merge from 1282




---
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-1838) Implement fast-path deserialization of common types in PortableObjectImpl.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1838:
---

 Summary: Implement fast-path deserialization of common types in 
PortableObjectImpl.
 Key: IGNITE-1838
 URL: https://issues.apache.org/jira/browse/IGNITE-1838
 Project: Ignite
  Issue Type: Task
  Components: general, interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.5


See PortableObjectImpl and PortableObjectOffheapImpl, method "fieldByOrder". 
We need to add fast-path deserializtion of the following types:

DECIMAL
STRING
UUID
DATE
TIMESTAMP




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

Re: Request add me to development list

[Dmitriy Setrakyan]

Prabhat,

It looks like you are incorrectly subscribed to the dev list and I always
have to manually approve your emails before they get distributed.

Can you please try subscribing again by sending an email to
dev-subscr...@ignite.apache.org. Please make sure to follow the simple
instructions in the reply email.

D.

On Mon, Nov 2, 2015 at 4:02 AM, Yakov Zhdanov  wrote:

> Done!
>
> --Yakov
>
> 2015-11-02 14:53 GMT+03:00 Denis Magda :
>
> > Yakov, Dmitriy or anyone else from the community with administrative
> > rights please provide Prabhat's JIRA account with all required
> permissions.
> >
> > --
> > Denis
> >
> > On 11/2/2015 1:49 PM, Prabhat Ranjan wrote:
> >
> >> Thanks Denis.
> >>
> >> Please set required permission to my  JIRA account 'prabhat'.
> >>
> >> Regards,
> >> Prabhat
> >>
> >>
> >>
> >> On 2 November 2015 at 19:26, Denis Magda > dma...@gridgain.com>> wrote:
> >>
> >> Hi Prabhat,
> >>
> >> Welcome on board!
> >>
> >> Please share your JIRA account with us and we will set all
> >> required permissions for it. Once it has been done you will be
> >> able to assign that ticket to you by yourself.
> >>
> >> Regards,
> >> Denis
> >>
> >>
> >> On 10/31/2015 3:42 PM, Prabhat Ranjan wrote:
> >>
> >> Hi,
> >>
> >> I  work in financial domain and have 10 years java experience.
> >> I  used Grid gain in-memory data grid  for  a POC (proof of
> >> concept )
> >> project at my company last year.
> >>
> >> I would like to contribute to ignite project.
> >>
> >> Also, could you please assign following issue to me.
> >>
> >> https://issues.apache.org/jira/browse/IGNITE-1783
> >>
> >> Regards,
> >> Prabhat
> >> +61 410 603 242 
> >>
> >>
> >>
> >>
> >
>

Re: Ignite-1.5 Release

[Anton Vinogradov]

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

[M G]

Can/will this include https://issues.apache.org/jira/browse/IGNITE-1681 ?

On Mon, Nov 2, 2015 at 1:51 PM, Anton Vinogradov 
wrote:

> Branch ignite-1.5 created.
>
> On Mon, Nov 2, 2015 at 4:39 PM, Anton Vinogradov  >
> 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 
> 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-1397 Load/consistency test framework

[ashutakGG]

Github user ashutakGG closed the pull request at:

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


---
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: Ignite-1.5 Release

[Dmitriy Setrakyan]

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

[jira] [Created] (IGNITE-1842) Add dropdown list of existing fields for setting it in index

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1842:
--

 Summary: Add dropdown list of existing fields for setting it in 
index
 Key: IGNITE-1842
 URL: https://issues.apache.org/jira/browse/IGNITE-1842
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Priority: Minor


If user already set field list will be useful to select existing field from 
dropdown list for index.



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

[jira] [Created] (IGNITE-1841) Need add ConnectorConfiguration to cluster configuration

[Andrey Novikov (JIRA)]

Andrey Novikov created IGNITE-1841:
--

 Summary: Need add ConnectorConfiguration to cluster configuration
 Key: IGNITE-1841
 URL: https://issues.apache.org/jira/browse/IGNITE-1841
 Project: Ignite
  Issue Type: Sub-task
Reporter: Andrey Novikov






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

Re: Ignite-1.5 Release

[Dmitriy Setrakyan]

Thanks Vladislav!

Would also be nice to get an update from other committers involved in the
outlined tickets. Specifically whether the ticket has been merged to master
or not, and if not, what should be the expectation.

Thanks,
D.

On Mon, Nov 2, 2015 at 11:23 AM, Vladisav Jelisavcic 
wrote:

> >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  >
> > > > 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: Request add me to development list

[Denis Magda]

Hi Prabhat,

Welcome on board!

Please share your JIRA account with us and we will set all required 
permissions for it. Once it has been done you will be able to assign 
that ticket to you by yourself.


Regards,
Denis

On 10/31/2015 3:42 PM, Prabhat Ranjan wrote:

Hi,

I  work in financial domain and have 10 years java experience.
I  used Grid gain in-memory data grid  for  a POC (proof of concept )
project at my company last year.

I would like to contribute to ignite project.

Also, could you please assign following issue to me.

https://issues.apache.org/jira/browse/IGNITE-1783

Regards,
Prabhat
+61 410 603 242

Re: Contributing to Ignite

[Дмитрийфф]

I would like to work on this issue
https://issues.apache.org/jira/browse/IGNITE-1831

please assign this issue to me, my account on jira @Dmitriyff

2015-11-02 14:59 GMT+07:00 Alexey Kuznetsov :

> Hi!
>
> Welcome to Ignite Apache.
>
> We have feature that requires web development: Apache Web Console
> See: https://issues.apache.org/jira/browse/IGNITE-843
>
> Please take a look at this issue it has a lot of open sub-tasks, feel free
> to select any and start contributing.
>
> You may ask any questions here.
>
>
> On Mon, Nov 2, 2015 at 2:24 PM, Дмитрийфф  wrote:
>
> > Hello,
> >
> > I am Dmitriy.
> >
> > I am looking for contributing in the project. I have a lot of experience
> in
> > Web-development.
> >
> > Best Regards.
> >
> > --
> > By Dmitriyff Smile =-)
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>



-- 
By Dmitriyff Smile =-)

RE: OSGi migration may require a special marshaller

[Andrey Kornev]

Raul,

The fundamental hurdle we need to jump over to make Ignite OSGi-enabled is the 
marshalling. More specifically the issue is with deserialization of the classes 
that are provided by the bundles other than the Ignite bundle itself. 

When the Ignite transport layer receives a message it needs to figure out how 
to deserialize the bytes and for that it needs to know the bundle that provides 
the class to be deserailized. At this point TCCL is of no use. To make things 
more complex, the class may contain other classes that come from other bundles, 
and so on recursively. This means that each object in the hierarchy must be 
serialized with its bundle name (or bundle id), so that the deserializer will 
then be able to correctly resolve the class while traversing the object 
hierarchy during deserialization.

Unfortunately, Ignite's OptimizedMarshaller is lacking the ability to plug in a 
custom class resolver. Romain's solution was to use Kryo that does provide a 
way to customize class resolution. It has solved the problem of capturing the 
bundle info and he was able to successfully run Ignite as a bundle in an OSGi 
container (after some repackaging and inclusion of the manifest). But 
Kryo-based marshalling introduced a lot of complexity to the code and incorrect 
use of Kryo's numerous serializers caused some weird hard-to-debug issues in 
the Ignite core (like duplicate cache entries due to incorrect marshalling of 
the GridDhtPArtitonFullMap class -- go figure!). Overall the Kryo-based 
solution is brittle and hard to maintain.

I feel the correct solution to OSGi problem would be to 
1) enhance the OptimizedMarshaller to allow custom class resolution.
2) provide an OSGi-enabled OptimizedMarshaller (in addition to the original 
one) to be used in OSGi environment.

Regards
Andrey

> From: ra...@apache.org
> Date: Mon, 2 Nov 2015 12:41:47 +
> Subject: Re: OSGi migration may require a special marshaller
> To: dev@ignite.apache.org
> 
> Hi Romain,
> 
> I'm working on the OSGi compatibility of Ignite. I appreciate your input.
> 
> I'm thinking about the situation you describe and I wonder if you're
> exporting Ignite as an OSGi service which is then consumed from other
> bundles. Under this situation, it would be quite easy to reproduce the
> behaviour you describe if Ignite is not resolving classes via the TCCL.
> Need to dig deeper into that.
> 
> Off the top of my head, there are two alternatives to solve it:
> 
> 1. Use the TCCL for marshalling/unmarshalling (if not already used) – we
> gotta be wary of possible regressions.
> 2. Create a special OSGi header Ignite-Export-Package so that bundles
> containing DTOs can expose packages to Ignite's marshallers.
> 
> 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 Mon, Nov 2, 2015 at 9:56 AM, Gilles, Romain 
> wrote:
> 
> > Hi all,
> >
> > I'm really interested in this issue:
> > https://issues.apache.org/jira/browse/IGNITE-1270 . We some stuff to make
> > it work in our osgi environment. The main issue for us now is the
> > serialization. I think it you will have to rework the OptimizedMarshaller
> > or any other marshaller that works with object that come from outside your
> > class space.
> >
> > We have try kryo that works. Kryo provide an extension point in order to
> > resolve the classes:
> > https://github.com/EsotericSoftware/kryo/blob/master/src/com/esotericsoftware/kryo/ClassResolver.java
> > . With this extension we are able to solve the problem of external classes.
> > The only issue with kryo is that some classes need a certain care in the
> > serialization process and therefore a specialized serializer.
> >
> > So I would like to know from the community what do think of changing the
> > way the optimized marshaller works or introducing the support of yet
> > another marshaller based on a kryo like technology?
> >
> >
> > Thanks in advance,
> >
> >
> > Best regards,
> >
> >
> > Romain.
> >
> >
> > PS: I'm ready to help in the both cases.
> > "Misys" is the trade name of the Misys group of companies. This email and
> > any attachments have been scanned for known viruses using multiple
> > scanners. This email message is intended for the named recipient only. It
> > may be privileged and/or confidential. If you are not the named recipient
> > of this email please notify us immediately and do not copy it or use it for
> > any purpose, nor disclose its contents to any other person. This email does
> > not constitute the commencement of legal relations between you and Misys.
> > Please refer to the executed contract between you and the relevant member
> > of the Misys group for the identity of the contracting party with which you
> > are dealing.
> >
  

[jira] [Created] (IGNITE-1839) [Test failed] GridCacheNearTxExceptionSelfTest.testRemoveBackup failed

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-1839:
---

 Summary: [Test failed] 
GridCacheNearTxExceptionSelfTest.testRemoveBackup failed
 Key: IGNITE-1839
 URL: https://issues.apache.org/jira/browse/IGNITE-1839
 Project: Ignite
  Issue Type: Test
Reporter: Andrey Gura


Test GridCacheNearTxExceptionSelfTest.testRemoveBackup fails periodically with 
different errors.

The first error is assertion failed:

{noformat}
junit.framework.AssertionFailedError: Unexpected entry for grid [i=2, 
entry=GridDhtCacheEntry [rdrs=[ReaderId 
[nodeId=107db664-5be5-4a03-a300-d5324058f001, msgId=6816762, txFut=null]], 
locPart=GridDhtLocalPartition [id=6, mapPubSize=1, rmvQueue=GridCircularBuffer 
[sizeMask=31, idxGen=1], state=OWNING, reservations=0, empty=false, 
createTime=11/02/2015 11:45:37, mapPubSize=1], super=GridDistributedCacheEntry 
[super=GridCacheMapEntry [key=KeyCacheObjectImpl [val=6, hasValBytes=true], 
val=CacheObjectImpl [val=1, hasValBytes=true], startVer=1446453938883, 
ver=GridCacheVersion [topVer=57933940, nodeOrderDrId=3, 
globalTime=1446453942485, order=1446453940025], hash=1558924552, 
extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc 
[locs=[GridCacheMvccCandidate [nodeId=20a19a7c-90ad-4fd9-9c07-5fbbf1236002, 
ver=GridCacheVersion [topVer=57933940, nodeOrderDrId=3, 
globalTime=1446453942486, order=1446453940029], timeout=0, ts=1446453942476, 
threadId=67884, id=8917672, topVer=AffinityTopologyVersion [topVer=3, 
minorTopVer=0], reentry=null, otherNodeId=0025e259-fd0f-43e4-8bf1-c1249eac5000, 
otherVer=GridCacheVersion [topVer=57933940, nodeOrderDrId=1, 
globalTime=1446453942486, order=1446453940028], mappedDhtNodes=null, 
mappedNearNodes=null, ownerVer=null, serOrder=null, key=KeyCacheObjectImpl 
[val=6, hasValBytes=true], 
masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=1|dht_local=1|near_local=0|removed=0,
 prevVer=null, nextVer=null]], rmts=null]], flags=2
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertFalse(Assert.java:39)
at junit.framework.TestCase.assertFalse(TestCase.java:210)
at 
org.apache.ignite.internal.processors.cache.IgniteTxExceptionAbstractSelfTest.checkUnlocked(IgniteTxExceptionAbstractSelfTest.java:404)
at 
org.apache.ignite.internal.processors.cache.IgniteTxExceptionAbstractSelfTest.checkRemove(IgniteTxExceptionAbstractSelfTest.java:561)
at 
org.apache.ignite.internal.processors.cache.IgniteTxExceptionAbstractSelfTest.testRemoveBackup(IgniteTxExceptionAbstractSelfTest.java:207)
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 junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
{noformat}

The second problem is exception:

{noformat}
[19:33:10,099][ERROR][main][root] Test failed.
org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:2847)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.lockedByAny(GridCacheMapEntry.java:3285)
at 
org.apache.ignite.internal.processors.cache.IgniteTxExceptionAbstractSelfTest.checkUnlocked(IgniteTxExceptionAbstractSelfTest.java:404)
at 
org.apache.ignite.internal.processors.cache.IgniteTxExceptionAbstractSelfTest.checkRemove(IgniteTxExceptionAbstractSelfTest.java:561)
at 
org.apache.ignite.internal.processors.cache.IgniteTxExceptionAbstractSelfTest.testRemoveBackup(IgniteTxExceptionAbstractSelfTest.java:205)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridCacheNearTxExceptionSelfTest.testRemoveBackup(GridCacheNearTxExceptionSelfTest.java:41)
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 junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
at 

Re: Questions about TeamCity CI organization

[Dmitriy Setrakyan]

I am also curious to get answers to the questions posted by Raul. Can
someone knowledgeable in TC configuration respond?

D.

On Mon, Oct 26, 2015 at 6:14 AM, Raul Kripalani  wrote:

> Hey guys,
>
> I have a few questions about the way our builds are organised in TeamCity.
>
> 1. All build configurations seem to be building the entire project tree. Is
> this correct?
>
> 2. The goal of the build configurations here is to partition the tests so
> that the test execution can be distributed across all 15 worker nodes,
> right?
>
> 3. Would it make sense to have a single top-level build for the project
> tree that actually builds the code? This one would in turn trigger the
> individual test suites – each in a build configuration such that then can
> continue to be distributed across the worker cloud? Or do we face a problem
> with Maven SNAPSHOTs potentially overwriting each other if multiple builds
> are running concurrently? To me, it seems overkill to build the entire
> project tree over and over again only to execute a given test suite (if I
> understood correctly).
>
> 4. Are tests for ignite-spark, ignite-kafka, ignite-mesos,
> ignite-rest-http, etc. ever run? I don't find specific build configurations
> for them... Are they included in other configs?
>
> Thanks,
>
> *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
>

Re: Regrouping of streamers under TeamCity

[Dmitriy Setrakyan]

Thanks Raul! What is the name of the new module? Should the documentation
be updated (or created?)

On Wed, Oct 28, 2015 at 5:53 AM, Raul Kripalani  wrote:

> Hello all,
>
> I've regrouped Ignite streamer modules in TeamCity into the existing Ignite
> Streamers build configuration. Thus, the separate Ignite JMS and Ignite
> MQTT have disappeared.
>
> I faced some troubles with the ActiveMQ KahaDB file locks in TeamCity,
> hence my commits today in that module, as I could not reproduce the error
> locally. It's now fixed.
>
> 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
>

[jira] [Created] (IGNITE-1836) Automatically select the first item if current is not in filtered list

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1836:
--

 Summary: Automatically select the first item if current is not in 
filtered list
 Key: IGNITE-1836
 URL: https://issues.apache.org/jira/browse/IGNITE-1836
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov


1) select valid metadata item
2) switch to invalid or set filter - current active item is not in the new list
3) try to remove item - you will be remove item which was be active before 
filtration




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

[GitHub] ignite pull request: IGNITE-1818 .Net: compact footer offsets

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1818 .Net: compact footer offsets



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

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

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

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


commit 2067d28c42239b0832a466920e913e9d2ab68385
Author: Pavel Tupitsyn 
Date:   2015-10-30T12:48:08Z

IGNITE-1818 .Net: compact footer offsets

commit efb4c195e582161a170dc6d8612b215060c626c0
Author: Pavel Tupitsyn 
Date:   2015-10-30T12:55:19Z

wip

commit f429254ce9c1698e8ab5bbd6cfdbfb80bd9a7a76
Author: Pavel Tupitsyn 
Date:   2015-10-30T13:01:00Z

wip

commit 4bdbeaf0a9e6142c6a99351654503fd265b43bf7
Author: Pavel Tupitsyn 
Date:   2015-10-30T13:14:00Z

wip naming

commit e76faef580dc9b339a5177d7714846766804402e
Author: Pavel Tupitsyn 
Date:   2015-10-30T13:14:06Z

wip

commit f1c0adb0c467fa949363e141569875cf608d9352
Author: Pavel Tupitsyn 
Date:   2015-10-30T13:37:21Z

wip

commit b528195005c61164620ae051ca3c1e0b6da7296f
Author: Pavel Tupitsyn 
Date:   2015-10-30T13:44:31Z

wip fixing

commit 147315d9a1cd3d09d776a13d1a19fe72576d2173
Author: Pavel Tupitsyn 
Date:   2015-10-30T13:47:05Z

wip

commit dda2c046bc018304c89d9e36e4a34c062b254118
Author: Pavel Tupitsyn 
Date:   2015-10-30T13:52:30Z

wip

commit 1b12792a7a032262cd44d89c0d4051d10e590986
Author: Pavel Tupitsyn 
Date:   2015-10-30T13:58:07Z

wip

commit b86723ba2de978f68b1cb0e04090a99bb9173db3
Author: Pavel Tupitsyn 
Date:   2015-10-30T13:59:00Z

wip

commit 4f0acc8679f5061cce86e0ba5950771a748fc386
Author: Pavel Tupitsyn 
Date:   2015-10-30T13:59:06Z

wip

commit 29a47f0f712c3860bbb2715afff380b514759198
Author: Pavel Tupitsyn 
Date:   2015-10-30T14:00:33Z

wip

commit 13752abc40b7f2d1511e52560ce019c2a68bb3ab
Author: Pavel Tupitsyn 
Date:   2015-10-30T14:01:28Z

wip

commit e552d780f514485a31bb2f27446be9806ff41cc0
Author: Pavel Tupitsyn 
Date:   2015-10-30T14:06:35Z

wip

commit 8acb8446530e74a1eef793cf803ea929224cd297
Author: Pavel Tupitsyn 
Date:   2015-10-30T14:09:23Z

wip

commit 5d278bc87b03f78316edb0dc500faae05ab9b2b2
Author: Pavel Tupitsyn 
Date:   2015-10-30T14:11:18Z

wip

commit fd7cc26f1ae8c49c0e8e192bba828b46b8ac1851
Author: Pavel Tupitsyn 
Date:   2015-10-30T14:11:37Z

wip

commit e4b9af09697e6361eba0b11f1cc35fe08d7316b3
Author: Pavel Tupitsyn 
Date:   2015-10-30T14:20:50Z

wip write in compact form

commit cee844b0cc34b2bb2ef09fcead9b23f04a56dc23
Author: Pavel Tupitsyn 
Date:   2015-10-30T14:57:19Z

It works!

commit 6ceec50b6ae65c6bfc85bbb9d2806c1084c9b081
Author: Pavel Tupitsyn 
Date:   2015-10-30T15:03:21Z

wip

commit 4bb6228a6e0eadbe00c0910d69188bbb8cdb1494
Author: Pavel Tupitsyn 
Date:   2015-10-30T15:13:49Z

wip

commit 33dc78a1d4105eccb0fc96e962f6d0ee5f18cd46
Author: Pavel Tupitsyn 
Date:   2015-11-02T08:31:24Z

wip cleanup

commit 5d7ce5fa1a8a553bab3696df9a0d2ad9df19ecb4
Author: Pavel Tupitsyn 
Date:   2015-11-02T08:33:24Z

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

commit 19aa19bde4e4b4735eb8a61a09fb4c8c411d3ffe
Author: Pavel Tupitsyn 
Date:   2015-11-02T08:35:32Z

revert renaming

commit 3f92bc5dc4d66c6098d18f0846c3daf7b6701842
Author: Pavel Tupitsyn 
Date:   2015-11-02T08:36:53Z

revert renaming

commit a972ff4f1636b2174a99272cd115f92db0babf93
Author: Pavel Tupitsyn 
Date:   2015-11-02T08:37:06Z

revert renaming

commit bc66978487c8574bb586ac372bec44cfc351178a
Author: Pavel Tupitsyn 
Date:   2015-11-02T08:38:47Z

revert renaming

commit 890a5608ab97783a34fe84a51e2a33fe4b30b619
Author: Pavel Tupitsyn 
Date:   2015-11-02T08:38:54Z

revert renaming

commit 31a7a3a03c968db057a58285cd513a9b2fa2bb05
Author: Pavel Tupitsyn 
Date:   2015-11-02T08:41:55Z

cleanup




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

[jira] [Created] (IGNITE-1833) VisorCache task collects wrong backup partitions information

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-1833:


 Summary: VisorCache task collects wrong backup partitions 
information
 Key: IGNITE-1833
 URL: https://issues.apache.org/jira/browse/IGNITE-1833
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: ignite-1.4
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 1.5


Current logic of VisorCache task is like this (pseudo code):

{code}
parts = cache.getPartitions();

for (part in parts) {
 if (part.isPrimary)
   prtimCnt++;
 else
  backupCnt++;
}
{code}

but we should add more checks to detect if  partition is really backup.
{code}
for (part in parts) {
 if (part.isPrimary)
   prtimCnt++;
 else if (part.state == OWNING && part.isBackup)
  backupCnt++;
}
{code}



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

[jira] [Created] (IGNITE-1834) .Net: Remove MetadataEnabled property

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1834:
---

 Summary: .Net: Remove MetadataEnabled property
 Key: IGNITE-1834
 URL: https://issues.apache.org/jira/browse/IGNITE-1834
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: 1.5
Reporter: Pavel  Tupitsyn
Assignee: Pavel  Tupitsyn
 Fix For: 1.5


MetadataEnabled is going to be removed from Ignite, need to reflect this in 
.Net.



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

[GitHub] ignite pull request: ignite-1698 SqlFieldsQuery works incorrectly ...

[asfgit]

Github user asfgit closed the pull request at:

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


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

[Raul Kripalani]

Hi Andrey,

Thanks for the participation in this topic.

I don't like the solution to incorporate the bundle symbolic name in the
serialised form. Nothing guarantees that the classdef will be located under
the same bundle in both source and target machines. We also have to take
into account that OSGi allows for multiple versions of the same
bundle/packages to co-exist in the same  container. So it becomes more
complex.

Using the TCCL should work when serialising, but it'll probably be of no
use when deserialising on the other end.

I need to enhance Ignite to:

1. Use the TCCL when marshalling on one end.
2. Incorporate the package version of the class in the serialised form if
Ignite is running in an OSGi environment.
3. On the receiver end, discover cache entities / DTOs in all bundles
through a custom OSGi manifest header or the like, as I explained before.
Package version must be taken into account.

What do you think?

Raúl.
On 2 Nov 2015 17:25, "Andrey Kornev"  wrote:

> Raul,
>
> The fundamental hurdle we need to jump over to make Ignite OSGi-enabled is
> the marshalling. More specifically the issue is with deserialization of the
> classes that are provided by the bundles other than the Ignite bundle
> itself.
>
> When the Ignite transport layer receives a message it needs to figure out
> how to deserialize the bytes and for that it needs to know the bundle that
> provides the class to be deserailized. At this point TCCL is of no use. To
> make things more complex, the class may contain other classes that come
> from other bundles, and so on recursively. This means that each object in
> the hierarchy must be serialized with its bundle name (or bundle id), so
> that the deserializer will then be able to correctly resolve the class
> while traversing the object hierarchy during deserialization.
>
> Unfortunately, Ignite's OptimizedMarshaller is lacking the ability to plug
> in a custom class resolver. Romain's solution was to use Kryo that does
> provide a way to customize class resolution. It has solved the problem of
> capturing the bundle info and he was able to successfully run Ignite as a
> bundle in an OSGi container (after some repackaging and inclusion of the
> manifest). But Kryo-based marshalling introduced a lot of complexity to the
> code and incorrect use of Kryo's numerous serializers caused some weird
> hard-to-debug issues in the Ignite core (like duplicate cache entries due
> to incorrect marshalling of the GridDhtPArtitonFullMap class -- go
> figure!). Overall the Kryo-based solution is brittle and hard to maintain.
>
> I feel the correct solution to OSGi problem would be to
> 1) enhance the OptimizedMarshaller to allow custom class resolution.
> 2) provide an OSGi-enabled OptimizedMarshaller (in addition to the
> original one) to be used in OSGi environment.
>
> Regards
> Andrey
>
> > From: ra...@apache.org
> > Date: Mon, 2 Nov 2015 12:41:47 +
> > Subject: Re: OSGi migration may require a special marshaller
> > To: dev@ignite.apache.org
> >
> > Hi Romain,
> >
> > I'm working on the OSGi compatibility of Ignite. I appreciate your input.
> >
> > I'm thinking about the situation you describe and I wonder if you're
> > exporting Ignite as an OSGi service which is then consumed from other
> > bundles. Under this situation, it would be quite easy to reproduce the
> > behaviour you describe if Ignite is not resolving classes via the TCCL.
> > Need to dig deeper into that.
> >
> > Off the top of my head, there are two alternatives to solve it:
> >
> > 1. Use the TCCL for marshalling/unmarshalling (if not already used) – we
> > gotta be wary of possible regressions.
> > 2. Create a special OSGi header Ignite-Export-Package so that bundles
> > containing DTOs can expose packages to Ignite's marshallers.
> >
> > 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 Mon, Nov 2, 2015 at 9:56 AM, Gilles, Romain 
> > wrote:
> >
> > > Hi all,
> > >
> > > I'm really interested in this issue:
> > > https://issues.apache.org/jira/browse/IGNITE-1270 . We some stuff to
> make
> > > it work in our osgi environment. The main issue for us now is the
> > > serialization. I think it you will have to rework the
> OptimizedMarshaller
> > > or any other marshaller that works with object that come from outside
> your
> > > class space.
> > >
> > > We have try kryo that works. Kryo provide an extension point in order
> to
> > > resolve the classes:
> > >
> https://github.com/EsotericSoftware/kryo/blob/master/src/com/esotericsoftware/kryo/ClassResolver.java
> > > . With this extension we are able to solve the problem of external
> classes.
> > > The only issue with kryo is that some classes need a certain care in
> the
> > > serialization process 

Re: Ignite-1.5 Release

[Alexey Goncharuk]

I am finalizing changes related to IGNITE-1486 branch. Currently the API
changes are finished and now I am mostly fixing the CI tests. In fact, I
just submitted the latest fix related to the new .NET platform
functionality and hope CI tests will pass, in this case it will be ready to
be merged tomorrow morning.
It would be nice if other community members reviewed my changes in
ignite-950-new branch before it gets to master.

2015-11-02 22:27 GMT+03:00 Dmitriy Setrakyan :

> Thanks Vladislav!
>
> Would also be nice to get an update from other committers involved in the
> outlined tickets. Specifically whether the ticket has been merged to master
> or not, and if not, what should be the expectation.
>
> Thanks,
> D.
>
> On Mon, Nov 2, 2015 at 11:23 AM, Vladisav Jelisavcic 
> wrote:
>
> > >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
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Hello

[Michael Grabenstein]

Subscribe me.
Is this automated only?

Re: Ignite-1.5 Release

[Dmitriy Setrakyan]

Alexey,

I am confused. Why do you have 2 branches?

D.

On Mon, Nov 2, 2015 at 2:32 PM, Alexey Goncharuk  wrote:

> I am finalizing changes related to IGNITE-1486 branch. Currently the API
> changes are finished and now I am mostly fixing the CI tests. In fact, I
> just submitted the latest fix related to the new .NET platform
> functionality and hope CI tests will pass, in this case it will be ready to
> be merged tomorrow morning.
> It would be nice if other community members reviewed my changes in
> ignite-950-new branch before it gets to master.
>
> 2015-11-02 22:27 GMT+03:00 Dmitriy Setrakyan :
>
> > Thanks Vladislav!
> >
> > Would also be nice to get an update from other committers involved in the
> > outlined tickets. Specifically whether the ticket has been merged to
> master
> > or not, and if not, what should be the expectation.
> >
> > Thanks,
> > D.
> >
> > On Mon, Nov 2, 2015 at 11:23 AM, Vladisav Jelisavcic <
> vladis...@gmail.com>
> > wrote:
> >
> > > >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 <
> dsetrak...@apache.org
> > >
> > > 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
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Ignite-1.5 Release

[Alexey Goncharuk]

I'm sorry, I meant to write "changes related to IGNITE-1486 *ticket*". The
changes are in ignite-950-new branch because it is a result of work on
multiple sub-tickets and it is currently used as an integration branch.

2015-11-03 1:39 GMT+03:00 Dmitriy Setrakyan :

> Alexey,
>
> I am confused. Why do you have 2 branches?
>
> D.
>
> On Mon, Nov 2, 2015 at 2:32 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > wrote:
>
> > I am finalizing changes related to IGNITE-1486 branch. Currently the API
> > changes are finished and now I am mostly fixing the CI tests. In fact, I
> > just submitted the latest fix related to the new .NET platform
> > functionality and hope CI tests will pass, in this case it will be ready
> to
> > be merged tomorrow morning.
> > It would be nice if other community members reviewed my changes in
> > ignite-950-new branch before it gets to master.
> >
> > 2015-11-02 22:27 GMT+03:00 Dmitriy Setrakyan :
> >
> > > Thanks Vladislav!
> > >
> > > Would also be nice to get an update from other committers involved in
> the
> > > outlined tickets. Specifically whether the ticket has been merged to
> > master
> > > or not, and if not, what should be the expectation.
> > >
> > > Thanks,
> > > D.
> > >
> > > On Mon, Nov 2, 2015 at 11:23 AM, Vladisav Jelisavcic <
> > vladis...@gmail.com>
> > > wrote:
> > >
> > > > >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 <
> > dsetrak...@apache.org
> > > >
> > > > 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?
> > > > > > 

Re: Hello

[Dmitriy Setrakyan]

Hi Michael,

Please subscribe to this list by sending an email to
dev-subscr...@ignite.apache.org and following the simple instructions in
the reply.

D.

On Mon, Nov 2, 2015 at 2:31 PM, Michael Grabenstein  wrote:

> Subscribe me.
> Is this automated only?
>
>

[GitHub] ignite pull request: IGNITE-1834 .Net: Remove MetadataEnabled prop...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1834 .Net: Remove MetadataEnabled property



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

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

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

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


commit a380a94d9b6352cc766f63b6bc8fe1f03fcbef9d
Author: Pavel Tupitsyn 
Date:   2015-11-02T10:37:34Z

IGNITE-1834 .Net: Remove MetadataEnabled property

commit 1b197aa8d907e82e6990a1219315fc9cda5ad289
Author: Pavel Tupitsyn 
Date:   2015-11-02T10:44:26Z

Fix tests




---
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-1380 Random eviction policy for near c...

[agura]

Github user agura closed the pull request at:

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


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

[Yakov Zhdanov]

Romain,

Is that correct that you obtain instance of Ignite through cache manager
and pass your classloader to which gets ignored at some point? Or you
use IgniteConfiguration#setClassLoader?

Can you or anyone in community please provide a short example or junit so I
can reproduce this?

Thanks!

Thanks!
--
Yakov Zhdanov, Director R
*GridGain Systems*
www.gridgain.com

2015-11-02 12:56 GMT+03:00 Gilles, Romain :

> Hi all,
>
> I'm really interested in this issue:
> https://issues.apache.org/jira/browse/IGNITE-1270 . We some stuff to make
> it work in our osgi environment. The main issue for us now is the
> serialization. I think it you will have to rework the OptimizedMarshaller
> or any other marshaller that works with object that come from outside your
> class space.
>
> We have try kryo that works. Kryo provide an extension point in order to
> resolve the classes:
> https://github.com/EsotericSoftware/kryo/blob/master/src/com/esotericsoftware/kryo/ClassResolver.java
> . With this extension we are able to solve the problem of external classes.
> The only issue with kryo is that some classes need a certain care in the
> serialization process and therefore a specialized serializer.
>
> So I would like to know from the community what do think of changing the
> way the optimized marshaller works or introducing the support of yet
> another marshaller based on a kryo like technology?
>
>
> Thanks in advance,
>
>
> Best regards,
>
>
> Romain.
>
>
> PS: I'm ready to help in the both cases.
> "Misys" is the trade name of the Misys group of companies. This email and
> any attachments have been scanned for known viruses using multiple
> scanners. This email message is intended for the named recipient only. It
> may be privileged and/or confidential. If you are not the named recipient
> of this email please notify us immediately and do not copy it or use it for
> any purpose, nor disclose its contents to any other person. This email does
> not constitute the commencement of legal relations between you and Misys.
> Please refer to the executed contract between you and the relevant member
> of the Misys group for the identity of the contracting party with which you
> are dealing.
>

Re: Request add me to development list

[Denis Magda]

Yakov, Dmitriy or anyone else from the community with administrative 
rights please provide Prabhat's JIRA account with all required permissions.


--
Denis

On 11/2/2015 1:49 PM, Prabhat Ranjan wrote:

Thanks Denis.

Please set required permission to my  JIRA account 'prabhat'.

Regards,
Prabhat


On 2 November 2015 at 19:26, Denis Magda > wrote:


Hi Prabhat,

Welcome on board!

Please share your JIRA account with us and we will set all
required permissions for it. Once it has been done you will be
able to assign that ticket to you by yourself.

Regards,
Denis


On 10/31/2015 3:42 PM, Prabhat Ranjan wrote:

Hi,

I  work in financial domain and have 10 years java experience.
I  used Grid gain in-memory data grid  for  a POC (proof of
concept )
project at my company last year.

I would like to contribute to ignite project.

Also, could you please assign following issue to me.

https://issues.apache.org/jira/browse/IGNITE-1783

Regards,
Prabhat
+61 410 603 242 

RE: OSGi migration may require a special marshaller

[Andrey Kornev]

Hey Raul,

What kind of use case do you have in mind when you suggest that a classdef may 
be located in different bundles on different machines? What would one have to 
do to end up in such a predicament? It feels more like a 
configuration/deployment issue rather than a desirable feature.

A more realistic assumption I believe is that the nodes will have (mostly) the 
same set of bundles deployed. (We even enforce it at runtime  by leveraging 
Ignite's PluginProvider.validateNewNode() method: we do not allow new nodes 
join the cluster if their OSGi environment is inconsistent.)

The "bundle name" in my original email really meant "bundle symbolic name + 
bundle version". Sorry for not being clear.

I'm not sure I understand why TCCL is even required for serialization?

Finally, I didn't quite grok your thinking about the custom manifest header. 
Could you please elaborate? What type of information do you propose to store in 
the header? How will the serializer be able to provide that info, and how will 
the deserializer use the info to load the classes? Also, who is responsible for 
making sure that the custom header includes all classes to be serialized? And 
how/when/by whom would such a header be generated?

Regards
Andrey

> Date: Mon, 2 Nov 2015 23:20:41 +
> Subject: RE: OSGi migration may require a special marshaller
> From: r...@evosent.com
> To: dev@ignite.apache.org
> 
> Hi Andrey,
> 
> Thanks for the participation in this topic.
> 
> I don't like the solution to incorporate the bundle symbolic name in the
> serialised form. Nothing guarantees that the classdef will be located under
> the same bundle in both source and target machines. We also have to take
> into account that OSGi allows for multiple versions of the same
> bundle/packages to co-exist in the same  container. So it becomes more
> complex.
> 
> Using the TCCL should work when serialising, but it'll probably be of no
> use when deserialising on the other end.
> 
> I need to enhance Ignite to:
> 
> 1. Use the TCCL when marshalling on one end.
> 2. Incorporate the package version of the class in the serialised form if
> Ignite is running in an OSGi environment.
> 3. On the receiver end, discover cache entities / DTOs in all bundles
> through a custom OSGi manifest header or the like, as I explained before.
> Package version must be taken into account.
> 
> What do you think?
> 
> Raúl.
> On 2 Nov 2015 17:25, "Andrey Kornev"  wrote:
> 
> > Raul,
> >
> > The fundamental hurdle we need to jump over to make Ignite OSGi-enabled is
> > the marshalling. More specifically the issue is with deserialization of the
> > classes that are provided by the bundles other than the Ignite bundle
> > itself.
> >
> > When the Ignite transport layer receives a message it needs to figure out
> > how to deserialize the bytes and for that it needs to know the bundle that
> > provides the class to be deserailized. At this point TCCL is of no use. To
> > make things more complex, the class may contain other classes that come
> > from other bundles, and so on recursively. This means that each object in
> > the hierarchy must be serialized with its bundle name (or bundle id), so
> > that the deserializer will then be able to correctly resolve the class
> > while traversing the object hierarchy during deserialization.
> >
> > Unfortunately, Ignite's OptimizedMarshaller is lacking the ability to plug
> > in a custom class resolver. Romain's solution was to use Kryo that does
> > provide a way to customize class resolution. It has solved the problem of
> > capturing the bundle info and he was able to successfully run Ignite as a
> > bundle in an OSGi container (after some repackaging and inclusion of the
> > manifest). But Kryo-based marshalling introduced a lot of complexity to the
> > code and incorrect use of Kryo's numerous serializers caused some weird
> > hard-to-debug issues in the Ignite core (like duplicate cache entries due
> > to incorrect marshalling of the GridDhtPArtitonFullMap class -- go
> > figure!). Overall the Kryo-based solution is brittle and hard to maintain.
> >
> > I feel the correct solution to OSGi problem would be to
> > 1) enhance the OptimizedMarshaller to allow custom class resolution.
> > 2) provide an OSGi-enabled OptimizedMarshaller (in addition to the
> > original one) to be used in OSGi environment.
> >
> > Regards
> > Andrey
> >
> > > From: ra...@apache.org
> > > Date: Mon, 2 Nov 2015 12:41:47 +
> > > Subject: Re: OSGi migration may require a special marshaller
> > > To: dev@ignite.apache.org
> > >
> > > Hi Romain,
> > >
> > > I'm working on the OSGi compatibility of Ignite. I appreciate your input.
> > >
> > > I'm thinking about the situation you describe and I wonder if you're
> > > exporting Ignite as an OSGi service which is then consumed from other
> > > bundles. Under this situation, it would be quite easy to reproduce the
> > > behaviour you describe if Ignite is not resolving classes via 

Re: OSGi migration may require a special marshaller

[Dmitriy Setrakyan]

I think I can see Andrey’s point about the bundles. Having same classdef in
different bundles on sender and receiver sides sounds rather like a bug,
not a feature we should support.

Having read this thread, I think we need to have ClassLoaderResolver on the
sending and receiving sides. Something like this:

*public interface ClassLoaderResolver {*
*// This method is invoked on the sender side to *
*// marshal the information about the class loader.*
*public byte[] writeClassLoader(Object o) throws IgniteException;*

*// This method is invoked on the receiving side to*
*// retrieve the class loader based on provided information.*
*public ClassLoader readClassLoader(byte[]) throws IgniteException;*
*}*

This resolver should be a pluggable configuration for marshallers or
provided in IgniteConfiguration directly. Once we have such resolver, then
we can have a special OSGI implementation for it (perhaps a different one
for different OSGI containers).

Thoughts?

D.

On Mon, Nov 2, 2015 at 4:23 PM, Andrey Kornev 
wrote:

> Hey Raul,
>
> What kind of use case do you have in mind when you suggest that a classdef
> may be located in different bundles on different machines? What would one
> have to do to end up in such a predicament? It feels more like a
> configuration/deployment issue rather than a desirable feature.
>
> A more realistic assumption I believe is that the nodes will have (mostly)
> the same set of bundles deployed. (We even enforce it at runtime  by
> leveraging Ignite's PluginProvider.validateNewNode() method: we do not
> allow new nodes join the cluster if their OSGi environment is inconsistent.)
>
> The "bundle name" in my original email really meant "bundle symbolic name
> + bundle version". Sorry for not being clear.
>
> I'm not sure I understand why TCCL is even required for serialization?
>
> Finally, I didn't quite grok your thinking about the custom manifest
> header. Could you please elaborate? What type of information do you propose
> to store in the header? How will the serializer be able to provide that
> info, and how will the deserializer use the info to load the classes? Also,
> who is responsible for making sure that the custom header includes all
> classes to be serialized? And how/when/by whom would such a header be
> generated?
>
> Regards
> Andrey
>
> > Date: Mon, 2 Nov 2015 23:20:41 +
> > Subject: RE: OSGi migration may require a special marshaller
> > From: r...@evosent.com
> > To: dev@ignite.apache.org
> >
> > Hi Andrey,
> >
> > Thanks for the participation in this topic.
> >
> > I don't like the solution to incorporate the bundle symbolic name in the
> > serialised form. Nothing guarantees that the classdef will be located
> under
> > the same bundle in both source and target machines. We also have to take
> > into account that OSGi allows for multiple versions of the same
> > bundle/packages to co-exist in the same  container. So it becomes more
> > complex.
> >
> > Using the TCCL should work when serialising, but it'll probably be of no
> > use when deserialising on the other end.
> >
> > I need to enhance Ignite to:
> >
> > 1. Use the TCCL when marshalling on one end.
> > 2. Incorporate the package version of the class in the serialised form if
> > Ignite is running in an OSGi environment.
> > 3. On the receiver end, discover cache entities / DTOs in all bundles
> > through a custom OSGi manifest header or the like, as I explained before.
> > Package version must be taken into account.
> >
> > What do you think?
> >
> > Raúl.
> > On 2 Nov 2015 17:25, "Andrey Kornev"  wrote:
> >
> > > Raul,
> > >
> > > The fundamental hurdle we need to jump over to make Ignite
> OSGi-enabled is
> > > the marshalling. More specifically the issue is with deserialization
> of the
> > > classes that are provided by the bundles other than the Ignite bundle
> > > itself.
> > >
> > > When the Ignite transport layer receives a message it needs to figure
> out
> > > how to deserialize the bytes and for that it needs to know the bundle
> that
> > > provides the class to be deserailized. At this point TCCL is of no
> use. To
> > > make things more complex, the class may contain other classes that come
> > > from other bundles, and so on recursively. This means that each object
> in
> > > the hierarchy must be serialized with its bundle name (or bundle id),
> so
> > > that the deserializer will then be able to correctly resolve the class
> > > while traversing the object hierarchy during deserialization.
> > >
> > > Unfortunately, Ignite's OptimizedMarshaller is lacking the ability to
> plug
> > > in a custom class resolver. Romain's solution was to use Kryo that does
> > > provide a way to customize class resolution. It has solved the problem
> of
> > > capturing the bundle info and he was able to successfully run Ignite
> as a
> > > bundle in an OSGi container (after some repackaging and inclusion of
> the
> > > 

[GitHub] ignite pull request: IGNITE-1397 Load/consistency test framework

[ashutakGG]

GitHub user ashutakGG opened a pull request:

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

IGNITE-1397 Load/consistency test framework

IGNITE-1397 Load/consistency test framework

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

$ git pull https://github.com/ashutakGG/incubator-ignite ignite-1397-yard-2

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

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


commit 1fe969d3727c5cf0843a759934893acc5b2ee324
Author: ashutak 
Date:   2015-10-08T17:50:26Z

ignite-1397

commit 0454468b0c441d49c0df4b08af7275d150c881da
Author: ashutak 
Date:   2015-10-08T18:27:16Z

review

commit 33cbdfeeb4144fc20cc591fe32163389f3e37a18
Author: ashutak 
Date:   2015-10-08T18:28:01Z

typo

commit df70ac6922acc6d6a1dc616f3286bf407347a5a1
Author: ashutak 
Date:   2015-10-12T13:38:20Z

self-review

commit 9844e2b95391205b349511b1d0e5690160094ba3
Author: ashutak 
Date:   2015-10-12T15:17:57Z

Alex review

commit b9aa7b8e752a49f10a919e9b697c25c617a563d2
Author: ashutak 
Date:   2015-10-12T16:40:29Z

typo

commit 374a66350633a13f0298e4aeb900d9854e90649a
Author: ashutak 
Date:   2015-10-13T12:55:33Z

improve properties files

commit b0ba2dc30b3b3668c3dff909ea04225d11c760f3
Author: ashutak 
Date:   2015-10-14T10:27:18Z

ignite-1397

commit a4d4d8534ef8269bba611eb5d6eec57b14b7b5f2
Author: ashutak 
Date:   2015-10-15T14:53:19Z

0.8.0-SNAPSHOT -> 0.8.0

commit 814c7d1aa3984cd0a7916a76f15f7fde90a38e75
Author: ashutak 
Date:   2015-10-15T15:33:14Z

offheap tests

commit faf18509167b4fbc18e4b26ab13f67c1f3152a30
Author: ashutak 
Date:   2015-10-15T15:34:54Z

awaitPartitionedMapExchange

commit 9b496bb64b410c29a76e4548ef2d65cdf10d32f8
Author: ashutak 
Date:   2015-10-15T15:35:00Z

Merge branch 'tmp-ignite-1397' into ignite-1397-yard-2

commit 56a02fcba9a4824443ebdfe76f7f90abdc13e1e4
Author: ashutak 
Date:   2015-10-15T16:24:34Z

10 caches

commit 746175cc2dafb433e9c04a17d26a7aa255832947
Author: ashutak 
Date:   2015-10-15T16:43:07Z

fix benchmark-failover.properties and IgniteAtomicInvokeRetryBenchmark.java

commit 529a24533aa5cc7f92f632b26dcf75ea546a8f42
Author: ashutak 
Date:   2015-10-15T16:43:14Z

Merge branch 'master' into ignite-1397-yard-2

commit 44aef24cb2a17cdadaf12b3ee53e58d6d84f6e23
Author: ashutak 
Date:   2015-10-15T17:07:25Z

rewrite IgniteAtomicInvokeRetryBenchmark

commit ddb7636e9dc96dcbcf698ae20e06982e9643de8b
Author: ashutak 
Date:   2015-10-15T17:23:18Z

add atomic invoke to benchmark-failover.properties

commit 764aaa3f95ddbf4af28e0a03555c454362868fd0
Author: ashutak 
Date:   2015-10-20T18:06:32Z

-ea

commit 84099ba8c36b4b821f1e03bf5168e685c876331b
Author: ashutak 
Date:   2015-10-20T18:25:07Z

onException

commit 9af0c0297793749f03a94c52c2d1d53dbb6a35ef
Author: ashutak 
Date:   2015-10-21T16:27:54Z

Merge branch 'master' into ignite-1397-yard-2

commit b404dbffd0e648be6977b5d96b48feea8aec16d2
Author: ashutak 
Date:   2015-10-21T16:32:02Z



commit 366e31ad65933efbcf33a189094e7a4e66c93b8d
Author: ashutak 
Date:   2015-10-21T16:34:40Z

benchmark-failover.properties review

commit f1f9396367addc42562dec687d329ae4cbb6093d
Author: ashutak 
Date:   2015-11-02T12:20:11Z

Merge branch 'master' into ignite-1397-yard-2

Conflicts:
modules/yardstick/config/benchmark-multicast.properties

modules/yardstick/src/main/java/org/apache/ignite/yardstick/IgniteBenchmarkArguments.java

modules/yardstick/src/main/java/org/apache/ignite/yardstick/cache/IgniteCacheAbstractBenchmark.java




---
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: Request add me to development list

[Yakov Zhdanov]

Done!

--Yakov

2015-11-02 14:53 GMT+03:00 Denis Magda :

> Yakov, Dmitriy or anyone else from the community with administrative
> rights please provide Prabhat's JIRA account with all required permissions.
>
> --
> Denis
>
> On 11/2/2015 1:49 PM, Prabhat Ranjan wrote:
>
>> Thanks Denis.
>>
>> Please set required permission to my  JIRA account 'prabhat'.
>>
>> Regards,
>> Prabhat
>>
>>
>>
>> On 2 November 2015 at 19:26, Denis Magda  dma...@gridgain.com>> wrote:
>>
>> Hi Prabhat,
>>
>> Welcome on board!
>>
>> Please share your JIRA account with us and we will set all
>> required permissions for it. Once it has been done you will be
>> able to assign that ticket to you by yourself.
>>
>> Regards,
>> Denis
>>
>>
>> On 10/31/2015 3:42 PM, Prabhat Ranjan wrote:
>>
>> Hi,
>>
>> I  work in financial domain and have 10 years java experience.
>> I  used Grid gain in-memory data grid  for  a POC (proof of
>> concept )
>> project at my company last year.
>>
>> I would like to contribute to ignite project.
>>
>> Also, could you please assign following issue to me.
>>
>> https://issues.apache.org/jira/browse/IGNITE-1783
>>
>> Regards,
>> Prabhat
>> +61 410 603 242 
>>
>>
>>
>>
>

[jira] [Created] (IGNITE-1837) Slow rebalancing on a big cluster (64 nodes and more)

[Denis Magda (JIRA)]

Denis Magda created IGNITE-1837:
---

 Summary: Slow rebalancing on a big cluster (64 nodes and more)
 Key: IGNITE-1837
 URL: https://issues.apache.org/jira/browse/IGNITE-1837
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: ignite-1.4
Reporter: Denis Magda
Assignee: Alexey Goncharuk
 Fix For: 1.5


It seems that Ignite has different rebalancing related issues that appear when 
a big cluster is started.

Under the big cluster I mean:
- cluster of 64 server nodes;
- cluster of 64 server and 64 client nodes.

The issues can be divided on three main use cases.

1) Slow rebalancing on start.

If to set partitions number for some cache to value bigger than default one (to 
3200 or to 6400, etc.) then rebalancing of such caches may take several 
minutes. The caches are empty at that time.

2) Slow rebalancing on client nodes shutdown.

If to stop a significant number of client nodes at the same time then again by 
some reason the rebalancing will take serveral minutes.

3) Periodic rebalancing timeouts during the time a cluster is idle.

Discussed there: 
http://apache-ignite-users.70518.x6.nabble.com/Help-with-tuning-for-larger-clusters-td1692.html#a1813

Probably the code is not optimal and sends rebalancing related messages too 
frequently.



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

Re: OSGi migration may require a special marshaller

[Raul Kripalani]

Hi Romain,

I'm working on the OSGi compatibility of Ignite. I appreciate your input.

I'm thinking about the situation you describe and I wonder if you're
exporting Ignite as an OSGi service which is then consumed from other
bundles. Under this situation, it would be quite easy to reproduce the
behaviour you describe if Ignite is not resolving classes via the TCCL.
Need to dig deeper into that.

Off the top of my head, there are two alternatives to solve it:

1. Use the TCCL for marshalling/unmarshalling (if not already used) – we
gotta be wary of possible regressions.
2. Create a special OSGi header Ignite-Export-Package so that bundles
containing DTOs can expose packages to Ignite's marshallers.

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 Mon, Nov 2, 2015 at 9:56 AM, Gilles, Romain 
wrote:

> Hi all,
>
> I'm really interested in this issue:
> https://issues.apache.org/jira/browse/IGNITE-1270 . We some stuff to make
> it work in our osgi environment. The main issue for us now is the
> serialization. I think it you will have to rework the OptimizedMarshaller
> or any other marshaller that works with object that come from outside your
> class space.
>
> We have try kryo that works. Kryo provide an extension point in order to
> resolve the classes:
> https://github.com/EsotericSoftware/kryo/blob/master/src/com/esotericsoftware/kryo/ClassResolver.java
> . With this extension we are able to solve the problem of external classes.
> The only issue with kryo is that some classes need a certain care in the
> serialization process and therefore a specialized serializer.
>
> So I would like to know from the community what do think of changing the
> way the optimized marshaller works or introducing the support of yet
> another marshaller based on a kryo like technology?
>
>
> Thanks in advance,
>
>
> Best regards,
>
>
> Romain.
>
>
> PS: I'm ready to help in the both cases.
> "Misys" is the trade name of the Misys group of companies. This email and
> any attachments have been scanned for known viruses using multiple
> scanners. This email message is intended for the named recipient only. It
> may be privileged and/or confidential. If you are not the named recipient
> of this email please notify us immediately and do not copy it or use it for
> any purpose, nor disclose its contents to any other person. This email does
> not constitute the commencement of legal relations between you and Misys.
> Please refer to the executed contract between you and the relevant member
> of the Misys group for the identity of the contracting party with which you
> are dealing.
>

Integration with Spring Transaction Manager

[Dmitriy Setrakyan]

Igniters,

Anyone in the community interested in picking up integration with Spring
Transaction Manager? The implementation should not be difficult, but will
be a very useful addition to the project (many users have been asking for
it).

Here is the Jira ticket:
https://issues.apache.org/jira/browse/IGNITE-1227

D.

IgniteMultiMap design

[Dmitriy Setrakyan]

Igniters,

MultiMap should be really great addition to the Ignite fabric, as it
provides an easy-to-use API to work with time-series data.

I have added a detailed design description to the IgniteMultiMap ticket:
https://issues.apache.org/jira/browse/IGNITE-640

Vladislav Jelisavcic, the ticket is currently assigned to you. If you still
intend to work on it,  please review it and let us know if the design makes
sense.

Also, would be nice if others could review it and provide comments as well.

D.

Re: Hello

[Dmitriy Setrakyan]

Hi Jose,

You can also find interesting Jira tickets to work on here:
https://ignite.apache.org/community/contribute.html#pick-ticket

D.


On Sat, Oct 31, 2015 at 4:55 AM, Gianfranco Murador 
wrote:

> Welcome Josè , take a look at these guidelines:
>  https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> and check in the opened jira if there is one you wish to work on it.
> Thanks , Gianfranco
>
> 2015-10-31 1:05 GMT+01:00 jose renato pequeno :
>
> > Good evening for everyone!
> > My name´s José Renato Pequeno.
> > I work in biggest e-commerce of South America with IT Specialist with
> > focus in Big Data, working with Hadoop and its ecosystem.
> > I´d like to contribute with the Ignite team!
> > Best Regards.
> > José Renato Pequeno
> >
>
>
>
>
> --
> Gianfranco Murador
> Igniter and Software Engineer.
>