Re: [VOTE] Establishing duration of Apache Ignite Chair rotation

[Anton Vinogradov]

+1 (binding)

On Wed, Oct 14, 2015 at 4:47 PM, Gianfranco Murador 
wrote:

> +1 (binding)
>
> 2015-10-14 15:46 GMT+02:00 Yakov Zhdanov :
>
> > +1 (binding)
> >
> > --Yakov
> >
> > 2015-10-14 1:30 GMT+03:00 Konstantin Boudnik :
> >
> > > Hi!
> > >
> > > As discussed in the "[DISCUSS] PMC Chair rotation" thread last month, I
> > > propose
> > > that we adopt a rule allowing for a Apache Ignite Chair rotation on a
> > > yearly
> > > basis. The proposed policy is this:
> > >   - a position of an Apache Ignite Chair gets elected for a year
> > >   - after a year passes it is expected of the active Chair to start a
> > > [DISCUSS] email thread on priv...@ignite.apache.org asking PMC
> > > members to
> > > make a nomination for the next year
> > >   - it is perfectly acceptable for the active chair to nominate him or
> > > herself
> > >   - there is no limit on the number of terms that one person can serve
> as
> > > an
> > > Apache Ignite Chair.
> > >
> > > Each term, however is exactly one year.
> > >
> > >   [ ] +1 Adopt the Apache Ingite Chair rotation policy
> > >   [ ] +0
> > >   [ ] -1 Do not adopt the proposed policy (please provide a reason)
> > >
> > > This VOTE will be held open for at least 72 hours.
> > >
> > > Thanks,
> > >   Cos
> > >
> >
>
>
>
> --
> Gianfranco Murador
> Igniter and Software Engineer.
>

[GitHub] ignite pull request: IGNITE-1641 .Net: Get rid of ContinuousQueryF...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1641 .Net: Get rid of ContinuousQueryFilterHolder



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

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

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

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


commit 30bc496a7d9f9e0aeac6810ef120d019756bdcbe
Author: ptupitsyn 
Date:   2015-10-14T10:38:16Z

wip .Net

commit 37ea69dcaef86d2aae10d2ba031d796c6c5efe36
Author: ptupitsyn 
Date:   2015-10-14T10:47:39Z

wip

commit 8e470aa4743da70d0779cd4a442d13498c69e230
Author: ptupitsyn 
Date:   2015-10-14T14:16:53Z

Propagating keepPortable in Java

commit c8f8a5cf95d950a34405916cbfa40a22364ae5aa
Author: ptupitsyn 
Date:   2015-10-14T14:27:47Z

fixing tests

commit b88700bd1758465438747cf38249a79b069195d9
Author: ptupitsyn 
Date:   2015-10-14T14:46:16Z

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

[jira] [Created] (IGNITE-1685) BrokenBarrierException in test o.a.i.i.processors.cache.distributed.IgniteCacheClientNodeChangingTopologyTest.testAtomicClockPutAllMultinode

[Ivan Veselovsky (JIRA)]

Ivan Veselovsky created IGNITE-1685:
---

 Summary: BrokenBarrierException in test 
o.a.i.i.processors.cache.distributed.IgniteCacheClientNodeChangingTopologyTest.testAtomicClockPutAllMultinode
 Key: IGNITE-1685
 URL: https://issues.apache.org/jira/browse/IGNITE-1685
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Veselovsky


BrokenBarrierException followed by a hang up observed in build 
http://94.72.60.102/viewLog.html?buildId=551330=Ignite_IgniteCache2=buildLog

[16:48:10]W: [org.apache.ignite:ignite-core] 
java.util.concurrent.BrokenBarrierException
[16:48:10]W: [org.apache.ignite:ignite-core]at 
java.util.concurrent.CyclicBarrier.dowait(CyclicBarrier.java:243)
[16:48:10]W: [org.apache.ignite:ignite-core]at 
java.util.concurrent.CyclicBarrier.await(CyclicBarrier.java:355)
[16:48:10]W: [org.apache.ignite:ignite-core]at 
org.apache.ignite.internal.processors.cache.distributed.IgniteCacheClientNodeChangingTopologyTest$14.call(IgniteCacheClientNodeChangingTopologyTest.java:1553)



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

[jira] [Created] (IGNITE-1673) We need to show more clear and human readable message in case when no grid available

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1673:
--

 Summary: We need to show more clear and human readable message in 
case when no grid available 
 Key: IGNITE-1673
 URL: https://issues.apache.org/jira/browse/IGNITE-1673
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Andrey Novikov


1) Open SQL in Console (no agent started yet)
2) Start agent with default settings but do not start grid

Observed: the message "Connect to localhost:8080" is appears again and again. 



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

[GitHub] ignite pull request: IGNITE-1664 .Net: Review generic type argumen...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1664 .Net: Review generic type arguments in the API



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

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

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

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


commit 39e436fcb0c123bb0a8bed5f7b281ef6c47a2385
Author: ptupitsyn 
Date:   2015-10-13T14:26:37Z

IGNITE-1664 .Net: Review generic type arguments in the API

commit d5c480d11ec3526453ca05d17326f48001962cff
Author: ptupitsyn 
Date:   2015-10-13T15:31:20Z

wip

commit 553aacceaa5df2362c2ead2befa67515e2e288eb
Author: ptupitsyn 
Date:   2015-10-13T15:49:49Z

wip

commit 13732fd5fc1255771e66a956a8edce126a411827
Author: ptupitsyn 
Date:   2015-10-13T15:52:49Z

Fix cache invoke

commit 0ac485fbd13266b8c4ce47db0684d4ed26780892
Author: ptupitsyn 
Date:   2015-10-13T15:57:00Z

wip

commit 5af411cc0df9bd5d8f1fc2d799d37e1f5a94a9be
Author: ptupitsyn 
Date:   2015-10-13T16:03:15Z

wip

commit 5304b0e9348ed707ed74e5216b6c10bd08847bc7
Author: ptupitsyn 
Date:   2015-10-14T08:46:24Z

wip

commit d447aaeb329584a031d47ff4e18cf03844777d86
Author: ptupitsyn 
Date:   2015-10-14T08:55:16Z

wip

commit 5798ecf27329011fcaa7b4e0d9fc303ba0f6173b
Author: ptupitsyn 
Date:   2015-10-14T09:05:07Z

wip

commit eea73f779e93dbad859a75d50d836ba7b4a312c3
Author: ptupitsyn 
Date:   2015-10-14T09:10:39Z

wip




---
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-1674) Incorrect UI state of Load metadata dialog

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1674:
--

 Summary: Incorrect UI state of Load metadata dialog
 Key: IGNITE-1674
 URL: https://issues.apache.org/jira/browse/IGNITE-1674
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Vasiliy Sisko


Set incorrect filter value



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

Re: [VOTE] Establishing duration of Apache Ignite Chair rotation

[Sergi Vladykin]

+1 (binding)

Sergi

2015-10-14 10:28 GMT+03:00 Raul Kripalani :

> +1 (binding)
> On 13 Oct 2015 23:27, "Konstantin Boudnik"  wrote:
>
> > Hi!
> >
> > As discussed in the "[DISCUSS] PMC Chair rotation" thread last month, I
> > propose
> > that we adopt a rule allowing for a Apache Ignite Chair rotation on a
> > yearly
> > basis. The proposed policy is this:
> >   - a position of an Apache Ignite Chair gets elected for a year
> >   - after a year passes it is expected of the active Chair to start a
> > [DISCUSS] email thread on priv...@ignite.apache.org asking PMC
> > members to
> > make a nomination for the next year
> >   - it is perfectly acceptable for the active chair to nominate him or
> > herself
> >   - there is no limit on the number of terms that one person can serve as
> > an
> > Apache Ignite Chair.
> >
> > Each term, however is exactly one year.
> >
> >   [ ] +1 Adopt the Apache Ingite Chair rotation policy
> >   [ ] +0
> >   [ ] -1 Do not adopt the proposed policy (please provide a reason)
> >
> > This VOTE will be held open for at least 72 hours.
> >
> > Thanks,
> >   Cos
> >
>

[jira] [Created] (IGNITE-1677) .Net: Sign assemblies and store SNK file in git

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1677:
---

 Summary: .Net: Sign assemblies and store SNK file in git
 Key: IGNITE-1677
 URL: https://issues.apache.org/jira/browse/IGNITE-1677
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: ignite-1.4
Reporter: Pavel  Tupitsyn
Assignee: Pavel  Tupitsyn
 Fix For: 1.5


Currently there is no strong name signing, so anyone who wants to reference 
Ignite.NET in their signed assembly will have to modify our sources and build 
them.

Providing snk file as part of the open source project is a standard practice 
(see log4net 
https://svn.apache.org/repos/asf/logging/log4net/trunk/log4net.snk.readme).

Public strong name, of course, does not provide any means of authenticity 
checking, but makes development easier.

Authenticity can be ensured by downloading Apache Ignite release from official 
download page and verifying check sums.



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

Storing .NET assembly strong name key file (.snk) in git

[Pavel Tupitsyn]

Igniters,

We are going to enable assembly signing for Ignite.NET.

(Unsigned assemblies can't be referenced from signed assemblies, so clients
will have to enable signing and build from sources otherwise).

This requires storing binary .snk file in git.
For example, Apache log4net does this, and describes the situation in
detail:
https://svn.apache.org/repos/asf/logging/log4net/trunk/log4net.snk.readme

Thoughts, objections?

-- 
-- 
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com

[jira] [Created] (IGNITE-1678) IgniteAtomicSequence: make additional reservations in advance

[Denis Magda (JIRA)]

Denis Magda created IGNITE-1678:
---

 Summary: IgniteAtomicSequence: make additional reservations in 
advance
 Key: IGNITE-1678
 URL: https://issues.apache.org/jira/browse/IGNITE-1678
 Project: Ignite
  Issue Type: Improvement
  Components: data structures
Affects Versions: ignite-1.4
Reporter: Denis Magda


In current implementation a new reservation is made when the current local 
sequence boundary is exceeded.

In cases when there are many nodes that use the same atomic sequence there can 
be a situation when all the nodes start doing a new reservation at the same 
time. This can lead to performance drops.

As a performance optimization it makes sense to start reserving new sequence 
slot in advance (in background), like when around 80% of current reservation 
has already been used. Probably we should add a special parameter to 
{{AtomicConfiguration}} that will manage such behavior.



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

[jira] [Created] (IGNITE-1676) Agent cannot detect JDBC Driver class if path to jdbc-drivers folder is relative from agent home folder.

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1676:
--

 Summary: Agent cannot detect JDBC Driver class  if path to 
jdbc-drivers folder is relative from agent home folder.
 Key: IGNITE-1676
 URL: https://issues.apache.org/jira/browse/IGNITE-1676
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov


{code}
[17:21:54,377][INFO][pool-2-thread-2][DatabaseMetadataExtractor] Found: 
[driver=db2jcc4.jar]
[17:21:54,378][INFO][pool-2-thread-2][DatabaseMetadataExtractor] Failed to 
detect driver class: \.\jdbc-drivers\db2jcc4.jar (╤шёЄхьх эх єфрхЄё  эрщЄш 
єърчрээ√щ яєЄ№)
[17:21:54,378][INFO][pool-2-thread-2][DatabaseMetadataExtractor] Found: 
[driver=h2-1.3.175.jar]
[17:21:54,379][INFO][pool-2-thread-2][DatabaseMetadataExtractor] Failed to 
detect driver class: \.\jdbc-drivers\h2-1.3.175.jar (╤шёЄхьх эх єфрхЄё  эрщЄш 
єърчрээ√щ яєЄ№)
[17:21:54,379][INFO][pool-2-thread-2][DatabaseMetadataExtractor] Found: 
[driver=ojdbc6.jar]
[17:21:54,380][INFO][pool-2-thread-2][DatabaseMetadataExtractor] Failed to 
detect driver class: \.\jdbc-drivers\ojdbc6.jar (╤шёЄхьх эх єфрхЄё  эрщЄш 
єърчрээ√щ яєЄ№)
{code}



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

Re: [VOTE] Establishing duration of Apache Ignite Chair rotation

[Yakov Zhdanov]

+1 (binding)

--Yakov

2015-10-14 1:30 GMT+03:00 Konstantin Boudnik :

> Hi!
>
> As discussed in the "[DISCUSS] PMC Chair rotation" thread last month, I
> propose
> that we adopt a rule allowing for a Apache Ignite Chair rotation on a
> yearly
> basis. The proposed policy is this:
>   - a position of an Apache Ignite Chair gets elected for a year
>   - after a year passes it is expected of the active Chair to start a
> [DISCUSS] email thread on priv...@ignite.apache.org asking PMC
> members to
> make a nomination for the next year
>   - it is perfectly acceptable for the active chair to nominate him or
> herself
>   - there is no limit on the number of terms that one person can serve as
> an
> Apache Ignite Chair.
>
> Each term, however is exactly one year.
>
>   [ ] +1 Adopt the Apache Ingite Chair rotation policy
>   [ ] +0
>   [ ] -1 Do not adopt the proposed policy (please provide a reason)
>
> This VOTE will be held open for at least 72 hours.
>
> Thanks,
>   Cos
>

Re: [VOTE] Establishing duration of Apache Ignite Chair rotation

[Gianfranco Murador]

+1 (binding)

2015-10-14 15:46 GMT+02:00 Yakov Zhdanov :

> +1 (binding)
>
> --Yakov
>
> 2015-10-14 1:30 GMT+03:00 Konstantin Boudnik :
>
> > Hi!
> >
> > As discussed in the "[DISCUSS] PMC Chair rotation" thread last month, I
> > propose
> > that we adopt a rule allowing for a Apache Ignite Chair rotation on a
> > yearly
> > basis. The proposed policy is this:
> >   - a position of an Apache Ignite Chair gets elected for a year
> >   - after a year passes it is expected of the active Chair to start a
> > [DISCUSS] email thread on priv...@ignite.apache.org asking PMC
> > members to
> > make a nomination for the next year
> >   - it is perfectly acceptable for the active chair to nominate him or
> > herself
> >   - there is no limit on the number of terms that one person can serve as
> > an
> > Apache Ignite Chair.
> >
> > Each term, however is exactly one year.
> >
> >   [ ] +1 Adopt the Apache Ingite Chair rotation policy
> >   [ ] +0
> >   [ ] -1 Do not adopt the proposed policy (please provide a reason)
> >
> > This VOTE will be held open for at least 72 hours.
> >
> > Thanks,
> >   Cos
> >
>



-- 
Gianfranco Murador
Igniter and Software Engineer.

A Future with intermediate progress?

[Ivan Veselovskiy]

IgniteFuture is an interface to pass the control upon an action completion.
But the action can be long running, and may have some intermediate
completion stages, e.g. data loading action progress can be measured as
loaded data percentage.
May it make sense to have an IgniteFuture subclass like
IgniteProgressableFuture with method #getProgress() : double ?

[jira] [Created] (IGNITE-1686) Autoscrolling to the newly created query

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1686:
--

 Summary: Autoscrolling to the newly created query
 Key: IGNITE-1686
 URL: https://issues.apache.org/jira/browse/IGNITE-1686
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov


Currently user must scroll the page manually.



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

[jira] [Created] (IGNITE-1688) Add possibility to insert fully qualified name to the query from metadata popup

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1688:
--

 Summary: Add possibility to insert fully qualified name to the 
query from metadata popup 
 Key: IGNITE-1688
 URL: https://issues.apache.org/jira/browse/IGNITE-1688
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov


Such possibility will help user to construct cross-cache queries.



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

[jira] [Created] (IGNITE-1687) Add possibility to insert fully qualified name to the query from metadata popup

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-1687:
--

 Summary: Add possibility to insert fully qualified name to the 
query from metadata popup 
 Key: IGNITE-1687
 URL: https://issues.apache.org/jira/browse/IGNITE-1687
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov


Such possibility will help user to construct cross-cache queries.



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

Re: IgniteEvents.remoteListen() semantics

[Yakov Zhdanov]

It uses similar approach as continuous query - remoteFiltering and
localListener notification.

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

2015-10-14 16:45 GMT+03:00 Vladimir Ozerov :

> Yakov, I'm not sure whether there are any problems or not. This is why I
> wanted to understand what was the initial idea behind remoteListen() API
> before creating the ticket.
>
> On Wed, Oct 14, 2015 at 4:37 PM, Yakov Zhdanov 
> wrote:
>
> > Pavel, this is source node ID which is already in the event, as you
> > mentioned. Vladimir, can you please file a ticket?
> >
> > --Yakov
> >
> > 2015-10-13 14:11 GMT+03:00 Pavel Tupitsyn :
> >
> > > Related question:
> > >
> > > What does first UUID arg mean in "IgniteBiPredicate locLsnr"?
> > > It can either be event source node id, which is already included in
> Event
> > > interface, or local node id, which does not make much sense.
> > >
> > > On Tue, Oct 13, 2015 at 1:57 PM, Vladimir Ozerov  >
> > > wrote:
> > >
> > > > Igniters,
> > > >
> > > > I was looking at IgniteEvents.remoteListen() and failed to understand
> > how
> > > > it works. Can someone explain me semantics please?
> > > >
> > > > 1) What is the point of *local* listener in the method
> > "*remote*Listen"?
> > > > Are we collecting events remotely and send them to the local node? If
> > > yes,
> > > > then this is not "remoteListen", it is "localListen" with additional
> > > remote
> > > > filters.
> > > >
> > > > 2) How does "IgnitePredicate rmtFilter" argument work? JavaDoc
> says:
> > > > "It will be auto-unsubsribed on the node where event occurred in case
> > if
> > > it
> > > > returns {@code false}."
> > > > Is this a filter that stops working when "false" is returned? If yes,
> > > this
> > > > is not a filter, I am afraid. It doesn't filter anything. This is
> > > something
> > > > else I cannot name.
> > > >
> > > > To the contrast please look at IgniteMessaging.remoteListen() - clean
> > and
> > > > consistent method.
> > > >
> > > > Looks like we need to rethink this API. The closest concept is
> > continuous
> > > > queries. It has a remote filter (which is really a filter) and a
> local
> > > > listener.
> > > >
> > > > I would remove/deprecate "remoteListen" method and do something like
> > > this:
> > > >
> > > > UUID listen(IgniteInClosure locLsnr, @Nullable
> > > > IgnitePredicate rmtFilter, bool autoUnsubscribe);
> > > > bool stopListen(UUID id);
> > > >
> > > > Thoughts?
> > > >
> > >
> > >
> > >
> > > --
> > > --
> > > Pavel Tupitsyn
> > > GridGain Systems, Inc.
> > > www.gridgain.com
> > >
> >
>

Re: A Future with intermediate progress?

[Pavel Tupitsyn]

Hi,

Another common way of progress reporting is to provide overload for the
operation, e.g.
IgniteFuture doSomething();
IgniteFuture doSomething(Progress progress);

where Progress interface has a single "report(T)" method, and it is up to
user to implement it.

Thanks,

On Wed, Oct 14, 2015 at 4:50 PM, Ivan Veselovskiy  wrote:

> IgniteFuture is an interface to pass the control upon an action completion.
> But the action can be long running, and may have some intermediate
> completion stages, e.g. data loading action progress can be measured as
> loaded data percentage.
> May it make sense to have an IgniteFuture subclass like
> IgniteProgressableFuture with method #getProgress() : double ?
>



-- 
-- 
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com

Re: A Future with intermediate progress?

[Yakov Zhdanov]

I don't think this makes sense. How would you measure progress of cache
put? Does anyone need that?

On the opposite, I agree that it would be nice to have future that is able
to notify user on primaries updated, then on backups update, but again
there were no requests for that.

--Yakov

2015-10-14 16:50 GMT+03:00 Ivan Veselovskiy :

> IgniteFuture is an interface to pass the control upon an action completion.
> But the action can be long running, and may have some intermediate
> completion stages, e.g. data loading action progress can be measured as
> loaded data percentage.
> May it make sense to have an IgniteFuture subclass like
> IgniteProgressableFuture with method #getProgress() : double ?
>