Re: LGPL in 1.4 examples

[Sergey Kozlov]

I filed the ticket:
Build examples failed from binary fabric package



On Wed, Sep 30, 2015 at 9:06 AM, Sergey Kozlov  wrote:

>
>
> On Wed, Sep 30, 2015 at 4:10 AM, Dmitriy Setrakyan 
> wrote:
>
>> Igniters,
>>
>> I just downloaded the ignite 1.4 zip from the website and the example
>> project does not build for me out of the box.
>>
>> The reason is that LGPL dependencies are not included into the POM file.
>> This is a serious usability issue. Am I doing something wrong?
>>
>> D.
>>
>
> I confirm that build from fabric binary package is failed:
>
> [INFO]
> 
> [INFO] Building ignite-examples 1.4.0
> [INFO]
> 
> [WARNING] The POM for org.apache.ignite:ignite-hibernate:jar:1.4.0 is
> missing, no dependency information available
> [WARNING] The POM for org.apache.ignite:ignite-schedule:jar:1.4.0 is
> missing, no dependency information available
>
> --
> Sergey Kozlov
>
>


-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Sergey Evdokimov Tickets

[Yakov Zhdanov]

Correct. I meant unassign.

There are no critical tickets in my view -
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20%20status%20!%3D%20closed%20AND%20assignee%20%3D%20sevdokimov-gg%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

--Yakov

2015-09-29 19:44 GMT+03:00 Dmitriy Setrakyan :

> On Tue, Sep 29, 2015 at 4:45 PM, Yakov Zhdanov 
> wrote:
>
> > Hi!
> >
> > I want to ask if Sergey is going to continue working on tickets assigned
> to
> > him? If not, we will reassign them in 72 hours.
> >
>
> I thought you meant "un-assign" not "reassign". Do we know if there are any
> critical tickets that Sergey was working on?
>
>
> >
> > Thanks!
> >
> > --Yakov
> >
>

Re: what is "communication encryption"?

[Dmitriy Setrakyan]

On Wed, Sep 30, 2015 at 8:01 AM, Sergey Kozlov  wrote:

> On Wed, Sep 30, 2015 at 4:51 AM, Dmitriy Setrakyan 
> wrote:
>
> > I got the following printout on 1.4 startup:
> > -
> > Security status [authentication=off, communication encryption=off]
> > -
> >
> > Do we mean SSL by "communication encryption"? If yes, shouldn't we just
> say
> > "ssl=off"?
>
>
> > D.
> >
>
> Yes, in that case communication encryption is SSL
>

Do we have another case? If not, let's rename to "ssl", shorter and to the
point. I think this can be done directly in the master. Any objections?

>

>
> --
> Sergey Kozlov
>

Re: LGPL in 1.4 examples

[Yakov Zhdanov]

We can.

--Yakov

2015-09-30 10:29 GMT+03:00 Dmitriy Setrakyan :

> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov 
> wrote:
>
> > I filed the ticket:
> > Build examples failed from binary fabric package
> > 
> >
>
>
> I think the reason is that we do not upload Ignite LGPL integrations, e.g.
> ignite-hiberbnate artifact to maven central. I don't see why we do not,
> because even though they depend on some LGPL-based code, the ignite module
> itself is licensed under ASL.
>
> Can we upload these artifacts manually?
>
>
> >
> >
> > On Wed, Sep 30, 2015 at 9:06 AM, Sergey Kozlov 
> > wrote:
> >
> > >
> > >
> > > On Wed, Sep 30, 2015 at 4:10 AM, Dmitriy Setrakyan <
> > dsetrak...@apache.org>
> > > wrote:
> > >
> > >> Igniters,
> > >>
> > >> I just downloaded the ignite 1.4 zip from the website and the example
> > >> project does not build for me out of the box.
> > >>
> > >> The reason is that LGPL dependencies are not included into the POM
> file.
> > >> This is a serious usability issue. Am I doing something wrong?
> > >>
> > >> D.
> > >>
> > >
> > > I confirm that build from fabric binary package is failed:
> > >
> > > [INFO]
> > >
> 
> > > [INFO] Building ignite-examples 1.4.0
> > > [INFO]
> > >
> 
> > > [WARNING] The POM for org.apache.ignite:ignite-hibernate:jar:1.4.0 is
> > > missing, no dependency information available
> > > [WARNING] The POM for org.apache.ignite:ignite-schedule:jar:1.4.0 is
> > > missing, no dependency information available
> > >
> > > --
> > > Sergey Kozlov
> > >
> > >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>

Re: LGPL in 1.4 examples

[Branko Čibej]

On 30.09.2015 10:28, Sergey Kozlov wrote:
> Could we build these modules during building example project? It seems a
> bit excessively from user standpoint.

Why do you think users are dumb and lazy and can't issue two build
commands instead of one?


> On Wed, Sep 30, 2015 at 10:45 AM, Branko Čibej  wrote:
>
>> On 30.09.2015 09:29, Dmitriy Setrakyan wrote:
>>> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov 
>> wrote:
 I filed the ticket:
 Build examples failed from binary fabric package
 

>>> I think the reason is that we do not upload Ignite LGPL integrations,
>> e.g.
>>> ignite-hiberbnate artifact to maven central. I don't see why we do not,
>>> because even though they depend on some LGPL-based code, the ignite
>> module
>>> itself is licensed under ASL.
>>>
>>> Can we upload these artifacts manually?
>> We've been through this any number of times, yes? We cannot distribute
>> (L)GPL dependencies. If you can't run a reasonable grid that doesn't
>> depend on LGPL-licensed modules, then those modules are not "optional"
>> by any reasonable definition.
>>
>> It's quite all right to have examples that require those modules; just
>> tell users that if they want to run those examples, they'll have to
>> build Ignite (or at least the LGPL dependencies) themselves.
>>
>> -- Brane
>>
>>
>

[jira] [Created] (IGNITE-1580) CPP: Review Ignition interface.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1580:
---

 Summary: CPP: Review Ignition interface.
 Key: IGNITE-1580
 URL: https://issues.apache.org/jira/browse/IGNITE-1580
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Priority: Critical
 Fix For: ignite-1.5


It is necessary to review Ignition interface and understand whether it is 
compliant with common CPP practices. 



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

Re: LGPL in 1.4 examples

[Sergey Kozlov]

On Wed, Sep 30, 2015 at 4:10 AM, Dmitriy Setrakyan 
wrote:

> Igniters,
>
> I just downloaded the ignite 1.4 zip from the website and the example
> project does not build for me out of the box.
>
> The reason is that LGPL dependencies are not included into the POM file.
> This is a serious usability issue. Am I doing something wrong?
>
> D.
>

I confirm that build from fabric binary package is failed:

[INFO]

[INFO] Building ignite-examples 1.4.0
[INFO]

[WARNING] The POM for org.apache.ignite:ignite-hibernate:jar:1.4.0 is
missing, no dependency information available
[WARNING] The POM for org.apache.ignite:ignite-schedule:jar:1.4.0 is
missing, no dependency information available

-- 
Sergey Kozlov

Re: Switched main version to 1.4 on readme.io

[Yakov Zhdanov]

done.

--Yakov

2015-09-29 20:34 GMT+03:00 Dmitriy Setrakyan :

> Yakov,
>
> The javadoc link on Ignite documentation still points to 1.3. Can you make
> the switch?
>
> Thanks,
> D.
>
> On Mon, Sep 28, 2015 at 3:24 PM, Yakov Zhdanov 
> wrote:
>
> > subj
> >
> > --Yakov
> >
>

Re: Introducing "compatibility level" concept.

[Branko Čibej]

On 30.09.2015 09:51, Vladimir Ozerov wrote:
> Igniters,
>
> Normally we are trying to maintain backward compatibility with previous
> versions. But it is not always possible.
>
> E.g. we are about to release portable protocol. There are lots suggestions
> how to optimize it, but all of them are relatively hard to implement. It
> would not be a problem if are able to improve it iteratively from release
> to release while still allowing for different versions (e.g. 1.5 and 1.6)
> to communicate.
>
> What if we add a top-level property "*compatibility level*" allowing user
> to "downgrade" some parts of the system to communicate with earlier
> versions?

That's likely to be a huge pain to maintain. The problem is that it
doesn't force you to think about compatibility too much, and you'll end
up having any number of incompatible protocols that you'll have to
maintain simultaneously.

There's an IMO better way: define the protocol to be natrually
extensible, and introduce a capability exchange step. Map protocol
extensions to capabilities (these can represented as simple tokens, or
whatever), then make the client and server use any capabilities that are
common to both.

We do this in Subversion; that's how a 1.9 server can work with a 1.0
client but the same server will work much better (with more features
available) with a 1.9 client. And the other way around, of course.

-- Brane

Re: LGPL in 1.4 examples

[Branko Čibej]

On 30.09.2015 09:29, Dmitriy Setrakyan wrote:
> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov  wrote:
>
>> I filed the ticket:
>> Build examples failed from binary fabric package
>> 
>>
>
> I think the reason is that we do not upload Ignite LGPL integrations, e.g.
> ignite-hiberbnate artifact to maven central. I don't see why we do not,
> because even though they depend on some LGPL-based code, the ignite module
> itself is licensed under ASL.
>
> Can we upload these artifacts manually?

We've been through this any number of times, yes? We cannot distribute
(L)GPL dependencies. If you can't run a reasonable grid that doesn't
depend on LGPL-licensed modules, then those modules are not "optional"
by any reasonable definition.

It's quite all right to have examples that require those modules; just
tell users that if they want to run those examples, they'll have to
build Ignite (or at least the LGPL dependencies) themselves.

-- Brane

Re: Introducing "compatibility level" concept.

[Vladimir Ozerov]

Brane,

I see you point, but I do not see how we can implement it in our
distributed environment. Very weird situations could appear. E.g. if there
are two versions A and B:
1) Node A starts.
2) Node B starts and agrees with A to use old A-protocol.
3) Some data is persisted on disk using A-protocol;
4) Cluster shuts down.
5) Several new B-nodes appear, but have no clue that something was
persisted using A-protocol. They decide to use B-protocol.
6) Node A restarts and meets unknown B-protocol.

On Wed, Sep 30, 2015 at 11:01 AM, Branko Čibej  wrote:

> On 30.09.2015 09:51, Vladimir Ozerov wrote:
> > Igniters,
> >
> > Normally we are trying to maintain backward compatibility with previous
> > versions. But it is not always possible.
> >
> > E.g. we are about to release portable protocol. There are lots
> suggestions
> > how to optimize it, but all of them are relatively hard to implement. It
> > would not be a problem if are able to improve it iteratively from release
> > to release while still allowing for different versions (e.g. 1.5 and 1.6)
> > to communicate.
> >
> > What if we add a top-level property "*compatibility level*" allowing user
> > to "downgrade" some parts of the system to communicate with earlier
> > versions?
>
> That's likely to be a huge pain to maintain. The problem is that it
> doesn't force you to think about compatibility too much, and you'll end
> up having any number of incompatible protocols that you'll have to
> maintain simultaneously.
>
> There's an IMO better way: define the protocol to be natrually
> extensible, and introduce a capability exchange step. Map protocol
> extensions to capabilities (these can represented as simple tokens, or
> whatever), then make the client and server use any capabilities that are
> common to both.
>
> We do this in Subversion; that's how a 1.9 server can work with a 1.0
> client but the same server will work much better (with more features
> available) with a 1.9 client. And the other way around, of course.
>
> -- Brane
>

Re: Ignite 1.5 plans

[Dmitriy Setrakyan]

On Wed, Sep 30, 2015 at 4:34 AM, Nikita Ivanov  wrote:

> I'm not sure how a file system concept corresponds to shared RDD or custom
> MapReduce implementation... May we should have another "assembly" just for
> in-memory file system?
>

And how would users use IgniteRDD and IGFS in the same project? There could
be a use case when RDDs are used for objects and IGFS for files in the same
application.


>
> --
> Nikita Ivanov
>
>
> On Tue, Sep 29, 2015 at 7:04 PM, Dmitriy Setrakyan 
> wrote:
>
> > How about we rename the hadoop-accelerator to "in-memory file system" and
> > include spark and map-reduce there as well.
> >
> > "In-memory file system" is a known entity and will bring more interest.
> We
> > can position the map-reduce and spark RDD as additional features there.
> >
> > Thoughts?
> >
> > D.
> >
> > On Wed, Sep 30, 2015 at 4:00 AM, Nikita Ivanov 
> > wrote:
> >
> > > Well, my thinking at this point is that none of these three modules
> would
> > > interest in real life. So, I was thinking of giving users a clear
> > direction
> > > on getting a) fabric only, b) hadoop accelerator, and c) spark
> > integration.
> > >
> > > --
> > > Nikita Ivanov
> > >
> > >
> > > On Tue, Sep 29, 2015 at 5:29 PM, Konstantin Boudnik 
> > > wrote:
> > >
> > > > One of the reasons is that I don't believe that running two builds to
> > get
> > > > two
> > > > different module assemblies is a right or useful idea. I can use
> > reactor
> > > to
> > > > build just what's needed, but looks like it won't produce specific
> > > > assemblies,
> > > > because spark is included into core package. hence, I would have to
> > move
> > > > the
> > > > jars selection logic into the packaging, which seems orthogonal to
> the
> > > case
> > > > at hands.
> > > >
> > > > As for the intersection of the two: will Spark more often intersect
> > with
> > > > the
> > > > data fabric core, you think?
> > > >
> > > > Cos
> > > >
> > > > On Tue, Sep 29, 2015 at 10:58AM, Nikita Ivanov wrote:
> > > > > Cos - why mixing the two? I think if we are embark on this route -
> > why
> > > > not
> > > > > create two different assemblies, one for Hadoop bits, and another
> for
> > > > Spark
> > > > > integration? Two would rarely intersect IMHO.
> > > > >
> > > > > --
> > > > > Nikita Ivanov
> > > > >
> > > > >
> > > > > On Mon, Sep 28, 2015 at 10:40 PM, Konstantin Boudnik <
> c...@apache.org
> > >
> > > > wrote:
> > > > >
> > > > > > While a  minor modification which won't affect anything, I'd like
> > to
> > > > put
> > > > > > on the table the consolidation of hadoodp and spark bits into
> > > > > > ignite-accelerator assembly. The fix is ready and I was just
> > waiting
> > > > for
> > > > > > 1.4 to come out.
> > > > > >
> > > > > > Cos
> > > > > >
> > > > > > On September 28, 2015 11:11:44 AM PDT, Vladimir Ozerov <
> > > > > > voze...@gridgain.com> wrote:
> > > > > > >I'd like to add several things.
> > > > > > >1) It looks like fix for IBM JVM will brake backward
> compatibility
> > > > > > >because
> > > > > > >the problem is caused by missing serialVersionId, right?
> > > > > > >2) HP-UX users are also concerned, see last comments in
> > > > > > >https://issues.apache.org/jira/browse/IGNITE-1493 I think we
> must
> > > > > > >adress
> > > > > > >Unsafe refactoring in this release as well.
> > > > > > >
> > > > > > >On Mon, Sep 28, 2015 at 7:57 PM, Dmitriy Setrakyan
> > > > > > >
> > > > > > >wrote:
> > > > > > >
> > > > > > >> Gianfranco,
> > > > > > >>
> > > > > > >> I am not too familiar with JBPM. Can you make a case on why we
> > may
> > > > > > >need
> > > > > > >> this integration and how it will benefit Ignite users?
> > > > > > >>
> > > > > > >> Thanks,
> > > > > > >> D.
> > > > > > >>
> > > > > > >> On Mon, Sep 28, 2015 at 6:56 PM, Gianfranco Murador
> > > > > > >
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >> > I would like to propose the integration with JBPM ,
> > > > > > >> >  I think I can finish in a couple of weeks since I have a
> bit
> > of
> > > > > > >time to
> > > > > > >> > devote to Ignite.
> > > > > > >> >  Let me know if you agree.
> > > > > > >> > Regards, Gianfranco
> > > > > > >> >
> > > > > > >> > 2015-09-28 18:50 GMT+02:00 Dmitriy Setrakyan
> > > > > > >:
> > > > > > >> >
> > > > > > >> > > I would like to add one more:
> > > > > > >> > > 10. OSGI integration - Raul Kripalani
> > > > > > >> > >
> > > > > > >> > > Raul, hopefully you will have time to finish it.
> > > > > > >> > >
> > > > > > >> > > Also, if anyone in the community wants to propose a
> feature
> > > they
> > > > > > >are
> > > > > > >> > > working on which can be finished within next couple of
> > weeks,
> > > it
> > > > > > >should
> > > > > > >> > get
> > > > > > >> > > into 1.5 as well.
> > > > > > >> > >
> > > > > > >> > > D.
> > > > > > >> > >
> > > > > > >> > > On Mon, Sep 28, 2015 at 6:43 

Re: LGPL in 1.4 examples

[Dmitriy Setrakyan]

On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov  wrote:

> I filed the ticket:
> Build examples failed from binary fabric package
> 
>


I think the reason is that we do not upload Ignite LGPL integrations, e.g.
ignite-hiberbnate artifact to maven central. I don't see why we do not,
because even though they depend on some LGPL-based code, the ignite module
itself is licensed under ASL.

Can we upload these artifacts manually?


>
>
> On Wed, Sep 30, 2015 at 9:06 AM, Sergey Kozlov 
> wrote:
>
> >
> >
> > On Wed, Sep 30, 2015 at 4:10 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> >> Igniters,
> >>
> >> I just downloaded the ignite 1.4 zip from the website and the example
> >> project does not build for me out of the box.
> >>
> >> The reason is that LGPL dependencies are not included into the POM file.
> >> This is a serious usability issue. Am I doing something wrong?
> >>
> >> D.
> >>
> >
> > I confirm that build from fabric binary package is failed:
> >
> > [INFO]
> > 
> > [INFO] Building ignite-examples 1.4.0
> > [INFO]
> > 
> > [WARNING] The POM for org.apache.ignite:ignite-hibernate:jar:1.4.0 is
> > missing, no dependency information available
> > [WARNING] The POM for org.apache.ignite:ignite-schedule:jar:1.4.0 is
> > missing, no dependency information available
> >
> > --
> > Sergey Kozlov
> >
> >
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

Introducing "compatibility level" concept.

[Vladimir Ozerov]

Igniters,

Normally we are trying to maintain backward compatibility with previous
versions. But it is not always possible.

E.g. we are about to release portable protocol. There are lots suggestions
how to optimize it, but all of them are relatively hard to implement. It
would not be a problem if are able to improve it iteratively from release
to release while still allowing for different versions (e.g. 1.5 and 1.6)
to communicate.

What if we add a top-level property "*compatibility level*" allowing user
to "downgrade" some parts of the system to communicate with earlier
versions?

Vladimir.

[jira] [Created] (IGNITE-1579) Build examples failed from binary fabric package

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-1579:
-

 Summary: Build examples failed from binary fabric package
 Key: IGNITE-1579
 URL: https://issues.apache.org/jira/browse/IGNITE-1579
 Project: Ignite
  Issue Type: Bug
Affects Versions: ignite-1.4
Reporter: Sergey Kozlov
 Fix For: ignite-1.5


{noformat}
[INFO] Scanning for projects...
[INFO] 
[INFO] 
[INFO] Building ignite-examples 1.4.0
[INFO] 
[WARNING] The POM for org.apache.ignite:ignite-hibernate:jar:1.4.0 is missing, 
no dependency information available
[WARNING] The POM for org.apache.ignite:ignite-schedule:jar:1.4.0 is missing, 
no dependency information available
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 0.404 s
[INFO] Finished at: 2015-09-30T09:06:08+03:00
[INFO] Final Memory: 7M/245M
{noformat}



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

Re: New 'Deployment tasks' article on readme.io

[Yakov Zhdanov]

I am looking at this page -
https://apacheignite.readme.io/docs/deployment-spi. Correct?

Good job! However, I have minor comments:

1. SPI parameters explanations and code example should be before scanners
(scanner is SPI config as well, just more detailed info)
2. code example should include all scanners + add spring configuration
example
3.
>> quot
Http Uri Example
The following example will scan ignite/deployment folder on site
www.mysite.com using authentication 'username:password' every '1'
milliseconds.
http://username:password;freq=10...@www.mysite.com:110/ignite/deployment
>>/quot

I thought this scanner will download the page served by a server and
mysite.com:110 (that will be default page), parse it and download and
deploy all GAR files specified by href attributes of  elements on the
page. Please correct your content if you agree.

Thanks!

--Yakov

2015-09-30 4:41 GMT+03:00 Dmitriy Setrakyan :

> Artem,
>
> I would move the deployment SPI documentation as a bottom section in "Zero
> Deployment" page. Also, please use this link for documentation:
>
> https://apacheignite.readme.io/docs
>
> D.
>
> On Tue, Sep 29, 2015 at 8:47 PM, Artem Shutak 
> wrote:
>
> > Folks,
> >
> > In process of working on [1] I've been created new article [2] on
> > readme.io
> > as long as this functionality has been missed in documentation. Please
> > review and feel free to comment.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-1559
> > [2] http://apacheignite.gridgain.org/docs/deployment-tasks
> >
> > -- Artem --
> >
>

Re: Introducing "compatibility level" concept.

[Branko Čibej]

My point is that is has to be just one extensible protocol. So in your
case, either: in step 6, the node A would be able to read the
A-compatible bits of data; or: in step 5, the B-nodes will know that the
persistent store was made with A.

Doing it any other way will force you to dumb down your whole grid,
caches, etc. to the lowest common denominator; which makes heterogeneous
grids impossible, and therefore makes rolling upgrades on a live grid
impossible.

Of course you may not care about these scenarios.

-- Brane

On 30.09.2015 10:12, Vladimir Ozerov wrote:
> Brane,
>
> I see you point, but I do not see how we can implement it in our
> distributed environment. Very weird situations could appear. E.g. if there
> are two versions A and B:
> 1) Node A starts.
> 2) Node B starts and agrees with A to use old A-protocol.
> 3) Some data is persisted on disk using A-protocol;
> 4) Cluster shuts down.
> 5) Several new B-nodes appear, but have no clue that something was
> persisted using A-protocol. They decide to use B-protocol.
> 6) Node A restarts and meets unknown B-protocol.
>
> On Wed, Sep 30, 2015 at 11:01 AM, Branko Čibej  wrote:
>
>> On 30.09.2015 09:51, Vladimir Ozerov wrote:
>>> Igniters,
>>>
>>> Normally we are trying to maintain backward compatibility with previous
>>> versions. But it is not always possible.
>>>
>>> E.g. we are about to release portable protocol. There are lots
>> suggestions
>>> how to optimize it, but all of them are relatively hard to implement. It
>>> would not be a problem if are able to improve it iteratively from release
>>> to release while still allowing for different versions (e.g. 1.5 and 1.6)
>>> to communicate.
>>>
>>> What if we add a top-level property "*compatibility level*" allowing user
>>> to "downgrade" some parts of the system to communicate with earlier
>>> versions?
>> That's likely to be a huge pain to maintain. The problem is that it
>> doesn't force you to think about compatibility too much, and you'll end
>> up having any number of incompatible protocols that you'll have to
>> maintain simultaneously.
>>
>> There's an IMO better way: define the protocol to be natrually
>> extensible, and introduce a capability exchange step. Map protocol
>> extensions to capabilities (these can represented as simple tokens, or
>> whatever), then make the client and server use any capabilities that are
>> common to both.
>>
>> We do this in Subversion; that's how a 1.9 server can work with a 1.0
>> client but the same server will work much better (with more features
>> available) with a 1.9 client. And the other way around, of course.
>>
>> -- Brane
>>

Re: LGPL in 1.4 examples

[Branko Čibej]

On 30.09.2015 10:30, Dmitriy Setrakyan wrote:
> On Wed, Sep 30, 2015 at 9:45 AM, Branko Čibej  wrote:
>
>> On 30.09.2015 09:29, Dmitriy Setrakyan wrote:
>>> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov 
>> wrote:
 I filed the ticket:
 Build examples failed from binary fabric package
 

>>> I think the reason is that we do not upload Ignite LGPL integrations,
>> e.g.
>>> ignite-hiberbnate artifact to maven central. I don't see why we do not,
>>> because even though they depend on some LGPL-based code, the ignite
>> module
>>> itself is licensed under ASL.
>>>
>>> Can we upload these artifacts manually?
>> We've been through this any number of times, yes? We cannot distribute
>> (L)GPL dependencies. If you can't run a reasonable grid that doesn't
>> depend on LGPL-licensed modules, then those modules are not "optional"
>> by any reasonable definition.
>>
>> It's quite all right to have examples that require those modules; just
>> tell users that if they want to run those examples, they'll have to
>> build Ignite (or at least the LGPL dependencies) themselves.
>>
>
> Hm... I thought that ignite-hibernate module could still be published to
> Maven because the module itself is licensed under ASL2.0 license.

People keep misunderstanding the LGPL. You really should read it. The
"module itself" cannot be licensed under ALv2. For example, this is
LGPL2.1 section 5 paragraph 2:

However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because
it contains portions of the Library), rather than a "work that uses
the library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.


In other words, as soon as you *build* something that is linked with
LGPL, it's covered by the LGPL. The sources of the module can be ALv2,
but the built module isn't.

This is why ASF policy forbids mandatory (L)GPL dependencies and
absolutely forbids releases containing (L)GPL code. And whilst the
binaries we put on Maven aren't "releases", they must follow these policies.

> If not, then we should not include these modules into the main set of
> examples, primarily because there is no way for a user to build them out of
> the box.
>
> I see 2 solutions:
>
> 1. Remove modules that depend on LGPL from the examples altogether.
> 2. Add a separate LGPL folder in examples, which will not be included into
> the POM file with a special README explaining how to build them.


Option 2 is acceptable.

-- Brane

Re: what is "communication encryption"?

[Sergey Kozlov]

On Wed, Sep 30, 2015 at 4:51 AM, Dmitriy Setrakyan 
wrote:

> I got the following printout on 1.4 startup:
> -
> Security status [authentication=off, communication encryption=off]
> -
>
> Do we mean SSL by "communication encryption"? If yes, shouldn't we just say
> "ssl=off"?
>
> D.
>

Yes, in that case communication encryption is SSL

-- 
Sergey Kozlov

Re: LGPL in 1.4 examples

[Dmitriy Setrakyan]

On Wed, Sep 30, 2015 at 9:34 AM, Yakov Zhdanov  wrote:

> We can.
>

I am currently at ApacheCon. Let me ask a few folks. I will respond here
soon.


>
> --Yakov
>
> 2015-09-30 10:29 GMT+03:00 Dmitriy Setrakyan :
>
> > On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov 
> > wrote:
> >
> > > I filed the ticket:
> > > Build examples failed from binary fabric package
> > > 
> > >
> >
> >
> > I think the reason is that we do not upload Ignite LGPL integrations,
> e.g.
> > ignite-hiberbnate artifact to maven central. I don't see why we do not,
> > because even though they depend on some LGPL-based code, the ignite
> module
> > itself is licensed under ASL.
> >
> > Can we upload these artifacts manually?
> >
> >
> > >
> > >
> > > On Wed, Sep 30, 2015 at 9:06 AM, Sergey Kozlov 
> > > wrote:
> > >
> > > >
> > > >
> > > > On Wed, Sep 30, 2015 at 4:10 AM, Dmitriy Setrakyan <
> > > dsetrak...@apache.org>
> > > > wrote:
> > > >
> > > >> Igniters,
> > > >>
> > > >> I just downloaded the ignite 1.4 zip from the website and the
> example
> > > >> project does not build for me out of the box.
> > > >>
> > > >> The reason is that LGPL dependencies are not included into the POM
> > file.
> > > >> This is a serious usability issue. Am I doing something wrong?
> > > >>
> > > >> D.
> > > >>
> > > >
> > > > I confirm that build from fabric binary package is failed:
> > > >
> > > > [INFO]
> > > >
> > 
> > > > [INFO] Building ignite-examples 1.4.0
> > > > [INFO]
> > > >
> > 
> > > > [WARNING] The POM for org.apache.ignite:ignite-hibernate:jar:1.4.0 is
> > > > missing, no dependency information available
> > > > [WARNING] The POM for org.apache.ignite:ignite-schedule:jar:1.4.0 is
> > > > missing, no dependency information available
> > > >
> > > > --
> > > > Sergey Kozlov
> > > >
> > > >
> > >
> > >
> > > --
> > > Sergey Kozlov
> > > GridGain Systems
> > > www.gridgain.com
> > >
> >
>

Re: New 'Deployment tasks' article on readme.io

[Artem Shutak]

Dmitriy, I think it should stay under "Compute Grid" block because
Deployment SPI have the meaning only for ComputeTasks.

Yakov, yes, Valentine has reviewed the jira and changed page name on:
https://apacheignite.readme.io/docs/deployment-spi. I will fix your
comments and will update the jira.

Thanks for comments!

-- Artem --

On Wed, Sep 30, 2015 at 10:54 AM, Yakov Zhdanov  wrote:

> I am looking at this page -
> https://apacheignite.readme.io/docs/deployment-spi. Correct?
>
> Good job! However, I have minor comments:
>
> 1. SPI parameters explanations and code example should be before scanners
> (scanner is SPI config as well, just more detailed info)
> 2. code example should include all scanners + add spring configuration
> example
> 3.
> >> quot
> Http Uri Example
> The following example will scan ignite/deployment folder on site
> www.mysite.com using authentication 'username:password' every '1'
> milliseconds.
> http://username:password;freq=10...@www.mysite.com:110/ignite/deployment
> >>/quot
>
> I thought this scanner will download the page served by a server and
> mysite.com:110 (that will be default page), parse it and download and
> deploy all GAR files specified by href attributes of  elements on the
> page. Please correct your content if you agree.
>
> Thanks!
>
> --Yakov
>
> 2015-09-30 4:41 GMT+03:00 Dmitriy Setrakyan :
>
> > Artem,
> >
> > I would move the deployment SPI documentation as a bottom section in
> "Zero
> > Deployment" page. Also, please use this link for documentation:
> >
> > https://apacheignite.readme.io/docs
> >
> > D.
> >
> > On Tue, Sep 29, 2015 at 8:47 PM, Artem Shutak 
> > wrote:
> >
> > > Folks,
> > >
> > > In process of working on [1] I've been created new article [2] on
> > > readme.io
> > > as long as this functionality has been missed in documentation. Please
> > > review and feel free to comment.
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-1559
> > > [2] http://apacheignite.gridgain.org/docs/deployment-tasks
> > >
> > > -- Artem --
> > >
> >
>

[GitHub] ignite pull request: IGNITE-1573: mkdirs concurrency fixed.

[iveselovskiy]

GitHub user iveselovskiy opened a pull request:

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

IGNITE-1573: mkdirs concurrency fixed.



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

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

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

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


commit a1208cdef23ea4e81f78c99b84d19731d9ec4261
Author: iveselovskiy 
Date:   2015-09-30T10:56:06Z

IGNITE-1573: mkdirs concurrency fixed.




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

[Konstantin Boudnik]

With my Ignite hat on, I think having them together in the same assembly makes
sense. After all, this is why I have offered the patch in the form it is right
now.

With my Bigtop hat on: I don't care one way or another. As soon as I can
produce one or more assemblies that will have all the required bits in it - I
will hack them anyway to produce seamless native installation experience for
the users.

I am happy to to change the patch to produce two assemblies or six as far as
we can unblock the Bigtop change.

Thanks,
  Cos

On Wed, Sep 30, 2015 at 09:14AM, Dmitriy Setrakyan wrote:
> On Wed, Sep 30, 2015 at 4:34 AM, Nikita Ivanov  wrote:
> 
> > I'm not sure how a file system concept corresponds to shared RDD or custom
> > MapReduce implementation... May we should have another "assembly" just for
> > in-memory file system?
> >
> 
> And how would users use IgniteRDD and IGFS in the same project? There could
> be a use case when RDDs are used for objects and IGFS for files in the same
> application.
> 
> 
> >
> > --
> > Nikita Ivanov
> >
> >
> > On Tue, Sep 29, 2015 at 7:04 PM, Dmitriy Setrakyan 
> > wrote:
> >
> > > How about we rename the hadoop-accelerator to "in-memory file system" and
> > > include spark and map-reduce there as well.
> > >
> > > "In-memory file system" is a known entity and will bring more interest.
> > We
> > > can position the map-reduce and spark RDD as additional features there.
> > >
> > > Thoughts?
> > >
> > > D.
> > >
> > > On Wed, Sep 30, 2015 at 4:00 AM, Nikita Ivanov 
> > > wrote:
> > >
> > > > Well, my thinking at this point is that none of these three modules
> > would
> > > > interest in real life. So, I was thinking of giving users a clear
> > > direction
> > > > on getting a) fabric only, b) hadoop accelerator, and c) spark
> > > integration.
> > > >
> > > > --
> > > > Nikita Ivanov
> > > >
> > > >
> > > > On Tue, Sep 29, 2015 at 5:29 PM, Konstantin Boudnik 
> > > > wrote:
> > > >
> > > > > One of the reasons is that I don't believe that running two builds to
> > > get
> > > > > two
> > > > > different module assemblies is a right or useful idea. I can use
> > > reactor
> > > > to
> > > > > build just what's needed, but looks like it won't produce specific
> > > > > assemblies,
> > > > > because spark is included into core package. hence, I would have to
> > > move
> > > > > the
> > > > > jars selection logic into the packaging, which seems orthogonal to
> > the
> > > > case
> > > > > at hands.
> > > > >
> > > > > As for the intersection of the two: will Spark more often intersect
> > > with
> > > > > the
> > > > > data fabric core, you think?
> > > > >
> > > > > Cos
> > > > >
> > > > > On Tue, Sep 29, 2015 at 10:58AM, Nikita Ivanov wrote:
> > > > > > Cos - why mixing the two? I think if we are embark on this route -
> > > why
> > > > > not
> > > > > > create two different assemblies, one for Hadoop bits, and another
> > for
> > > > > Spark
> > > > > > integration? Two would rarely intersect IMHO.
> > > > > >
> > > > > > --
> > > > > > Nikita Ivanov
> > > > > >
> > > > > >
> > > > > > On Mon, Sep 28, 2015 at 10:40 PM, Konstantin Boudnik <
> > c...@apache.org
> > > >
> > > > > wrote:
> > > > > >
> > > > > > > While a  minor modification which won't affect anything, I'd like
> > > to
> > > > > put
> > > > > > > on the table the consolidation of hadoodp and spark bits into
> > > > > > > ignite-accelerator assembly. The fix is ready and I was just
> > > waiting
> > > > > for
> > > > > > > 1.4 to come out.
> > > > > > >
> > > > > > > Cos
> > > > > > >
> > > > > > > On September 28, 2015 11:11:44 AM PDT, Vladimir Ozerov <
> > > > > > > voze...@gridgain.com> wrote:
> > > > > > > >I'd like to add several things.
> > > > > > > >1) It looks like fix for IBM JVM will brake backward
> > compatibility
> > > > > > > >because
> > > > > > > >the problem is caused by missing serialVersionId, right?
> > > > > > > >2) HP-UX users are also concerned, see last comments in
> > > > > > > >https://issues.apache.org/jira/browse/IGNITE-1493 I think we
> > must
> > > > > > > >adress
> > > > > > > >Unsafe refactoring in this release as well.
> > > > > > > >
> > > > > > > >On Mon, Sep 28, 2015 at 7:57 PM, Dmitriy Setrakyan
> > > > > > > >
> > > > > > > >wrote:
> > > > > > > >
> > > > > > > >> Gianfranco,
> > > > > > > >>
> > > > > > > >> I am not too familiar with JBPM. Can you make a case on why we
> > > may
> > > > > > > >need
> > > > > > > >> this integration and how it will benefit Ignite users?
> > > > > > > >>
> > > > > > > >> Thanks,
> > > > > > > >> D.
> > > > > > > >>
> > > > > > > >> On Mon, Sep 28, 2015 at 6:56 PM, Gianfranco Murador
> > > > > > > >
> > > > > > > >> wrote:
> > > > > > > >>
> > > > > > > >> > I would like to propose the integration with JBPM ,
> > > > > > > >> >  I think I can finish in a couple of weeks since I have a
> > bit
> > > of
> > > > > > > 

Re: Introducing "compatibility level" concept.

[Raul Kripalani]

Exposing a manually adjustable "compatibility level" makes the user a
participant of Ignite's internals – something I dislike. Most users won't
bother with investigating deep enough to make an informed decision to set
this value accordingly, and it'll end up being the typical obscure config
parameter that only a handful of people understand.

I would prefer an intelligent handshake/negotiation like Branko proposed.
Mapping protocol versions to capabilities and intersecting both peers to
find the common set. Some capabilities must be compulsory, others can be
optional.

For those that are optional we may need to define a policy of how Ignite
should act if the user's code attempts to use a capability that's currently
unsupported by the topology -- do we fail with an Exception (blocking
user's code)? Do we define a fallback behaviour for each capability? Do we
ignore the user's attempt to use an unsupported capability?

While this level of dynamic negotiation sounds appealing, it can lead to
extremely unpredictable results. Imagine we have nodes A, B, C, all on
v3.0. A client node dispatches a ComputeJob that uses some new
functionality introduced in v3.0: it executes correctly. Now node D joins
and dumbs down the whole grid to 2.0. The next time the client dispatches
the same job, it'll fail.

Needless to say that the effort to maintain infinite compatibility policies
between versions is going to be huge and it'll lead to technical baggage.

So some things to consider:

* Don't make the user a participant of the internal protocol. Instead,
let's make the community agree on a backwards compatibility policy, e.g.
let's declare that major versions of Ignite will NOT be compatible with old
major versions (1.x vs 2.x), and that minor versions will only be
compatible two steps back, e.g. (1.4.x will be compatible at most with
1.2.x, but not with 1.1.x). This will also gently push users to keep
upgrading and not dwelling in old versions because they're compatible with
everything.

* Separate the different interoperability protocols we have in Ignite:
communication, persistence, etc. And make those versionable independently
of one another.

* How about a "Grid stabilisation period" parameter? A window of grace
(e.g. 30 min) during which existing nodes will dumb down to the common
denominator. After that window elapses, no further dumbing down will be
allowed. New nodes attempting to join and trigger further dumbing down will
be rejected.

At the end of the day, I doubt that users running Ignite 2.1.0 will
suddenly want to join an Ignite 1.0.0 node 3 days after the grid has
started...

*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 Wed, Sep 30, 2015 at 9:28 AM, Branko Čibej  wrote:

> My point is that is has to be just one extensible protocol. So in your
> case, either: in step 6, the node A would be able to read the
> A-compatible bits of data; or: in step 5, the B-nodes will know that the
> persistent store was made with A.
>
> Doing it any other way will force you to dumb down your whole grid,
> caches, etc. to the lowest common denominator; which makes heterogeneous
> grids impossible, and therefore makes rolling upgrades on a live grid
> impossible.
>
> Of course you may not care about these scenarios.
>
> -- Brane
>
> On 30.09.2015 10:12, Vladimir Ozerov wrote:
> > Brane,
> >
> > I see you point, but I do not see how we can implement it in our
> > distributed environment. Very weird situations could appear. E.g. if
> there
> > are two versions A and B:
> > 1) Node A starts.
> > 2) Node B starts and agrees with A to use old A-protocol.
> > 3) Some data is persisted on disk using A-protocol;
> > 4) Cluster shuts down.
> > 5) Several new B-nodes appear, but have no clue that something was
> > persisted using A-protocol. They decide to use B-protocol.
> > 6) Node A restarts and meets unknown B-protocol.
> >
> > On Wed, Sep 30, 2015 at 11:01 AM, Branko Čibej  wrote:
> >
> >> On 30.09.2015 09:51, Vladimir Ozerov wrote:
> >>> Igniters,
> >>>
> >>> Normally we are trying to maintain backward compatibility with previous
> >>> versions. But it is not always possible.
> >>>
> >>> E.g. we are about to release portable protocol. There are lots
> >> suggestions
> >>> how to optimize it, but all of them are relatively hard to implement.
> It
> >>> would not be a problem if are able to improve it iteratively from
> release
> >>> to release while still allowing for different versions (e.g. 1.5 and
> 1.6)
> >>> to communicate.
> >>>
> >>> What if we add a top-level property "*compatibility level*" allowing
> user
> >>> to "downgrade" some parts of the system to communicate with earlier
> >>> versions?
> >> That's likely to be a huge pain to maintain. The problem is that it
> >> doesn't force you to think about 

Re: Sergey Evdokimov Tickets

[Dmitriy Setrakyan]

On Wed, Sep 30, 2015 at 10:18 AM, Gianfranco Murador 
wrote:

> Some ticket seem resolved , but the state has been left "open" . I like to
> work on  IGNITE-417 and IGNITE-888 with the right help from community;
>

Gianfranco, I am not sure IGNITE-888 is a valid ticket. I personally do
knot know what it means. Looks like Sergey E. was the one who filed the
ticket. Does anyone know what this ticket is about?

As far as IGNITE-417, I think this ticket might be valid, although there is
no reproducible test. I would start from trying to reproduce it in a test
(it might be that it has been fixed already in 1.4, in which case we should
close the ticket)

D.


> 2015-09-30 9:42 GMT+02:00 Dmitriy Setrakyan :
>
> > On Wed, Sep 30, 2015 at 9:01 AM, Yakov Zhdanov 
> > wrote:
> >
> > > Correct. I meant unassign.
> > >
> > > There are no critical tickets in my view -
> > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20%20status%20!%3D%20closed%20AND%20assignee%20%3D%20sevdokimov-gg%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >
> >
> > I think that community should feel free to grab these tickets if they
> have
> > not had any activity for a while.
> >
> >
> > >
> > > --Yakov
> > >
> > > 2015-09-29 19:44 GMT+03:00 Dmitriy Setrakyan :
> > >
> > > > On Tue, Sep 29, 2015 at 4:45 PM, Yakov Zhdanov 
> > > > wrote:
> > > >
> > > > > Hi!
> > > > >
> > > > > I want to ask if Sergey is going to continue working on tickets
> > > assigned
> > > > to
> > > > > him? If not, we will reassign them in 72 hours.
> > > > >
> > > >
> > > > I thought you meant "un-assign" not "reassign". Do we know if there
> are
> > > any
> > > > critical tickets that Sergey was working on?
> > > >
> > > >
> > > > >
> > > > > Thanks!
> > > > >
> > > > > --Yakov
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Gianfranco Murador
> Igniter and Software Engineer.
>

Re: what is "communication encryption"?

[Branko Čibej]

On 30.09.2015 11:18, Nikolay Tikhonov wrote:
> SslContextFactory allows to set different encryption protocols (by default
> TLS). I think that just "ssl" confuses users. Might be "ssl\tls=off" more
> acceptable?

SSL is one (rather old) specification of Transport Layer Security (TLS).
These days, you shouldn't be using any version of the SSL protocol; they
all have unfixable security holes.

To be moderately safe, you should implement TLS v1.2 with fallback
allowed to TLS v1.0 but not lower. Even then, certificates should use at
least SHA256, preferably SHA512; SHA1 is no longer considered secure. I
don't recall offhand which ciphers are considered secure, but there
aren't very many of them.

-- Brane


> On Wed, Sep 30, 2015 at 11:53 AM, Dmitriy Setrakyan 
> wrote:
>
>> On Wed, Sep 30, 2015 at 10:18 AM, Alexey Goncharuk <
>> alexey.goncha...@gmail.com> wrote:
>>
>>> Given that encryption is enabled by setting SslContextFactory, I believe
>>> that SSL is the only option. I am +1 for changing the output.
>>>
>> I changed it and committed to master.
>>
>>
>>> 2015-09-30 10:21 GMT+03:00 Dmitriy Setrakyan :
>>>
 On Wed, Sep 30, 2015 at 8:01 AM, Sergey Kozlov 
 wrote:

> On Wed, Sep 30, 2015 at 4:51 AM, Dmitriy Setrakyan <
 dsetrak...@apache.org>
> wrote:
>
>> I got the following printout on 1.4 startup:
>> -
>> Security status [authentication=off, communication encryption=off]
>> -
>>
>> Do we mean SSL by "communication encryption"? If yes, shouldn't we
>>> just
> say
>> "ssl=off"?
>
>> D.
>>
> Yes, in that case communication encryption is SSL
>
 Do we have another case? If not, let's rename to "ssl", shorter and to
>>> the
 point. I think this can be done directly in the master. Any objections?

> --
> Sergey Kozlov
>

Re: JBPM and Drools integrations

[Dmitriy Setrakyan]

Invitation is sent and "drools-ignite" repository is created. Let me now if
you have troubles accessing it.

D.

On Wed, Sep 30, 2015 at 10:46 AM, Gianfranco Murador 
wrote:

> My github username is murador.
> Thank you.
>
> 2015-09-30 10:39 GMT+02:00 Dmitriy Setrakyan :
>
> > On Wed, Sep 30, 2015 at 10:13 AM, Gianfranco Murador  >
> > wrote:
> >
> > > Hello Igniters ,
> > > I take the discussion to understand if I have the proper approval from
> > the
> > > community
> > > for the early integration of Ignite with Drools and JBPM.
> > > I would ask if you can then create a new repository in
> > > https://github.com/apacheignite.
> > >
> >
> > Gianfranco, what is your github username, so I can invite you?
> >
> >
> > > Thanks,
> > > Regards, Gianfranco
> > >
> > >
> > > --
> > > Gianfranco Murador
> > > Igniter and Software Engineer.
> > >
> >
>
>
>
> --
> Gianfranco Murador
> Igniter and Software Engineer.
>

Re: Introducing "compatibility level" concept.

[Sergi Vladykin]

For me "compatibility level" looks like a complex and dangerous concept.

It really must be enough to have versioned protocol, when newer protocol
fully understands older ones. And there is no need to store the protocol
version
with each object, because it must be enough to send it on handshake
and store it to persistent storage metadata.

The only issue here is that we are trying to marshal messages only once
during a broadcast while with this approach we must make sure that
such a reuse of bytes happens only when protocol is the same for all nodes
or we must group receiver nodes by protocol version.

Sergi


2015-09-30 12:03 GMT+03:00 Yakov Zhdanov :

> >> 6) Node A restarts and meets unknown B-protocol.
>
> 6.1 Node A throws exception on start
> 6.2 Or node A invalidates persistent store (ignores the prev state)
> 6.3 Or user should have ability to specify converter somehow. Converter
> logic should be provided with release of new protocol (with more recent
> versions) so user can plug it in to older versions.
>
> Thoughts?
>
> --Yakov
>

Re: Introducing "compatibility level" concept.

[Yakov Zhdanov]

>> 6) Node A restarts and meets unknown B-protocol.

6.1 Node A throws exception on start
6.2 Or node A invalidates persistent store (ignores the prev state)
6.3 Or user should have ability to specify converter somehow. Converter
logic should be provided with release of new protocol (with more recent
versions) so user can plug it in to older versions.

Thoughts?

--Yakov

Re: Sergey Evdokimov Tickets

[chandresh pancholi]

Gian,
I would love to help you with IGNITE-417.

Let me know when and where to start.

Thanks

On Wed, Sep 30, 2015 at 2:30 PM, Dmitriy Setrakyan 
wrote:

> On Wed, Sep 30, 2015 at 10:18 AM, Gianfranco Murador 
> wrote:
>
> > Some ticket seem resolved , but the state has been left "open" . I like
> to
> > work on  IGNITE-417 and IGNITE-888 with the right help from community;
> >
>
> Gianfranco, I am not sure IGNITE-888 is a valid ticket. I personally do
> knot know what it means. Looks like Sergey E. was the one who filed the
> ticket. Does anyone know what this ticket is about?
>
> As far as IGNITE-417, I think this ticket might be valid, although there is
> no reproducible test. I would start from trying to reproduce it in a test
> (it might be that it has been fixed already in 1.4, in which case we should
> close the ticket)
>
> D.
>
>
> > 2015-09-30 9:42 GMT+02:00 Dmitriy Setrakyan :
> >
> > > On Wed, Sep 30, 2015 at 9:01 AM, Yakov Zhdanov 
> > > wrote:
> > >
> > > > Correct. I meant unassign.
> > > >
> > > > There are no critical tickets in my view -
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20%20status%20!%3D%20closed%20AND%20assignee%20%3D%20sevdokimov-gg%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > >
> > >
> > > I think that community should feel free to grab these tickets if they
> > have
> > > not had any activity for a while.
> > >
> > >
> > > >
> > > > --Yakov
> > > >
> > > > 2015-09-29 19:44 GMT+03:00 Dmitriy Setrakyan  >:
> > > >
> > > > > On Tue, Sep 29, 2015 at 4:45 PM, Yakov Zhdanov <
> yzhda...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Hi!
> > > > > >
> > > > > > I want to ask if Sergey is going to continue working on tickets
> > > > assigned
> > > > > to
> > > > > > him? If not, we will reassign them in 72 hours.
> > > > > >
> > > > >
> > > > > I thought you meant "un-assign" not "reassign". Do we know if there
> > are
> > > > any
> > > > > critical tickets that Sergey was working on?
> > > > >
> > > > >
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > --Yakov
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Gianfranco Murador
> > Igniter and Software Engineer.
> >
>



-- 
Chandresh Pancholi
Senior Software Engineer
Flipkart.com
Email-id:chandresh.panch...@flipkart.com
Contact:08951803660

[jira] [Created] (IGNITE-1585) Test failed - TcpDiscoveryCloudIpFinderSelfTest.testGoogleComputeEngine

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-1585:


 Summary: Test failed - 
TcpDiscoveryCloudIpFinderSelfTest.testGoogleComputeEngine
 Key: IGNITE-1585
 URL: https://issues.apache.org/jira/browse/IGNITE-1585
 Project: Ignite
  Issue Type: Bug
Reporter: Anton Vinogradov


org.apache.ignite.spi.IgniteSpiException: Failed to get registered addresses 
for the provider: google-compute-engine
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:229)
at 
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.checkGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:124)
at 
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.sharedNameForGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:120)
at 
org.jclouds.googlecomputeengine.compute.functions.FirewallTagNamingConvention$Factory.get(FirewallTagNamingConvention.java:39)
at 
org.jclouds.googlecomputeengine.compute.functions.InstanceToNodeMetadata.apply(InstanceToNodeMetadata.java:68)
at 
org.jclouds.googlecomputeengine.compute.functions.InstanceToNodeMetadata.apply(InstanceToNodeMetadata.java:43)
at 
com.google.common.base.Functions$FunctionComposition.apply(Functions.java:211)
at com.google.common.collect.Iterators$8.transform(Iterators.java:794)
at 
com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at com.google.common.collect.Iterators$7.computeNext(Iterators.java:646)
at 
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at 
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at com.google.common.collect.Iterators.addAll(Iterators.java:356)
at com.google.common.collect.Iterables.addAll(Iterables.java:350)
at com.google.common.collect.Sets.newLinkedHashSet(Sets.java:328)
at 
org.jclouds.compute.internal.BaseComputeService.listNodesDetailsMatching(BaseComputeService.java:359)
at 
org.apache.ignite.spi.discovery.tcp.ipfinder.cloud.TcpDiscoveryCloudIpFinder.getRegisteredAddresses(TcpDiscoveryCloudIpFinder.java:190)
at 
org.apache.ignite.spi.discovery.tcp.ipfinder.cloud.TcpDiscoveryCloudIpFinderSelfTest.testCloudProvider(TcpDiscoveryCloudIpFinderSelfTest.java:106)
at 
org.apache.ignite.spi.discovery.tcp.ipfinder.cloud.TcpDiscoveryCloudIpFinderSelfTest.testGoogleComputeEngine(TcpDiscoveryCloudIpFinderSelfTest.java:71)
--- Stdout: ---
Configured log4j from: 
/opt/TeamcityAgent/work/871ff4a46e450b13/modules/core/src/test/config/log4j-test.xml
[14:19:49,901][INFO ][main][root] >>> Starting test class: 
TcpDiscoveryCloudIpFinderSelfTest <<<
[14:19:49,944][INFO ][main][root] >>> Starting test: testGoogleComputeEngine <<<
[14:19:49,945][INFO ][test-runner][root] Testing provider: google-compute-engine
[14:19:52,312][INFO ][main][root] >>> Stopping test: testGoogleComputeEngine in 
2367 ms <<<
--- Stderr: ---
[14:19:52,310][ERROR][main][root] Test failed.
class org.apache.ignite.spi.IgniteSpiException: Failed to get registered 
addresses for the provider: google-compute-engine
at 
org.apache.ignite.spi.discovery.tcp.ipfinder.cloud.TcpDiscoveryCloudIpFinder.getRegisteredAddresses(TcpDiscoveryCloudIpFinder.java:210)
at 
org.apache.ignite.spi.discovery.tcp.ipfinder.cloud.TcpDiscoveryCloudIpFinderSelfTest.testCloudProvider(TcpDiscoveryCloudIpFinderSelfTest.java:106)
at 
org.apache.ignite.spi.discovery.tcp.ipfinder.cloud.TcpDiscoveryCloudIpFinderSelfTest.testGoogleComputeEngine(TcpDiscoveryCloudIpFinderSelfTest.java:71)
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:1665)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:111)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:1603)
Caused by: java.lang.NullPointerException: group
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:229)
at 
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.checkGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:124)
at 
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.sharedNameForGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:120)
at 

Re: LGPL in 1.4 examples

[Dmitriy Setrakyan]

On Wed, Sep 30, 2015 at 10:49 AM, Branko Čibej  wrote:

> On 30.09.2015 10:30, Dmitriy Setrakyan wrote:
> > On Wed, Sep 30, 2015 at 9:45 AM, Branko Čibej  wrote:
> >
> >> On 30.09.2015 09:29, Dmitriy Setrakyan wrote:
> >>> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov 
> >> wrote:
>  I filed the ticket:
>  Build examples failed from binary fabric package
>  
> 
> >>> I think the reason is that we do not upload Ignite LGPL integrations,
> >> e.g.
> >>> ignite-hiberbnate artifact to maven central. I don't see why we do not,
> >>> because even though they depend on some LGPL-based code, the ignite
> >> module
> >>> itself is licensed under ASL.
> >>>
> >>> Can we upload these artifacts manually?
> >> We've been through this any number of times, yes? We cannot distribute
> >> (L)GPL dependencies. If you can't run a reasonable grid that doesn't
> >> depend on LGPL-licensed modules, then those modules are not "optional"
> >> by any reasonable definition.
> >>
> >> It's quite all right to have examples that require those modules; just
> >> tell users that if they want to run those examples, they'll have to
> >> build Ignite (or at least the LGPL dependencies) themselves.
> >>
> >
> > Hm... I thought that ignite-hibernate module could still be published to
> > Maven because the module itself is licensed under ASL2.0 license.
>
> People keep misunderstanding the LGPL. You really should read it. The
> "module itself" cannot be licensed under ALv2. For example, this is
> LGPL2.1 section 5 paragraph 2:
>
> However, linking a "work that uses the Library" with the Library
> creates an executable that is a derivative of the Library (because
> it contains portions of the Library), rather than a "work that uses
> the library". The executable is therefore covered by this License.
> Section 6 states terms for distribution of such executables.
>
>
> In other words, as soon as you *build* something that is linked with
> LGPL, it's covered by the LGPL. The sources of the module can be ALv2,
> but the built module isn't.
>

Got it. Thanks for the clarification!


>
> This is why ASF policy forbids mandatory (L)GPL dependencies and
> absolutely forbids releases containing (L)GPL code. And whilst the
> binaries we put on Maven aren't "releases", they must follow these
> policies.
>
> > If not, then we should not include these modules into the main set of
> > examples, primarily because there is no way for a user to build them out
> of
> > the box.
> >
> > I see 2 solutions:
> >
> > 1. Remove modules that depend on LGPL from the examples altogether.
> > 2. Add a separate LGPL folder in examples, which will not be included
> into
> > the POM file with a special README explaining how to build them.
>
>
> Option 2 is acceptable.
>
> -- Brane
>
>

[jira] [Created] (IGNITE-1581) Synchronous cache operation can deadlock on async semaphore.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1581:
---

 Summary: Synchronous cache operation can deadlock on async 
semaphore.
 Key: IGNITE-1581
 URL: https://issues.apache.org/jira/browse/IGNITE-1581
 Project: Ignite
  Issue Type: Task
  Components: cache
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Priority: Critical
 Fix For: ignite-1.5


Problem can be reproduced as follows:
1) Set CacheConfiguration.setMaxConcurrentAsyncOperations() to a very small 
value, e.g. 3.
2) T1: Start PESSIMISTIC/REPEATABLE_READ tx and call Cache.get(1);
3) Start 3 other threads, initiate PESSIMISTIC/REPEATABLE_READ tx and call 
Cache.get(1) on them. They will stuck as expected.
4) T1: Call Cache.get(1) again. Instead of getting already locked value, thread 
is stuck on async semaphore acquire:

{code}
at sun.misc.Unsafe.park(Unsafe.java:-1)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
  at java.util.concurrent.Semaphore.acquire(Semaphore.java:317)
  at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOpAcquire(GridCacheAdapter.java:4329)
  at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4203)
  at 
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAllAsync(GridDhtColocatedCache.java:211)
  at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAllAsync(GridCacheAdapter.java:4609)
  at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4556)
  at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1569)
{code}



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

Re: what is "communication encryption"?

[Dmitriy Setrakyan]

On Wed, Sep 30, 2015 at 12:18 PM, Branko Čibej  wrote:

> On 30.09.2015 11:18, Nikolay Tikhonov wrote:
> > SslContextFactory allows to set different encryption protocols (by
> default
> > TLS). I think that just "ssl" confuses users. Might be "ssl\tls=off" more
> > acceptable?
>
> SSL is one (rather old) specification of Transport Layer Security (TLS).
> These days, you shouldn't be using any version of the SSL protocol; they
> all have unfixable security holes.
>
> To be moderately safe, you should implement TLS v1.2 with fallback
> allowed to TLS v1.0 but not lower. Even then, certificates should use at
> least SHA256, preferably SHA512; SHA1 is no longer considered secure. I
> don't recall offhand which ciphers are considered secure, but there
> aren't very many of them.
>
>
Agree. Ignite currently supports TLS. Does anyone know which version of TLS
we support?

Re: JBPM and Drools integrations

[Gianfranco Murador]

Dmitriy,
 I get this error  *Permission to apacheignite/drools-ignite.git denied* ,
when I push on this repo : https://github.com/apacheignite/drools-ignite.
Maybe you need to add write permissions to my user.
Thanks

2015-09-30 11:05 GMT+02:00 Dmitriy Setrakyan :

> Invitation is sent and "drools-ignite" repository is created. Let me now if
> you have troubles accessing it.
>
> D.
>
> On Wed, Sep 30, 2015 at 10:46 AM, Gianfranco Murador 
> wrote:
>
> > My github username is murador.
> > Thank you.
> >
> > 2015-09-30 10:39 GMT+02:00 Dmitriy Setrakyan :
> >
> > > On Wed, Sep 30, 2015 at 10:13 AM, Gianfranco Murador <
> mura...@apache.org
> > >
> > > wrote:
> > >
> > > > Hello Igniters ,
> > > > I take the discussion to understand if I have the proper approval
> from
> > > the
> > > > community
> > > > for the early integration of Ignite with Drools and JBPM.
> > > > I would ask if you can then create a new repository in
> > > > https://github.com/apacheignite.
> > > >
> > >
> > > Gianfranco, what is your github username, so I can invite you?
> > >
> > >
> > > > Thanks,
> > > > Regards, Gianfranco
> > > >
> > > >
> > > > --
> > > > Gianfranco Murador
> > > > Igniter and Software Engineer.
> > > >
> > >
> >
> >
> >
> > --
> > Gianfranco Murador
> > Igniter and Software Engineer.
> >
>



-- 
Gianfranco Murador
Igniter and Software Engineer.

[jira] [Created] (IGNITE-1596) Web console agent improvements

[Dmitriy Setrakyan (JIRA)]

Dmitriy Setrakyan created IGNITE-1596:
-

 Summary: Web console agent improvements
 Key: IGNITE-1596
 URL: https://issues.apache.org/jira/browse/IGNITE-1596
 Project: Ignite
  Issue Type: Sub-task
  Components: UI
Reporter: Dmitriy Setrakyan
 Fix For: 1.5


* Help message should state if the parameter is optional. Ideally default 
values should be provided on the next line.
* Default value for config-path should be provided. Text should say: Path to 
agent property file
* When start (with or without parameters), agent should print out values for 
all the configuration settings.
* We should have a suggestion saying: To start web-agent in test-drive mode, 
pass "-tm" and "-ts" parameters
* Before prompting for token, agent should say: 
Security token is required to establish connection to the web console. 
It is available on the Profile page: http://console.gridgain.com/profile
Enter security token:




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

[GitHub] ignite pull request: IGNITE-1580: const qualifiers removed for boo...

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-1580: const qualifiers removed for bool arguments



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

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

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

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


commit ad217b358e7fe48cd06a746a8a47379cca4669ed
Author: isapego 
Date:   2015-09-30T13:51:01Z

IGNITE-1580: const qualifiers removed for bool arguments




---
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: [RESULT] [VOTE] Apache Ignite 1.4.0 Release (RC1)

[Konstantin Boudnik]

Was the announcement send already and I missed it? If not - please do.

Thanks!
  Cos

On Mon, Sep 28, 2015 at 07:20PM, Anton Vinogradov wrote:
> Site updated.
> 
> On Mon, Sep 28, 2015 at 5:09 PM, Anton Vinogradov 
> wrote:
> 
> > Ignite 1.4.0 successfuly released to
> > https://dist.apache.org/repos/dist/release/ignite/1.4.0/
> > Site will be updated soon.
> >
> > On Mon, Sep 28, 2015 at 4:13 PM, Yakov Zhdanov 
> > wrote:
> >
> >> Hello!
> >>
> >> Apache Ignite 1.4.0 release (RC1) has been accepted.
> >>
> >> 9 "+1" votes received.
> >>
> >> Here are the votes received:
> >>
> >>- Denis Magda (binding)
> >>- Anton Vinogradov (binding)
> >>- Alexey Kuznetsov (binding)
> >>- Sergi Vladykin (binding)
> >>- Gianfranco Murador (binding)
> >>- Vladimir Ozerov (binding)
> >>- Raul Kripalani (binding)
> >>- Konstantin Boudnik (binding)
> >>- chandresh pancholi
> >>
> >> Here is the link to vote thread -
> >>
> >> http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Apache-Ignite-1-4-0-Release-RC1-tp3474.html
> >>
> >> Thanks!
> >>
> >> --Yakov
> >>
> >
> >

[jira] [Created] (IGNITE-1588) CPP: Fix constructor of the IgniteJvmOption class

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-1588:
---

 Summary: CPP: Fix constructor of the IgniteJvmOption class
 Key: IGNITE-1588
 URL: https://issues.apache.org/jira/browse/IGNITE-1588
 Project: Ignite
  Issue Type: Task
Reporter: Igor Sapego
Assignee: Igor Sapego


Current implementation of the IgniteJvmOption class takes {{char*}} as 
argument, when it should take {{const char*}} and copy it.



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

[jira] [Created] (IGNITE-1586) CPP: Add isValid() method to all proxy-like classes

[Igor (JIRA)]

Igor created IGNITE-1586:


 Summary: CPP: Add isValid() method to all proxy-like classes
 Key: IGNITE-1586
 URL: https://issues.apache.org/jira/browse/IGNITE-1586
 Project: Ignite
  Issue Type: Task
Reporter: Igor
Assignee: Igor


Need to add isValid() methods to proxy-like classes so users can check if they 
can use an instance.



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

[jira] [Created] (IGNITE-1587) [Test Failed] Timeouted IgniteCacheAtomicNodeRestartTest.* at TC Windows agents

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-1587:


 Summary: [Test Failed] Timeouted 
IgniteCacheAtomicNodeRestartTest.* at TC Windows agents
 Key: IGNITE-1587
 URL: https://issues.apache.org/jira/browse/IGNITE-1587
 Project: Ignite
  Issue Type: Test
Affects Versions: ignite-1.5
Reporter: Anton Vinogradov
Priority: Blocker
 Fix For: ignite-1.5






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

[jira] [Created] (IGNITE-1589) Platform .Net: CacheAbstractTest.TestPutGetAsyncMultithreaded fails

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1589:
---

 Summary: Platform .Net: 
CacheAbstractTest.TestPutGetAsyncMultithreaded fails
 Key: IGNITE-1589
 URL: https://issues.apache.org/jira/browse/IGNITE-1589
 Project: Ignite
  Issue Type: Sub-task
  Components: interop
Affects Versions: ignite-1.5
Reporter: Pavel  Tupitsyn
Assignee: Pavel  Tupitsyn
 Fix For: ignite-1.5






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

Re: Sergey Evdokimov Tickets

[Gianfranco Murador]

Chandresh , Thank you, any help is welcome.
We update as soon we can replicate the issue


2015-09-30 11:25 GMT+02:00 chandresh pancholi <
chandreshpancholi...@gmail.com>:

> Gian,
> I would love to help you with IGNITE-417.
>
> Let me know when and where to start.
>
> Thanks
>
> On Wed, Sep 30, 2015 at 2:30 PM, Dmitriy Setrakyan 
> wrote:
>
> > On Wed, Sep 30, 2015 at 10:18 AM, Gianfranco Murador  >
> > wrote:
> >
> > > Some ticket seem resolved , but the state has been left "open" . I like
> > to
> > > work on  IGNITE-417 and IGNITE-888 with the right help from community;
> > >
> >
> > Gianfranco, I am not sure IGNITE-888 is a valid ticket. I personally do
> > knot know what it means. Looks like Sergey E. was the one who filed the
> > ticket. Does anyone know what this ticket is about?
> >
> > As far as IGNITE-417, I think this ticket might be valid, although there
> is
> > no reproducible test. I would start from trying to reproduce it in a test
> > (it might be that it has been fixed already in 1.4, in which case we
> should
> > close the ticket)
> >
> > D.
> >
> >
> > > 2015-09-30 9:42 GMT+02:00 Dmitriy Setrakyan :
> > >
> > > > On Wed, Sep 30, 2015 at 9:01 AM, Yakov Zhdanov 
> > > > wrote:
> > > >
> > > > > Correct. I meant unassign.
> > > > >
> > > > > There are no critical tickets in my view -
> > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20%20status%20!%3D%20closed%20AND%20assignee%20%3D%20sevdokimov-gg%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > > >
> > > >
> > > > I think that community should feel free to grab these tickets if they
> > > have
> > > > not had any activity for a while.
> > > >
> > > >
> > > > >
> > > > > --Yakov
> > > > >
> > > > > 2015-09-29 19:44 GMT+03:00 Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >:
> > > > >
> > > > > > On Tue, Sep 29, 2015 at 4:45 PM, Yakov Zhdanov <
> > yzhda...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi!
> > > > > > >
> > > > > > > I want to ask if Sergey is going to continue working on tickets
> > > > > assigned
> > > > > > to
> > > > > > > him? If not, we will reassign them in 72 hours.
> > > > > > >
> > > > > >
> > > > > > I thought you meant "un-assign" not "reassign". Do we know if
> there
> > > are
> > > > > any
> > > > > > critical tickets that Sergey was working on?
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > --Yakov
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Gianfranco Murador
> > > Igniter and Software Engineer.
> > >
> >
>
>
>
> --
> Chandresh Pancholi
> Senior Software Engineer
> Flipkart.com
> Email-id:chandresh.panch...@flipkart.com
> Contact:08951803660
>



-- 
Gianfranco Murador
Igniter and Software Engineer.

[GitHub] ignite pull request: IGNITE-1588: Fix for the IgniteJvmOption clas...

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-1588: Fix for the IgniteJvmOption class



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

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

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

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


commit 374ed5277d030cd28afdf0647769757ce3d1d9b1
Author: isapego 
Date:   2015-09-30T15:41:35Z

IGNITE-1588: Fix for the IgniteJvmOption class

commit ea795e7cabad83feb2f1a3518e9547c0f560dfa2
Author: isapego 
Date:   2015-09-30T15:48:49Z

Fix for indentation




---
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-1592) [Test Failed] GridCachePartitionedOffHeapValuesQueueApiSelfTest.testQueueRemoveMultithreadBounded

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-1592:


 Summary: [Test Failed] 
GridCachePartitionedOffHeapValuesQueueApiSelfTest.testQueueRemoveMultithreadBounded
 Key: IGNITE-1592
 URL: https://issues.apache.org/jira/browse/IGNITE-1592
 Project: Ignite
  Issue Type: Test
Affects Versions: ignite-1.5
Reporter: Anton Vinogradov
Priority: Blocker
 Fix For: ignite-1.5


java.lang.AssertionError: null
at 
org.apache.ignite.internal.processors.cache.datastructures.GridCacheQueueApiSelfAbstractTest.testQueueRemoveMultithreadBounded(GridCacheQueueApiSelfAbstractTest.java:443)
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:1665)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:111)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:1603)
--- Stdout: ---
[11:59:42,194][INFO ][main][root] >>> Starting test: 
testQueueRemoveMultithreadBounded <<<
[12:02:42,196][INFO ][main][root] >>> Stopping test: 
testQueueRemoveMultithreadBounded in 180002 ms <<<
--- Stderr: ---
[12:02:42,195][ERROR][main][root] Test failed.
java.lang.AssertionError
at 
org.apache.ignite.internal.processors.cache.datastructures.GridCacheQueueApiSelfAbstractTest.testQueueRemoveMultithreadBounded(GridCacheQueueApiSelfAbstractTest.java:443)
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:1665)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:111)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:1603)



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

[jira] [Created] (IGNITE-1590) IGFS: update & create operations should be truly thread-safe.

[Ivan Veselovsky (JIRA)]

Ivan Veselovsky created IGNITE-1590:
---

 Summary: IGFS: update & create operations should be truly 
thread-safe.
 Key: IGNITE-1590
 URL: https://issues.apache.org/jira/browse/IGNITE-1590
 Project: Ignite
  Issue Type: Bug
Affects Versions: ignite-1.4
Reporter: Ivan Veselovsky
Assignee: Ivan Veselovsky
 Fix For: ignite-1.5


Fix #create() operation & revise #update().
Currently the tests with many concurrent operations (involving  
delete/rename/nkdirs/create) reveal concurrency problems -- some tree entries 
get "lost".



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