from:"Vladisav Jelisavcic"

Re: IgniteMultiMap design

2015-11-04 Thread Vladisav Jelisavcic

Assigned IGNITE-642 and IGNITE-637 to me,
and unassigned IGNITE-640.

If nobody picks it up in the near future,
I will do it (after I'm done with IGNITE-642 and IGNITE-637).

Best regards,
VJ

On Thu, Nov 5, 2015 at 1:48 AM, Dmitriy Setrakyan <dsetrak...@apache.org>
wrote:

> On Tue, Nov 3, 2015 at 5:46 AM, Vladisav Jelisavcic <vladis...@gmail.com>
> wrote:
>
> > Dear Dmitriy,
> >
> > it sounds excellent, I would like to do it,
> > but I would like to implement ReentrantLock first:
> > https://issues.apache.org/jira/browse/IGNITE-642
> >
> > What do you think?
> >
>
> Vladisav, this sounds great! Both, ReentrantLock and ReentrantReadWriteLock
> are pretty important data structures that Ignite should support.
>
> Can you please assign the IGNITE-642 to yourself and unassign the
> IGNITE-640 to see if someone else in the community will be interested in
> picking it up in the mean time?
>
>
> >
> >
> > On Tue, Nov 3, 2015 at 3:37 AM, Dmitriy Setrakyan <dsetrak...@apache.org
> >
> > wrote:
> >
> > > Igniters,
> > >
> > > MultiMap should be really great addition to the Ignite fabric, as it
> > > provides an easy-to-use API to work with time-series data.
> > >
> > > I have added a detailed design description to the IgniteMultiMap
> ticket:
> > > https://issues.apache.org/jira/browse/IGNITE-640
> > >
> > > Vladislav Jelisavcic, the ticket is currently assigned to you. If you
> > still
> > > intend to work on it,  please review it and let us know if the design
> > makes
> > > sense.
> > >
> > > Also, would be nice if others could review it and provide comments as
> > well.
> > >
> > > D.
> > >
> >
>

Re: IgniteMultiMap design

2015-11-03 Thread Vladisav Jelisavcic

Dear Dmitriy,

it sounds excellent, I would like to do it,
but I would like to implement ReentrantLock first:
https://issues.apache.org/jira/browse/IGNITE-642

What do you think?


On Tue, Nov 3, 2015 at 3:37 AM, Dmitriy Setrakyan 
wrote:

> Igniters,
>
> MultiMap should be really great addition to the Ignite fabric, as it
> provides an easy-to-use API to work with time-series data.
>
> I have added a detailed design description to the IgniteMultiMap ticket:
> https://issues.apache.org/jira/browse/IGNITE-640
>
> Vladislav Jelisavcic, the ticket is currently assigned to you. If you still
> intend to work on it,  please review it and let us know if the design makes
> sense.
>
> Also, would be nice if others could review it and provide comments as well.
>
> D.
>

Re: Ignite-1.5 Release

2015-11-13 Thread Vladisav Jelisavcic

Hi Denis,

Thanks a lot, it looks like my test setup was wrong,
I added semaphore tests to GridCacheAbstractDataStructuresFailoverSelfTest
suite.
Now I have following problem:
when I run tests with TOP_CHANGE_THREAD_CNT = 3
tests fail when they reach stop() with the following exception:

class org.apache.ignite.internal.IgniteInterruptedCheckedException: Node is
stopping: 09c5e8b8-8998-468e-960d-223220354fd3
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStop0(GridCachePartitionExchangeManager.java:382)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.onKernalStop(GridCacheSharedManagerAdapter.java:113)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:946)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:1823)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:1769)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2133)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2096)
at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:314)
at org.apache.ignite.Ignition.stop(Ignition.java:223)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:802)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:784)
at
org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.access$500(GridCacheAbstractDataStructuresFailoverSelfTest.java:54)
at
org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest$5.apply(GridCacheAbstractDataStructuresFailoverSelfTest.java:459)

When I run tests with TOP_CHANGE_THEAD_CNT = 1
everything is running ok;


@Yakov
I made a new commit to my IGNITE-638 branch,
can you please take a look?



Best regards,
Vladisav




> On Wed, Nov 11, 2015 at 3:48 PM, Denis Magda <dma...@gridgain.com> wrote:
>
> > Hi Vladislav,
> >
> > Please see below..
> >
> >
> > On 11/11/2015 12:33 PM, Vladisav Jelisavcic wrote:
> >
> >> Yakov,
> >>
> >> sorry  for running a bit late.
> >>
> >> Vladislav, do you have any updates for
> >>> https://issues.apache.org/jira/browse/IGNITE-638? Or any questions?
> >>>
> >>> --Yakov
> >>>
> >> I have problems with some fail-over scenarios;
> >> It seems that if the two nodes are in the middle of acquiring or
> releasing
> >> the semaphore,
> >> and one of them fails, all nodes get:
> >>
> >> [09:36:38,509][ERROR][ignite-#13%pub-null%][GridCacheSemaphoreImpl]
> >>  Failed to compare and set:
> >> o.a.i.i.processors.datastructures.GridCacheSemaphoreImpl$Sync$1@5528b728
> >> class
> org.apache.ignite.internal.cluster.ClusterTopologyCheckedException:
> >> Failed to acquire lock for keys (primary node left grid, retry
> transaction
> >> if possible) [keys=[UserKeyCacheObjectImpl [val=GridCacheInternalKeyImpl
> >> [name=ac83b8cb-3052-49a6-9301-81b20b0ecf3a], hasValBytes=true]],
> >> node=c321fcc4-5db5-4b03-9811-6a5587f2c253]
> >> ...
> >> Caused by: class
> >> org.apache.ignite.internal.cluster.ClusterTopologyCheckedException:
> Failed
> >> to acquire lock for keys (primary node left grid, retry transaction if
> >> possible) [keys=[UserKeyCacheObjectImpl [val=GridCacheInternalKeyImpl
> >> [name=ac83b8cb-3052-49a6-9301-81b20b0ecf3a], hasValBytes=true]],
> >> node=c321fcc4-5db5-4b03-9811-6a5587f2c253]
> >> at
> >>
> >>
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.newTopologyException(GridDhtColocatedLockFuture.java:1199)
> >> ... 10 more
> >>
> > You have to process this exception manually at your implementation layer
> > since your data structure uses a transactional cache.
> > Below is a kind of template I used when it was required to process this
> > and some other exeptions. You can use it as-is.
> >
> > int retries = GridCacheAdapter.MAX_RETRIES;
> >
> > IgniteCheckedException err =null;
> >
> > for (int i =0; i < retries; i++) {
> > try {
> > //Your transactional code that may fail
> > }
> > catch (IgniteCheckedException e) {
> > if (i == retries)
> > throw e;
> >
> > if (X.hasCause(e, ClusterTopologyCheckedException.class)) {
> > ClusterTopologyCheckedException topErr =
> > e.getCause(ClusterTopologyCheckedException.class);
> >
> > topErr.retryR

Semaphore issue

2015-09-25 Thread Vladisav Jelisavcic

Hi everyone,

my name is VJ, i would like to implement IgniteSemaphore datastructure (
IGNITE-638).
My Jira ID is vladisav, can someone please assign it to me?

Thanks,
VJ

Re: Ignite Download links broken

2016-06-20 Thread Vladisav Jelisavcic

Not working for me also,
but only 1.6.0 (latest) and 1.5.0.final, the rest is working fine.

On Mon, Jun 20, 2016 at 8:02 AM, Sergey Kozlov  wrote:

> Hi
>
> It's a known issue: apache site puts links to a nearest site for user (I
> suppose it based on IP address) and does it incorrect.
>
> On Mon, Jun 20, 2016 at 8:37 AM, Dmitriy Setrakyan 
> wrote:
>
> > Worked for me just now. Can you try again?
> >
> > On Sun, Jun 19, 2016 at 2:59 AM, Christos Erotocritou <
> > chris...@gridgain.com> wrote:
> >
> >> Hey guys,
> >>
> >> The links on the website seem to be broken, can someone check this?
> >>
> >> https://ignite.apache.org/download.html#binaries <
> >> https://ignite.apache.org/download.html#binaries>
> >>
> >> Thanks,
> >>
> >> Christos
> >
> >
> >
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

Re: Semaphore action

2016-01-18 Thread Vladisav Jelisavcic

I created a ticket from this discussion:

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

Can someone please review it (and edit if needed)?

Best regrads,
VJ

On Mon, Jan 18, 2016 at 12:28 PM, Yakov Zhdanov  wrote:

> I like the idea. Couple of comments though.
>
> I would leave only  IgniteFuture acquireAndExecute(Callable
> action); Overload with executor can be omitted because callable
> implementation can use any executor. As far as moving acquire logic to
> another thread pool - I think we'd better go without it same as for any
> other Ignite operations. Andrey, what was the pool intended for?
>
> This T> IgniteFuture
> acquireAndExecuteAsyncAction(Callable
> action); can be implemented with   IgniteFuture
> acquireAndExecute(Callable action); where T is IgniteFuture for
> operations initiated and returned by callable. Makes sense?
>
>
> --Yakov
>
> 2016-01-18 0:39 GMT+03:00 Andrey Kornev :
>
> > Just to clarify, 7.4 below refers to GridGain 7.4, which is Ignite 1.4.
> > _
> > From: Andrey Kornev 
> > Sent: Sunday, January 17, 2016 10:27 AM
> > Subject: RE: Semaphore action
> > To:  
> >
> >
> >Vladisav,
> >
> >  It would be great if you could implement the enhancements!
> >
> >  And while we're at it, here's something else I'd like us to consider.
> The
> > proposed API only gets us half way there: there is no longer a blocking
> > wait for the permit, but the action must be blocking. I really think it
> > should be possible to do the whole thing asynchronously including the
> > action and release of the permit. (In fact, this is what I need for my
> > project. In 7.4, I was able to implement this feature using just the
> public
> > APIs, but I'd really like to drop that code and start using the Semaphore
> > API.)
> >
> >  For example, upon the permit acquisition, the action could fire off a
> > distributed compute and rather than block waiting for the results to come
> > back, it would simply return the future provided by Ignite's withAsync().
> > The semaphore implementation would not release the permit immediately
> upon
> > the action return. Instead, it'd do so only when the action future
> > completes.
> >
> >  Here's how the API might look like:
> >
> >   IgniteFuture
> > acquireAndExecuteAsyncAction(Callable action);
> >
> >  This API makes it possible to execute a protected action with no
> blocking
> > whatsoever! It's a lot more efficient, reduces the pressure on Ignite's
> > thread pools and prevents thread starvation, and so on.
> >
> >  Regards
> >  Andrey
> >
> >  > Date: Sun, 17 Jan 2016 10:40:53 +0100
> >  > Subject: Re: Semaphore action
> >  > From: vladis...@gmail.com
> >  > To: dev@ignite.apache.org
> >  >
> >  > It does sounds like a useful addition,
> >  > and I believe it could be implemented easily.
> >  > I can do it if the community agrees on changing the API of the
> > Semaphore.
> >  >
> >  > Best regards,
> >  > VJ
> >  >
> >  > On Sun, Jan 17, 2016 at 5:53 AM, Andrey Kornev <
> > andrewkor...@hotmail.com>
> >  > wrote:
> >  >
> >  > > Dmitriy,I don't believe it makes sense to have the action execute
> >  > > remotely. At least I didn't think of it.In my mind, the action is
> > always
> >  > > local (that's the reason I suggested the Java's Callable in the API
> > and not
> >  > > serializable IgniteCallable, in the first place). What the action
> > does is
> >  > > entirely up to the user. One could fire off a remote compute if
> > that's what
> >  > > one wants.I hope I make myself clear.ThanksAndrey
> >  > > _
> >  > > From: Dmitriy Setrakyan 
> >  > > Sent: Saturday, January 16, 2016 7:54 AM
> >  > > Subject: Re: Semaphore action
> >  > > To:  
> >  > >
> >  > >
> >  > >Andrey,
> >  > >
> >  > >  In general this seems like a good addition. However, I do not
> > understand
> >  > >  how you can specify an executor, given that execution could happen
> >  > >  remotely. Can you please clarify?
> >  > >
> >  > >  D.
> >  > >
> >  > >  On Fri, Jan 15, 2016 at 1:00 PM, Andrey Kornev <
> > andrewkor...@hotmail.com>
> >  > >  wrote:
> >  > >
> >  > >  > Hi there,
> >  > >  >
> >  > >  > The Semaphore feature was a great addition to Ignite's
> > synchronization
> >  > >  > primitive toolkit. I'd like to propose an enhancement to make
> > Semaphore
> >  > > API
> >  > >  > even more useful.
> >  > >  >
> >  > >  > My biggest complaint about the current API is its blocking
> nature.
> > For
> >  > >  > example, the only way to acquire a permit is by using the
> blocking
> >  > >  > acquire() method (tryAcquire() is not very useful in the cases
> > when you
> >  > >  > MUST acquire before you can proceed). I believe that in the 21st
> > century
> >  > >  > blocking APIs is anachronism. :))) It's a bit

Re: Semaphore waiting for permit even if node is shut down

2016-02-29 Thread Vladisav Jelisavcic

Sure, no problem.

I created a ticket:
https://issues.apache.org/jira/browse/IGNITE-2735

and a PR to resolve this problem.
I think this should also fix:  IGNITE-1977
but the non-failover test scenario is not good anymore;

Best regards,
Vladisav




On Mon, Feb 29, 2016 at 2:32 PM, Vladimir Ozerov 
wrote:

> Hi,
>
> I tested your code in multi-node scenario, and semaphore is released fine
> when node owning a permit has been closed. In your code sample there is
> only one node, and in this case semaphore is not released. I think that
> "acquire" method should throw an exception in this case (say,
> InterruptedException) as semaphore is no longer accessible when node is
> stopped.
>
> Vladislav,
> I know you worked on distributed semaphore. Could you please share your
> thoughts on the matter? And would you mind fixing that for a single-node
> scenario?
>
> Vladimir.
>
> On Sun, Feb 28, 2016 at 11:14 PM, nyname00 
> wrote:
>
> > Hi Igniters,
> >
> > I've got a problem with a semaphore that seems to wait for a permit even
> if
> > the node is already shut down. This behavior appears in a multi-node
> setup
> > where i try to shut down all nodes at the same time (using a
> poison-pill).
> > The code below can be used to reproduce the behavior. You will notice
> that
> > there is no call on sem1#release() - this is because in my poison-pill
> > scenario there seems to be no way to get a handle to sem1. And since I
> was
> > under the impression that any semaphore gets released by Ignite when the
> > node crashes/is shut down, I was expecting an exception on
> sem2#acquire().
> >
> > Any ideas? Best regards,
> > Mario
> >
> > public static void main(String[] args) {
> > Ignite i1 = Ignition.start(new
> > IgniteConfiguration().setGridName("1"));
> >
> > System.out.println(">>> I1 STARTED");
> > IgniteSemaphore sem1 = i1.semaphore("sem1", 1, true, true);
> > System.out.println(">>> S1 READ");
> > sem1.acquire();
> > System.out.println(">>> S1 ACQUIRED");
> >
> > new Thread(() -> {
> > IgniteSemaphore sem2 = i1.semaphore("sem1", 1, true, true);
> > System.out.println(">>> S1 READ 2");
> > sem2.acquire();
> > try {
> > System.out.println(">>> S1 ACQUIRED 2");
> > } finally {
> > sem2.release();
> > }
> > }).start();
> >
> > try {
> > TimeUnit.SECONDS.sleep(2);
> > } catch (InterruptedException e) {
> > e.printStackTrace();
> > }
> >
> > System.out.println(">>> I1 CLOSING");
> > i1.close();
> > System.out.println(">>> I1 CLOSED");
> > }
> >
> >
> >
> > --
> > View this message in context:
> >
> http://apache-ignite-users.70518.x6.nabble.com/Semaphore-waiting-for-permit-even-if-node-is-shut-down-tp3232.html
> > Sent from the Apache Ignite Users mailing list archive at Nabble.com.
> >
>

Re: Semaphore blocking on tryAcquire() while holding a cache-lock

2016-03-18 Thread Vladisav Jelisavcic

Hi Yakov,

yes, thanks for the comments, I think everything should be ok now,
please review the PR and tell me if you think anything else is needed.

Once ignite-642 is merged into master,
I'll submit a PR for IgniteReadWriteLock (hopefully on time for 1.6.
release).

Best regrads,
Vladisav



On Fri, Mar 18, 2016 at 11:56 AM, Yakov Zhdanov <yzhda...@gridgain.com>
wrote:

> Vlad, did you have a chance to review my latest comments?
>
> Thanks!
> --
> Yakov Zhdanov, Director R
> *GridGain Systems*
> www.gridgain.com
>
> 2016-03-06 12:21 GMT+03:00 Yakov Zhdanov <yzhda...@apache.org>:
>
> > Vlad and all (esp Val and Anton V.),
> >
> > I reviewed the PR. My comments are in the ticket.
> >
> > Anton V. there is a question regarding optimized-classnames.properties.
> > Can you please respond in ticket?
> >
> >
> > --Yakov
> >
> > 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yzhda...@apache.org>:
> >
> >> Vlad, that's great! I will take a look this week. Reassigning ticket to
> >> myself.
> >>
> >> --Yakov
> >>
> >> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vladis...@gmail.com>:
> >>
> >>> Hi,
> >>>
> >>> i recently implemented distributed ReentrantLock - IGNITE-642,
> >>> i made a pull request, so hopefully this could be added to the next
> >>> release.
> >>>
> >>> Best regards,
> >>> Vladisav
> >>>
> >>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
> >>> alexey.goncha...@gmail.com> wrote:
> >>>
> >>> > Folks,
> >>> >
> >>> > The current implementation of IgniteCache.lock(key).lock() has the
> same
> >>> > semantics as the transactional locks - cache topology cannot be
> changed
> >>> > while there exists an ongoing transaction or an explicit lock is
> held.
> >>> The
> >>> > restriction for transactions is quite fundamental, the lock() issue
> >>> can be
> >>> > fixed if we re-implement locking the same way IgniteSemaphore
> currently
> >>> > works.
> >>> >
> >>> > As for the "Failed to find semaphore with the given name" message, my
> >>> first
> >>> > guess is that DataStructures were configured with 1 backups which led
> >>> to
> >>> > the data loss when two nodes were stopped. Mario, can you please
> >>> re-test
> >>> > your semaphore scenario with 2 backups configured for data
> structures?
> >>> > From my side, I can also take a look at the semaphore issue when I'm
> >>> done
> >>> > with IGNITE-2610.
> >>> >
> >>>
> >>
> >>
> >
>

Re: Semaphore blocking on tryAcquire() while holding a cache-lock

2016-04-08 Thread Vladisav Jelisavcic

Yakov,

sorry for the long delay, I added another commit to the PR,
can you please do the review again?

Thanks!
Vladisav

On Sun, Mar 27, 2016 at 11:30 AM, Vladisav Jelisavcic <vladis...@gmail.com>
wrote:

> Yakov, I've seen your comments, can you please check the jira again?
>
>
> On Wed, Mar 23, 2016 at 4:46 PM, Yakov Zhdanov <yzhda...@apache.org>
> wrote:
>
>> Vlad, can you please check my comments again?
>>
>> --Yakov
>>
>> 2016-03-18 17:57 GMT+03:00 Vladisav Jelisavcic <vladis...@gmail.com>:
>>
>> > Hi Yakov,
>> >
>> > yes, thanks for the comments, I think everything should be ok now,
>> > please review the PR and tell me if you think anything else is needed.
>> >
>> > Once ignite-642 is merged into master,
>> > I'll submit a PR for IgniteReadWriteLock (hopefully on time for 1.6.
>> > release).
>> >
>> > Best regrads,
>> > Vladisav
>> >
>> >
>> >
>> > On Fri, Mar 18, 2016 at 11:56 AM, Yakov Zhdanov <yzhda...@gridgain.com>
>> > wrote:
>> >
>> > > Vlad, did you have a chance to review my latest comments?
>> > >
>> > > Thanks!
>> > > --
>> > > Yakov Zhdanov, Director R
>> > > *GridGain Systems*
>> > > www.gridgain.com
>> > >
>> > > 2016-03-06 12:21 GMT+03:00 Yakov Zhdanov <yzhda...@apache.org>:
>> > >
>> > > > Vlad and all (esp Val and Anton V.),
>> > > >
>> > > > I reviewed the PR. My comments are in the ticket.
>> > > >
>> > > > Anton V. there is a question regarding
>> optimized-classnames.properties.
>> > > > Can you please respond in ticket?
>> > > >
>> > > >
>> > > > --Yakov
>> > > >
>> > > > 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yzhda...@apache.org>:
>> > > >
>> > > >> Vlad, that's great! I will take a look this week. Reassigning
>> ticket
>> > to
>> > > >> myself.
>> > > >>
>> > > >> --Yakov
>> > > >>
>> > > >> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <
>> vladis...@gmail.com>:
>> > > >>
>> > > >>> Hi,
>> > > >>>
>> > > >>> i recently implemented distributed ReentrantLock - IGNITE-642,
>> > > >>> i made a pull request, so hopefully this could be added to the
>> next
>> > > >>> release.
>> > > >>>
>> > > >>> Best regards,
>> > > >>> Vladisav
>> > > >>>
>> > > >>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
>> > > >>> alexey.goncha...@gmail.com> wrote:
>> > > >>>
>> > > >>> > Folks,
>> > > >>> >
>> > > >>> > The current implementation of IgniteCache.lock(key).lock() has
>> the
>> > > same
>> > > >>> > semantics as the transactional locks - cache topology cannot be
>> > > changed
>> > > >>> > while there exists an ongoing transaction or an explicit lock is
>> > > held.
>> > > >>> The
>> > > >>> > restriction for transactions is quite fundamental, the lock()
>> issue
>> > > >>> can be
>> > > >>> > fixed if we re-implement locking the same way IgniteSemaphore
>> > > currently
>> > > >>> > works.
>> > > >>> >
>> > > >>> > As for the "Failed to find semaphore with the given name"
>> message,
>> > my
>> > > >>> first
>> > > >>> > guess is that DataStructures were configured with 1 backups
>> which
>> > led
>> > > >>> to
>> > > >>> > the data loss when two nodes were stopped. Mario, can you please
>> > > >>> re-test
>> > > >>> > your semaphore scenario with 2 backups configured for data
>> > > structures?
>> > > >>> > From my side, I can also take a look at the semaphore issue when
>> > I'm
>> > > >>> done
>> > > >>> > with IGNITE-2610.
>> > > >>> >
>> > > >>>
>> > > >>
>> > > >>
>> > > >
>> > >
>> >
>>
>
>

Re: Semaphore blocking on tryAcquire() while holding a cache-lock

2016-03-27 Thread Vladisav Jelisavcic

Yakov, I've seen your comments, can you please check the jira again?


On Wed, Mar 23, 2016 at 4:46 PM, Yakov Zhdanov <yzhda...@apache.org> wrote:

> Vlad, can you please check my comments again?
>
> --Yakov
>
> 2016-03-18 17:57 GMT+03:00 Vladisav Jelisavcic <vladis...@gmail.com>:
>
> > Hi Yakov,
> >
> > yes, thanks for the comments, I think everything should be ok now,
> > please review the PR and tell me if you think anything else is needed.
> >
> > Once ignite-642 is merged into master,
> > I'll submit a PR for IgniteReadWriteLock (hopefully on time for 1.6.
> > release).
> >
> > Best regrads,
> > Vladisav
> >
> >
> >
> > On Fri, Mar 18, 2016 at 11:56 AM, Yakov Zhdanov <yzhda...@gridgain.com>
> > wrote:
> >
> > > Vlad, did you have a chance to review my latest comments?
> > >
> > > Thanks!
> > > --
> > > Yakov Zhdanov, Director R
> > > *GridGain Systems*
> > > www.gridgain.com
> > >
> > > 2016-03-06 12:21 GMT+03:00 Yakov Zhdanov <yzhda...@apache.org>:
> > >
> > > > Vlad and all (esp Val and Anton V.),
> > > >
> > > > I reviewed the PR. My comments are in the ticket.
> > > >
> > > > Anton V. there is a question regarding
> optimized-classnames.properties.
> > > > Can you please respond in ticket?
> > > >
> > > >
> > > > --Yakov
> > > >
> > > > 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yzhda...@apache.org>:
> > > >
> > > >> Vlad, that's great! I will take a look this week. Reassigning ticket
> > to
> > > >> myself.
> > > >>
> > > >> --Yakov
> > > >>
> > > >> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vladis...@gmail.com
> >:
> > > >>
> > > >>> Hi,
> > > >>>
> > > >>> i recently implemented distributed ReentrantLock - IGNITE-642,
> > > >>> i made a pull request, so hopefully this could be added to the next
> > > >>> release.
> > > >>>
> > > >>> Best regards,
> > > >>> Vladisav
> > > >>>
> > > >>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
> > > >>> alexey.goncha...@gmail.com> wrote:
> > > >>>
> > > >>> > Folks,
> > > >>> >
> > > >>> > The current implementation of IgniteCache.lock(key).lock() has
> the
> > > same
> > > >>> > semantics as the transactional locks - cache topology cannot be
> > > changed
> > > >>> > while there exists an ongoing transaction or an explicit lock is
> > > held.
> > > >>> The
> > > >>> > restriction for transactions is quite fundamental, the lock()
> issue
> > > >>> can be
> > > >>> > fixed if we re-implement locking the same way IgniteSemaphore
> > > currently
> > > >>> > works.
> > > >>> >
> > > >>> > As for the "Failed to find semaphore with the given name"
> message,
> > my
> > > >>> first
> > > >>> > guess is that DataStructures were configured with 1 backups which
> > led
> > > >>> to
> > > >>> > the data loss when two nodes were stopped. Mario, can you please
> > > >>> re-test
> > > >>> > your semaphore scenario with 2 backups configured for data
> > > structures?
> > > >>> > From my side, I can also take a look at the semaphore issue when
> > I'm
> > > >>> done
> > > >>> > with IGNITE-2610.
> > > >>> >
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>

Re: distributed data types for ML applications

2016-03-04 Thread Vladisav Jelisavcic

This sounds excellent, I'll get right to it.

Best regards,
Vladisav

On Fri, Mar 4, 2016 at 2:48 AM, Dmitriy Setrakyan <dsetrak...@apache.org>
wrote:

> Vladislav,
>
> This would be a great contribution. For a feature like this, I would pick 1
> ML library and propose the design first. Once the community agrees on the
> design, you can proceed with the implementation.
>
> Does this sound good?
>
> D.
>
> On Thu, Mar 3, 2016 at 11:22 AM, Vladisav Jelisavcic <vladis...@gmail.com>
> wrote:
>
> > Igniters,
> >
> > is IGNITE-1251 still a thing?
> > If so, I would really like to start working on this one.
> >
> > Best regards,
> > Vladisav
> >
>

distributed data types for ML applications

2016-03-03 Thread Vladisav Jelisavcic

Igniters,

is IGNITE-1251 still a thing?
If so, I would really like to start working on this one.

Best regards,
Vladisav

Re: Semaphore blocking on tryAcquire() while holding a cache-lock

2016-04-27 Thread Vladisav Jelisavcic

Yakov,

did you had time to do another review round of ignite-642?

Thanks!

On Fri, Apr 15, 2016 at 3:53 PM, Vladisav Jelisavcic <vladis...@gmail.com>
wrote:

> Yakov,
>
> I've finished the initialization tests for ignite-642 (and moved
> serialization test from GridCacheLockAbstractTest to
> IgniteLockAbstractSelfTest).
> Please check the commit and let me know if you spot anything else.
> Thanks!
>
> On Fri, Apr 15, 2016 at 10:11 AM, Vladisav Jelisavcic <vladis...@gmail.com
> > wrote:
>
>> Yakov,
>>
>> I reviewed the changes in ignite-642 and it looks good to me, but I have
>> one question.
>> Can you please look at my comment in ignite-642 ticket?
>>
>> Thanks!
>> Vladisav
>>
>> On Thu, Apr 14, 2016 at 7:51 PM, Vladisav Jelisavcic <vladis...@gmail.com
>> > wrote:
>>
>>> Sure, I'll look into it later today, or tomorrow at the latest
>>>
>>> On Thu, Apr 14, 2016 at 5:53 PM, Yakov Zhdanov <yzhda...@apache.org>
>>> wrote:
>>>
>>>> Vlad, please see my changes in ignite-642 and comment in the ticket.
>>>>
>>>> Alex, can you please take a look at my latest commit as well and provide
>>>> comments?
>>>>
>>>> --Yakov
>>>>
>>>> 2016-04-12 23:47 GMT+03:00 Yakov Zhdanov <yzhda...@apache.org>:
>>>>
>>>> > Very good points, Alexey. I will look at this tomorrow and finalize
>>>> the
>>>> > changes.
>>>> >
>>>> > --Yakov
>>>> >
>>>> > 2016-04-12 23:41 GMT+03:00 Alexey Goncharuk <
>>>> alexey.goncha...@gmail.com>:
>>>> >
>>>> >> Guys,
>>>> >>
>>>> >> I fixed code style a bit and pushed my changes to the branch.
>>>> >>
>>>> >> Couple of questions:
>>>> >>  - I see that some of the Errors caught do not get re-thrown (e.g. if
>>>> >> interruptAll flag is set). I believe we should at least re-throw
>>>> OOME in
>>>> >> any case.
>>>> >>  - readResolve method is missing for CacheLockImpl. The current
>>>> >> readExternal/writeExternal code uses static stash field. I looked
>>>> around
>>>> >> in
>>>> >> the code and found that IgniteKernal uses localIgnite, while
>>>> >> GridCacheAdapter uses stash. Which way is the correct one?
>>>> >> 
>>>> >>
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>

Re: Integration with Apache Apex

2016-05-13 Thread Vladisav Jelisavcic

Hi,

it looks really interesting to me,
I'll be glad to pick this one.


Best regards,
Vladisav


On Fri, May 13, 2016 at 7:41 AM, Thomas Weise  wrote:

> Dear Ignite community,
>
> Apache Apex is a data in-motion processing platform. It was developed since
> 2012 and recently became an ASF top level project:
>
> http://apex.apache.org/docs.html
>
> The Apex engine can process large scale, high throughput streams with very
> low latency. It is a stateful system with strong processing guarantees. A
> unique feature of Apex is the ability to recover from failures without
> resetting the entire topology and also the ability to scale or change the
> application dynamically. Apex also has a large library of connectors,
> supporting integration with many well known projects in the wider big data
> ecosystem out of the box.
>
> It would be great to add Ignite to the list. I think Apex as processing
> engine and Ignite as storage layer would be a very powerful combination.
> Here are some use cases for such integration:
>
>- Connectors to read from Ignite or land data in Ignite (
>https://issues.apache.org/jira/browse/IGNITE-3131)
>- Checkpointing backend (alternative implementation for Apex
>StorageAgent)
>- Backend for operator specific state management
>
> It would be great if someone in Ignite community wants to take this up and
> collaborate. There is also a ticket in the Apex JIRA to track this:
> https://issues.apache.org/jira/browse/APEXMALHAR-2091
>
> Thanks,
> Thomas
>

Re: Semaphore blocking on tryAcquire() while holding a cache-lock

2016-04-15 Thread Vladisav Jelisavcic

Yakov,

I've finished the initialization tests for ignite-642 (and moved
serialization test from GridCacheLockAbstractTest to
IgniteLockAbstractSelfTest).
Please check the commit and let me know if you spot anything else.
Thanks!

On Fri, Apr 15, 2016 at 10:11 AM, Vladisav Jelisavcic <vladis...@gmail.com>
wrote:

> Yakov,
>
> I reviewed the changes in ignite-642 and it looks good to me, but I have
> one question.
> Can you please look at my comment in ignite-642 ticket?
>
> Thanks!
> Vladisav
>
> On Thu, Apr 14, 2016 at 7:51 PM, Vladisav Jelisavcic <vladis...@gmail.com>
> wrote:
>
>> Sure, I'll look into it later today, or tomorrow at the latest
>>
>> On Thu, Apr 14, 2016 at 5:53 PM, Yakov Zhdanov <yzhda...@apache.org>
>> wrote:
>>
>>> Vlad, please see my changes in ignite-642 and comment in the ticket.
>>>
>>> Alex, can you please take a look at my latest commit as well and provide
>>> comments?
>>>
>>> --Yakov
>>>
>>> 2016-04-12 23:47 GMT+03:00 Yakov Zhdanov <yzhda...@apache.org>:
>>>
>>> > Very good points, Alexey. I will look at this tomorrow and finalize the
>>> > changes.
>>> >
>>> > --Yakov
>>> >
>>> > 2016-04-12 23:41 GMT+03:00 Alexey Goncharuk <
>>> alexey.goncha...@gmail.com>:
>>> >
>>> >> Guys,
>>> >>
>>> >> I fixed code style a bit and pushed my changes to the branch.
>>> >>
>>> >> Couple of questions:
>>> >>  - I see that some of the Errors caught do not get re-thrown (e.g. if
>>> >> interruptAll flag is set). I believe we should at least re-throw OOME
>>> in
>>> >> any case.
>>> >>  - readResolve method is missing for CacheLockImpl. The current
>>> >> readExternal/writeExternal code uses static stash field. I looked
>>> around
>>> >> in
>>> >> the code and found that IgniteKernal uses localIgnite, while
>>> >> GridCacheAdapter uses stash. Which way is the correct one?
>>> >> 
>>> >>
>>> >
>>> >
>>>
>>
>>
>

Re: Semaphore blocking on tryAcquire() while holding a cache-lock

2016-04-15 Thread Vladisav Jelisavcic

Yakov,

I reviewed the changes in ignite-642 and it looks good to me, but I have
one question.
Can you please look at my comment in ignite-642 ticket?

Thanks!
Vladisav

On Thu, Apr 14, 2016 at 7:51 PM, Vladisav Jelisavcic <vladis...@gmail.com>
wrote:

> Sure, I'll look into it later today, or tomorrow at the latest
>
> On Thu, Apr 14, 2016 at 5:53 PM, Yakov Zhdanov <yzhda...@apache.org>
> wrote:
>
>> Vlad, please see my changes in ignite-642 and comment in the ticket.
>>
>> Alex, can you please take a look at my latest commit as well and provide
>> comments?
>>
>> --Yakov
>>
>> 2016-04-12 23:47 GMT+03:00 Yakov Zhdanov <yzhda...@apache.org>:
>>
>> > Very good points, Alexey. I will look at this tomorrow and finalize the
>> > changes.
>> >
>> > --Yakov
>> >
>> > 2016-04-12 23:41 GMT+03:00 Alexey Goncharuk <alexey.goncha...@gmail.com
>> >:
>> >
>> >> Guys,
>> >>
>> >> I fixed code style a bit and pushed my changes to the branch.
>> >>
>> >> Couple of questions:
>> >>  - I see that some of the Errors caught do not get re-thrown (e.g. if
>> >> interruptAll flag is set). I believe we should at least re-throw OOME
>> in
>> >> any case.
>> >>  - readResolve method is missing for CacheLockImpl. The current
>> >> readExternal/writeExternal code uses static stash field. I looked
>> around
>> >> in
>> >> the code and found that IgniteKernal uses localIgnite, while
>> >> GridCacheAdapter uses stash. Which way is the correct one?
>> >> 
>> >>
>> >
>> >
>>
>
>

Re: Semaphore blocking on tryAcquire() while holding a cache-lock

2016-04-14 Thread Vladisav Jelisavcic

Sure, I'll look into it later today, or tomorrow at the latest

On Thu, Apr 14, 2016 at 5:53 PM, Yakov Zhdanov  wrote:

> Vlad, please see my changes in ignite-642 and comment in the ticket.
>
> Alex, can you please take a look at my latest commit as well and provide
> comments?
>
> --Yakov
>
> 2016-04-12 23:47 GMT+03:00 Yakov Zhdanov :
>
> > Very good points, Alexey. I will look at this tomorrow and finalize the
> > changes.
> >
> > --Yakov
> >
> > 2016-04-12 23:41 GMT+03:00 Alexey Goncharuk  >:
> >
> >> Guys,
> >>
> >> I fixed code style a bit and pushed my changes to the branch.
> >>
> >> Couple of questions:
> >>  - I see that some of the Errors caught do not get re-thrown (e.g. if
> >> interruptAll flag is set). I believe we should at least re-throw OOME in
> >> any case.
> >>  - readResolve method is missing for CacheLockImpl. The current
> >> readExternal/writeExternal code uses static stash field. I looked around
> >> in
> >> the code and found that IgniteKernal uses localIgnite, while
> >> GridCacheAdapter uses stash. Which way is the correct one?
> >> 
> >>
> >
> >
>

Re: NullPointerException when stopping IgniteSemaphore

2016-07-21 Thread Vladisav Jelisavcic

Sure, I'll do the review.

It is lazy initialized, same as latch and other datastructures.

Regards,
Vladisav

On Thu, Jul 21, 2016 at 10:24 AM, Yakov Zhdanov  wrote:

> Vladislav, can you please review and merge to master the fix and test case
> suggested by Krome?
>
> Vlad, btw, why don't we init semaphore during construction time?
>
> https://issues.apache.org/jira/browse/IGNITE-3515
>
> Thanks!
>
> --Yakov
>

ReadWriteUpdateLock

2016-07-18 Thread Vladisav Jelisavcic

Hi everyone,

cross-posting from JIRA:
I recently came across this post:
http://codereview.stackexchange.com/a/31231

Do you think ReadWriteUpdateLock is something we can put to good use here
in Ignite?

This kind of lock should be more efficient for read-before-write patterns.

Best regards,
Vladisav

Re: IGNITE-4155 IgniteSemaphoreExample unexpected behavior

2016-11-08 Thread Vladisav Jelisavcic

Hi Sergey,

can you please provide more information?
Have you changed the example (if so, can you provide the changes you made?)
Is the example executed normally (without node failures)?

In the example, semaphore is created in non-failover safe mode,
which means it is not safe to use it once it is broken (something like
CyclicBarrier in java.util.concurrent),
and the semaphore is preserved in spite of the first node failing (if the
backups are configured),
so if the first node failed, then (broken) semaphore with the same name
should still be in the cache,
and this is expected behavior.

If this is not the case (test was executed normally) then please submit a
ticket describing more your setup,
how many nodes, how many backups configured, etc..

Thanks!
Vladisav

On Tue, Nov 8, 2016 at 10:37 AM, Sergey Chugunov 
wrote:

>  Hello folks,
>
> I found a reason why *IgniteSemaphoreExample* hangs when started twice
> without restarting a cluster; and it doesn't seem minor to me anymore.
>
> From here I'm going to refer to example's code so please have it opened.
>
> So, when the first instance of node running example code finishes and
> leaves the cluster, synchronization semaphore named
> "IgniteSemaphoreExample" goes to broken state on all other cluster nodes.
> If I restart example without restarting all nodes of the cluster, final
> *acquire *call on the semaphore on client side hangs because all other
> nodes treat it as broken and don't increase permits with their *release
> *calls
> on it.
>
> There is an interesting comment inside its *tryReleaseShared*
> implementation
> (BTW it is implemented in *GridCacheSemaphoreImpl*):
>
> "// If broken, return immediately, exception will be thrown anyway.
>  if (broken)
>return true;"
>
> It seems that no exceptions are thrown neither on client side calling
> *acquire
> *or on server side calling *release *methods on a broken semaphore.
>
> Does anybody know why it behaves in that way? Is it expected behavior at
> all and if yes where is it documented?
>
> Thanks,
> Sergey Chugunov.
>

Re: IGNITE-4155 IgniteSemaphoreExample unexpected behavior

2016-11-09 Thread Vladisav Jelisavcic

Hi Sergey,

you are right - I can reproduce this also.
It seems to me that this is caused because we treat the same both
EVT_NODE_LEFT and EVT_NODE_FAILED events.
In this case, node leaves the topology without failure, but fails to
release the semaphore before EVT_NODE_LEFT event occurs on other nodes,
this really is a bug.

Thanks!
Vladisav

On Wed, Nov 9, 2016 at 11:23 AM, Sergey Chugunov <sergey.chugu...@gmail.com>
wrote:

> Hello Vladisav,
>
> I found this behavior in a very simple environment: I had two nodes on my
> local machine started by *ExampleNodeStartup* class and another node
> started with *IgniteSemaphoreExample* class.
>
> No modifications were made to any code or configuration and I used latest
> version of code available in master branch.
> No node failures occurred during test execution as well.
>
> As far as I understood from short investigation synchronization semaphore
> of name "IgniteSemaphoreExample" goes to broken state when
> *IgniteSemaphoreExample* node normally finishes and disconnects from the
> cluster.
> After that reusing of this semaphore becomes impossible and leads to
> hanging of new nodes doing so.
>
> Can you reproduce this? If so I will submit a ticket and share with you.
>
> Thank you,
> Sergey.
>
>
> On Wed, Nov 9, 2016 at 10:55 AM, Vladisav Jelisavcic <vladis...@gmail.com>
> wrote:
>
> > Hi Sergey,
> >
> > can you please provide more information?
> > Have you changed the example (if so, can you provide the changes you
> made?)
> > Is the example executed normally (without node failures)?
> >
> > In the example, semaphore is created in non-failover safe mode,
> > which means it is not safe to use it once it is broken (something like
> > CyclicBarrier in java.util.concurrent),
> > and the semaphore is preserved in spite of the first node failing (if the
> > backups are configured),
> > so if the first node failed, then (broken) semaphore with the same name
> > should still be in the cache,
> > and this is expected behavior.
> >
> > If this is not the case (test was executed normally) then please submit a
> > ticket describing more your setup,
> > how many nodes, how many backups configured, etc..
> >
> > Thanks!
> > Vladisav
> >
> > On Tue, Nov 8, 2016 at 10:37 AM, Sergey Chugunov <
> > sergey.chugu...@gmail.com>
> > wrote:
> >
> > >  Hello folks,
> > >
> > > I found a reason why *IgniteSemaphoreExample* hangs when started twice
> > > without restarting a cluster; and it doesn't seem minor to me anymore.
> > >
> > > From here I'm going to refer to example's code so please have it
> opened.
> > >
> > > So, when the first instance of node running example code finishes and
> > > leaves the cluster, synchronization semaphore named
> > > "IgniteSemaphoreExample" goes to broken state on all other cluster
> nodes.
> > > If I restart example without restarting all nodes of the cluster, final
> > > *acquire *call on the semaphore on client side hangs because all other
> > > nodes treat it as broken and don't increase permits with their *release
> > > *calls
> > > on it.
> > >
> > > There is an interesting comment inside its *tryReleaseShared*
> > > implementation
> > > (BTW it is implemented in *GridCacheSemaphoreImpl*):
> > >
> > > "// If broken, return immediately, exception will be thrown anyway.
> > >  if (broken)
> > >return true;"
> > >
> > > It seems that no exceptions are thrown neither on client side calling
> > > *acquire
> > > *or on server side calling *release *methods on a broken semaphore.
> > >
> > > Does anybody know why it behaves in that way? Is it expected behavior
> at
> > > all and if yes where is it documented?
> > >
> > > Thanks,
> > > Sergey Chugunov.
> > >
> >
>
>
>
> --
> С уважением,
> Сергей Чугунов.
>

Re: IGNITE-4155 IgniteSemaphoreExample unexpected behavior

2016-11-10 Thread Vladisav Jelisavcic

Hi Sergey,

thanks for finding and submitting this bug!

Best regards,
Vladisav

On Thu, Nov 10, 2016 at 1:46 PM, Sergey Chugunov <sergey.chugu...@gmail.com>
wrote:

> Hello Vladisav,
>
> Thanks for confirmation!
>
> I created a JIRA <https://issues.apache.org/jira/browse/IGNITE-4209> to
> track this issue, feel free to edit it if it isn't descriptive enough.
>
> Thank you,
> Sergey.
>
> On Thu, Nov 10, 2016 at 9:44 AM, Vladisav Jelisavcic <vladis...@gmail.com>
> wrote:
>
> > Hi Sergey,
> >
> > you are right - I can reproduce this also.
> > It seems to me that this is caused because we treat the same both
> > EVT_NODE_LEFT and EVT_NODE_FAILED events.
> > In this case, node leaves the topology without failure, but fails to
> > release the semaphore before EVT_NODE_LEFT event occurs on other nodes,
> > this really is a bug.
> >
> > Thanks!
> > Vladisav
> >
> > On Wed, Nov 9, 2016 at 11:23 AM, Sergey Chugunov <
> > sergey.chugu...@gmail.com>
> > wrote:
> >
> > > Hello Vladisav,
> > >
> > > I found this behavior in a very simple environment: I had two nodes on
> my
> > > local machine started by *ExampleNodeStartup* class and another node
> > > started with *IgniteSemaphoreExample* class.
> > >
> > > No modifications were made to any code or configuration and I used
> latest
> > > version of code available in master branch.
> > > No node failures occurred during test execution as well.
> > >
> > > As far as I understood from short investigation synchronization
> semaphore
> > > of name "IgniteSemaphoreExample" goes to broken state when
> > > *IgniteSemaphoreExample* node normally finishes and disconnects from
> the
> > > cluster.
> > > After that reusing of this semaphore becomes impossible and leads to
> > > hanging of new nodes doing so.
> > >
> > > Can you reproduce this? If so I will submit a ticket and share with
> you.
> > >
> > > Thank you,
> > > Sergey.
> > >
> > >
> > > On Wed, Nov 9, 2016 at 10:55 AM, Vladisav Jelisavcic <
> > vladis...@gmail.com>
> > > wrote:
> > >
> > > > Hi Sergey,
> > > >
> > > > can you please provide more information?
> > > > Have you changed the example (if so, can you provide the changes you
> > > made?)
> > > > Is the example executed normally (without node failures)?
> > > >
> > > > In the example, semaphore is created in non-failover safe mode,
> > > > which means it is not safe to use it once it is broken (something
> like
> > > > CyclicBarrier in java.util.concurrent),
> > > > and the semaphore is preserved in spite of the first node failing (if
> > the
> > > > backups are configured),
> > > > so if the first node failed, then (broken) semaphore with the same
> name
> > > > should still be in the cache,
> > > > and this is expected behavior.
> > > >
> > > > If this is not the case (test was executed normally) then please
> > submit a
> > > > ticket describing more your setup,
> > > > how many nodes, how many backups configured, etc..
> > > >
> > > > Thanks!
> > > > Vladisav
> > > >
> > > > On Tue, Nov 8, 2016 at 10:37 AM, Sergey Chugunov <
> > > > sergey.chugu...@gmail.com>
> > > > wrote:
> > > >
> > > > >  Hello folks,
> > > > >
> > > > > I found a reason why *IgniteSemaphoreExample* hangs when started
> > twice
> > > > > without restarting a cluster; and it doesn't seem minor to me
> > anymore.
> > > > >
> > > > > From here I'm going to refer to example's code so please have it
> > > opened.
> > > > >
> > > > > So, when the first instance of node running example code finishes
> and
> > > > > leaves the cluster, synchronization semaphore named
> > > > > "IgniteSemaphoreExample" goes to broken state on all other cluster
> > > nodes.
> > > > > If I restart example without restarting all nodes of the cluster,
> > final
> > > > > *acquire *call on the semaphore on client side hangs because all
> > other
> > > > > nodes treat it as broken and don't increase permits with their
> > *release
> > > > > *calls
> > > > > on it.
> > > > >
> > > > > There is an interesting comment inside its *tryReleaseShared*
> > > > > implementation
> > > > > (BTW it is implemented in *GridCacheSemaphoreImpl*):
> > > > >
> > > > > "// If broken, return immediately, exception will be thrown anyway.
> > > > >  if (broken)
> > > > >return true;"
> > > > >
> > > > > It seems that no exceptions are thrown neither on client side
> calling
> > > > > *acquire
> > > > > *or on server side calling *release *methods on a broken semaphore.
> > > > >
> > > > > Does anybody know why it behaves in that way? Is it expected
> behavior
> > > at
> > > > > all and if yes where is it documented?
> > > > >
> > > > > Thanks,
> > > > > Sergey Chugunov.
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > С уважением,
> > > Сергей Чугунов.
> > >
> >
>

Re: [VOTE] Use Upsource for Code Review

2016-11-16 Thread Vladisav Jelisavcic

+1 (non-binding)

On Wed, Nov 16, 2016 at 6:15 PM, Denis Magda  wrote:

> +1
>
> —
> Denis
>
> > On Nov 16, 2016, at 2:08 AM, Pavel Tupitsyn 
> wrote:
> >
> > Following the discussion on Upsource [1],
> > I would like to call a vote on accepting it as our official code review
> > tool.
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> > This vote will go on for 5 days.
> >
> > [1] http://apache-ignite-developers.2346864.n4.nabble.
> > com/Code-Review-Tool-Proposal-Upsource-td12195.html
>
>

Re: IgniteSemaphore and failoverSafe flag

2016-11-01 Thread Vladisav Jelisavcic

Hi,

when failoverSafe == true, semaphore should silently redistribute the
permits acquired on the failing node.
If failoverSafe is set to false, exception is thrown to every node
attempting to acquire.

It seems to me that when the first instance left topology,
no backups were available (this is similar to:
https://issues.apache.org/jira/browse/IGNITE-3386).
This should be fixed (semaphore should be recreated when create==true, as
suggested by Denis in the ticket).

It should be a minor fix, will be ready for 1.8.

Best regards,
Vladisav

On Tue, Nov 1, 2016 at 5:41 PM, Andrey Gura  wrote:

> Hi all!
>
> Guys, could somebody explain semantic of failoverSafe flag in
> IgniteSemaphore. From my point of view the test below should work but it
> fails:
>
> public void testFailoverReleasePermits() throws Exception {
> Ignite ignite = grid(0);
>
> IgniteSemaphore sem = ignite.semaphore("sem", 1, true, true);
>
> sem.acquire(1);
>
> ignite.close();
>
> U.sleep(5000);
>
> ignite = grid(1);
>
> sem = ignite.semaphore("sem", 1, true, true);
>
> boolean acquire = sem.tryAcquire(1, 5000, TimeUnit.MILLISECONDS);
>
> assertTrue(acquire); // fails here
> }
>
> From my point of view permit should be available after the first ignite
> instance left topology.
>

Re: [VOTE] Apache Ignite 1.8.0 RC1

2016-12-06 Thread Vladisav Jelisavcic

+1 (non-binding)

On Tue, Dec 6, 2016 at 9:17 AM, Anton Vinogradov 
wrote:

> +1 (binding)
>
> On Tue, Dec 6, 2016 at 3:43 AM, Roman Shtykh 
> wrote:
>
> > +1 (binding)
> >
> > -Roman
> >
> >
> >
> >
> > On Tuesday, December 6, 2016 8:14 AM, Denis Magda 
> > wrote:
> > +1 (binding)
> >
> > —
> > Denis
> >
> >
> > > On Dec 5, 2016, at 7:22 AM, Vladimir Ozerov 
> > wrote:
> > >
> > > Hello,
> > >
> > > We have uploaded the 1.8.0 release candidate to
> > > *https://dist.apache.org/repos/dist/dev/ignite/1.8.0-rc1/
> > > *
> > >
> > > Tag name is
> > > 1.8.0-rc1
> > >
> > > This release includes the following changes:
> > >
> > > Ignite:
> > > * SQL: Added DML operations support (INSERT, UPDATE, DELETE, MERGE)
> > > * SQL: Improved DISTINCT keyword handling in aggregates
> > > * Hadoop: Added MapR distribution support
> > > * Visor: Improved SQL statistics
> > > * Added Redis protocol support
> > > * Added transactions deadlock detection
> > > * Many stability and fault-tolerance fixes
> > >
> > > Ignite.NET:
> > > * ASP.NET session state store provider
> > > * Entity Framework second level cache
> > > * Custom loggers support: NLog, Apache log4Net
> > >
> > > ODBC driver:
> > > * Added DML operations support
> > > * Added distributed joins support
> > > * Added DSN support
> > > * Performance improvements
> > >
> > > Complete list of closed issues:
> > > https://issues.apache.org/jira/issues/?jql=
> > > *project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%201.8%
> > 20AND%20status%20in%20(resolved%2C%20closed)*
> > >
> > > DEVNOTES
> > > *https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=
> > blob_plain;f=DEVNOTES.txt;hb=refs/tags/1.8.0-rc1
> > >  > blob_plain;f=DEVNOTES.txt;hb=refs/tags/1.8.0-rc1>*
> > >
> > > RELEASE NOTES
> > > *https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=
> > blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/1.8.0-rc1
> > >  > blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/1.8.0-rc1>*
> > >
> > > Please start voting.
> > >
> > > +1 - to accept Apache Ignite 1.8.0-rc1
> > > 0 - don't care either way
> > > -1 - DO NOT accept Apache Ignite 1.8.0-rc1 (explain why)
> > >
> > > This vote will go for 72 hours.
> > >
> > > Vladimir.
> >
>

Re: IgniteSemaphore and failoverSafe flag

2017-03-16 Thread Vladisav Jelisavcic

Hi everyone,

I agree with Val, he's got a point; recreating the lock doesn't seem
possible
(at least not the with the transactional cache lock/semaphore we have).
Is this re-create behavior really needed?

Best regards,
Vladisav



On Thu, Mar 16, 2017 at 8:34 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Guys,
>
> How does recreation of the lock helps? My understanding is that scenario is
> the following:
>
> 1. Client A creates and acquires a lock, and then starts to execute guarded
> logic.
> 2. Client B tries to acquire the same lock and parks to wait.
> 3. Before client A unlocks, all affinity nodes for the lock fail, lock
> disappears from the cache.
> 4. Client B fails with exception, recreates the lock, acquires it, and
> starts to execute guarded logic concurrently with client A.
>
> In my view this is wrong anyway, regardless of whether this happens
> silently or with an exception handled in user's code. Because this code
> doesn't have any way to know if client A still holds the lock or not.
>
> Am I missing something?
>
> -Val
>
> On Tue, Mar 14, 2017 at 10:14 AM, Dmitriy Setrakyan  >
> wrote:
>
> > On Tue, Mar 14, 2017 at 12:46 AM, Alexey Goncharuk <
> > alexey.goncha...@gmail.com> wrote:
> >
> > > >
> > > > Which user operation would result in exception? To my knowledge, user
> > may
> > > > already be holding the lock and not invoking any Ignite APIs, no?
> > > >
> > >
> > > Yes, this is exactly my point.
> > >
> > > Imagine that a node already holds a lock and another node is waiting
> for
> > > the lock. If all partition nodes leave the grid and the lock is
> > re-created,
> > > this second node will immediately acquire the lock and we will have two
> > > lock owners. I think in this case this second node (blocked on lock())
> > > should get an exception saying that the lock was lost (which is, by the
> > > way, the current behavior), and the first node should get an exception
> on
> > > unlock.
> > >
> >
> > Makes sense.
> >
>

Re: IgniteSemaphore and failoverSafe flag

2017-04-12 Thread Vladisav Jelisavcic

Hi Dmitry,

sure, I made a fix, take a look at the PR and the comments in the ticket.

Best regards,
Vladisav

On Tue, Apr 11, 2017 at 3:00 PM, Dmitry Karachentsev <
dkarachent...@gridgain.com> wrote:

> Hi Vladislav,
>
> Thanks for your contribution! But it seems doesn't fix related tickets, in
> particular [1].
> Could you please take a look?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-4173
>
> Thanks!
>
> 06.04.2017 16:27, Vladisav Jelisavcic пишет:
>
> Hey Dmitry,
>
> sorry for the late reply, I'll try to bake a pr later during the day.
>
> Best regards,
> Vladisav
>
>
>
> On Tue, Apr 4, 2017 at 11:05 AM, Dmitry Karachentsev <
> dkarachent...@gridgain.com> wrote:
>
>> Hi Vladislav,
>>
>> I see you're developing [1] for a while, did you have any chance to fix
>> it? If no, is there any estimate?
>>
>> [1] https://issues.apache.org/jira/browse/IGNITE-1977
>>
>> Thanks!
>>
>> -Dmitry.
>>
>>
>>
>> 20.03.2017 10:28, Alexey Goncharuk пишет:
>>
>> I think re-creation should be handled by a user who will make sure that
>>> nobody else is currently executing the guarded logic before the
>>> re-creation. This is exactly the same semantics as with
>>> BrokenBarrierException for j.u.c.CyclicBarrier.
>>>
>>> 2017-03-17 2:39 GMT+03:00 Vladisav Jelisavcic <vladis...@gmail.com>:
>>>
>>> Hi everyone,
>>>>
>>>> I agree with Val, he's got a point; recreating the lock doesn't seem
>>>> possible
>>>> (at least not the with the transactional cache lock/semaphore we have).
>>>> Is this re-create behavior really needed?
>>>>
>>>> Best regards,
>>>> Vladisav
>>>>
>>>>
>>>>
>>>> On Thu, Mar 16, 2017 at 8:34 PM, Valentin Kulichenko <
>>>> valentin.kuliche...@gmail.com> wrote:
>>>>
>>>> Guys,
>>>>>
>>>>> How does recreation of the lock helps? My understanding is that
>>>>> scenario
>>>>>
>>>> is
>>>>
>>>>> the following:
>>>>>
>>>>> 1. Client A creates and acquires a lock, and then starts to execute
>>>>>
>>>> guarded
>>>>
>>>>> logic.
>>>>> 2. Client B tries to acquire the same lock and parks to wait.
>>>>> 3. Before client A unlocks, all affinity nodes for the lock fail, lock
>>>>> disappears from the cache.
>>>>> 4. Client B fails with exception, recreates the lock, acquires it, and
>>>>> starts to execute guarded logic concurrently with client A.
>>>>>
>>>>> In my view this is wrong anyway, regardless of whether this happens
>>>>> silently or with an exception handled in user's code. Because this code
>>>>> doesn't have any way to know if client A still holds the lock or not.
>>>>>
>>>>> Am I missing something?
>>>>>
>>>>> -Val
>>>>>
>>>>> On Tue, Mar 14, 2017 at 10:14 AM, Dmitriy Setrakyan <
>>>>>
>>>> dsetrak...@apache.org
>>>>
>>>>> wrote:
>>>>>
>>>>> On Tue, Mar 14, 2017 at 12:46 AM, Alexey Goncharuk <
>>>>>> alexey.goncha...@gmail.com> wrote:
>>>>>>
>>>>>> Which user operation would result in exception? To my knowledge,
>>>>>>>>
>>>>>>> user
>>>>
>>>>> may
>>>>>>
>>>>>>> already be holding the lock and not invoking any Ignite APIs, no?
>>>>>>>>
>>>>>>>> Yes, this is exactly my point.
>>>>>>>
>>>>>>> Imagine that a node already holds a lock and another node is waiting
>>>>>>>
>>>>>> for
>>>>>
>>>>>> the lock. If all partition nodes leave the grid and the lock is
>>>>>>>
>>>>>> re-created,
>>>>>>
>>>>>>> this second node will immediately acquire the lock and we will have
>>>>>>>
>>>>>> two
>>>>
>>>>> lock owners. I think in this case this second node (blocked on
>>>>>>>
>>>>>> lock())
>>>>
>>>>> should get an exception saying that the lock was lost (which is, by
>>>>>>>
>>>>>> the
>>>>
>>>>> way, the current behavior), and the first node should get an
>>>>>>>
>>>>>> exception
>>>>
>>>>> on
>>>>>
>>>>>> unlock.
>>>>>>>
>>>>>>> Makes sense.
>>>>>>
>>>>>>
>>
>
>

Re: IgniteSemaphore and failoverSafe flag

2017-04-06 Thread Vladisav Jelisavcic

Hey Dmitry,

sorry for the late reply, I'll try to bake a pr later during the day.

Best regards,
Vladisav



On Tue, Apr 4, 2017 at 11:05 AM, Dmitry Karachentsev <
dkarachent...@gridgain.com> wrote:

> Hi Vladislav,
>
> I see you're developing [1] for a while, did you have any chance to fix
> it? If no, is there any estimate?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-1977
>
> Thanks!
>
> -Dmitry.
>
>
>
> 20.03.2017 10:28, Alexey Goncharuk пишет:
>
> I think re-creation should be handled by a user who will make sure that
>> nobody else is currently executing the guarded logic before the
>> re-creation. This is exactly the same semantics as with
>> BrokenBarrierException for j.u.c.CyclicBarrier.
>>
>> 2017-03-17 2:39 GMT+03:00 Vladisav Jelisavcic <vladis...@gmail.com>:
>>
>> Hi everyone,
>>>
>>> I agree with Val, he's got a point; recreating the lock doesn't seem
>>> possible
>>> (at least not the with the transactional cache lock/semaphore we have).
>>> Is this re-create behavior really needed?
>>>
>>> Best regards,
>>> Vladisav
>>>
>>>
>>>
>>> On Thu, Mar 16, 2017 at 8:34 PM, Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com> wrote:
>>>
>>> Guys,
>>>>
>>>> How does recreation of the lock helps? My understanding is that scenario
>>>>
>>> is
>>>
>>>> the following:
>>>>
>>>> 1. Client A creates and acquires a lock, and then starts to execute
>>>>
>>> guarded
>>>
>>>> logic.
>>>> 2. Client B tries to acquire the same lock and parks to wait.
>>>> 3. Before client A unlocks, all affinity nodes for the lock fail, lock
>>>> disappears from the cache.
>>>> 4. Client B fails with exception, recreates the lock, acquires it, and
>>>> starts to execute guarded logic concurrently with client A.
>>>>
>>>> In my view this is wrong anyway, regardless of whether this happens
>>>> silently or with an exception handled in user's code. Because this code
>>>> doesn't have any way to know if client A still holds the lock or not.
>>>>
>>>> Am I missing something?
>>>>
>>>> -Val
>>>>
>>>> On Tue, Mar 14, 2017 at 10:14 AM, Dmitriy Setrakyan <
>>>>
>>> dsetrak...@apache.org
>>>
>>>> wrote:
>>>>
>>>> On Tue, Mar 14, 2017 at 12:46 AM, Alexey Goncharuk <
>>>>> alexey.goncha...@gmail.com> wrote:
>>>>>
>>>>> Which user operation would result in exception? To my knowledge,
>>>>>>>
>>>>>> user
>>>
>>>> may
>>>>>
>>>>>> already be holding the lock and not invoking any Ignite APIs, no?
>>>>>>>
>>>>>>> Yes, this is exactly my point.
>>>>>>
>>>>>> Imagine that a node already holds a lock and another node is waiting
>>>>>>
>>>>> for
>>>>
>>>>> the lock. If all partition nodes leave the grid and the lock is
>>>>>>
>>>>> re-created,
>>>>>
>>>>>> this second node will immediately acquire the lock and we will have
>>>>>>
>>>>> two
>>>
>>>> lock owners. I think in this case this second node (blocked on
>>>>>>
>>>>> lock())
>>>
>>>> should get an exception saying that the lock was lost (which is, by
>>>>>>
>>>>> the
>>>
>>>> way, the current behavior), and the first node should get an
>>>>>>
>>>>> exception
>>>
>>>> on
>>>>
>>>>> unlock.
>>>>>>
>>>>>> Makes sense.
>>>>>
>>>>>
>

Re: IgniteSemaphore and failoverSafe flag

2017-04-14 Thread Vladisav Jelisavcic

Hi Dmitry,

it looks to me that this test is not valid - after the semaphore 2 fails
the permits are redistributed
so the expected number of permits should really be 20 not 10. Do you agree?

I guess before latest fix this test was (incorrectly) passing because
permits weren't released properly.

What do you think?

On Fri, Apr 14, 2017 at 11:27 AM, Dmitry Karachentsev <
dkarachent...@gridgain.com> wrote:

> Hi Vladislav,
>
> It looks like after fix was merged these tests [1] started failing. Could
> you please take a look?
>
> [1] http://ci.ignite.apache.org/viewLog.html?buildId=544238;
> tab=buildResultsDiv=IgniteTests_IgniteBinaryObjectsDataStrucut
> ures
>
> Thanks!
>
> -Dmitry.
>
> 13.04.2017 16:15, Dmitry Karachentsev пишет:
>
> Thanks a lot!
>
> 12.04.2017 16:35, Vladisav Jelisavcic пишет:
>
> Hi Dmitry,
>
> sure, I made a fix, take a look at the PR and the comments in the ticket.
>
> Best regards,
> Vladisav
>
> On Tue, Apr 11, 2017 at 3:00 PM, Dmitry Karachentsev <
> dkarachent...@gridgain.com> wrote:
>
>> Hi Vladislav,
>>
>> Thanks for your contribution! But it seems doesn't fix related tickets,
>> in particular [1].
>> Could you please take a look?
>>
>> [1] https://issues.apache.org/jira/browse/IGNITE-4173
>>
>> Thanks!
>>
>> 06.04.2017 16:27, Vladisav Jelisavcic пишет:
>>
>> Hey Dmitry,
>>
>> sorry for the late reply, I'll try to bake a pr later during the day.
>>
>> Best regards,
>> Vladisav
>>
>>
>>
>> On Tue, Apr 4, 2017 at 11:05 AM, Dmitry Karachentsev <
>> dkarachent...@gridgain.com> wrote:
>>
>>> Hi Vladislav,
>>>
>>> I see you're developing [1] for a while, did you have any chance to fix
>>> it? If no, is there any estimate?
>>>
>>> [1] https://issues.apache.org/jira/browse/IGNITE-1977
>>>
>>> Thanks!
>>>
>>> -Dmitry.
>>>
>>>
>>>
>>> 20.03.2017 10:28, Alexey Goncharuk пишет:
>>>
>>> I think re-creation should be handled by a user who will make sure that
>>>> nobody else is currently executing the guarded logic before the
>>>> re-creation. This is exactly the same semantics as with
>>>> BrokenBarrierException for j.u.c.CyclicBarrier.
>>>>
>>>> 2017-03-17 2:39 GMT+03:00 Vladisav Jelisavcic <vladis...@gmail.com>:
>>>>
>>>> Hi everyone,
>>>>>
>>>>> I agree with Val, he's got a point; recreating the lock doesn't seem
>>>>> possible
>>>>> (at least not the with the transactional cache lock/semaphore we have).
>>>>> Is this re-create behavior really needed?
>>>>>
>>>>> Best regards,
>>>>> Vladisav
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 16, 2017 at 8:34 PM, Valentin Kulichenko <
>>>>> valentin.kuliche...@gmail.com> wrote:
>>>>>
>>>>> Guys,
>>>>>>
>>>>>> How does recreation of the lock helps? My understanding is that
>>>>>> scenario
>>>>>>
>>>>> is
>>>>>
>>>>>> the following:
>>>>>>
>>>>>> 1. Client A creates and acquires a lock, and then starts to execute
>>>>>>
>>>>> guarded
>>>>>
>>>>>> logic.
>>>>>> 2. Client B tries to acquire the same lock and parks to wait.
>>>>>> 3. Before client A unlocks, all affinity nodes for the lock fail, lock
>>>>>> disappears from the cache.
>>>>>> 4. Client B fails with exception, recreates the lock, acquires it, and
>>>>>> starts to execute guarded logic concurrently with client A.
>>>>>>
>>>>>> In my view this is wrong anyway, regardless of whether this happens
>>>>>> silently or with an exception handled in user's code. Because this
>>>>>> code
>>>>>> doesn't have any way to know if client A still holds the lock or not.
>>>>>>
>>>>>> Am I missing something?
>>>>>>
>>>>>> -Val
>>>>>>
>>>>>> On Tue, Mar 14, 2017 at 10:14 AM, Dmitriy Setrakyan <
>>>>>>
>>>>> dsetrak...@apache.org
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> On Tue, Mar 14, 2017 at 12:46 AM, Alexey Goncharuk <
>>>>>>> alexey.goncha...@gmail.com> wrote:
>>>>>>>
>>>>>>> Which user operation would result in exception? To my knowledge,
>>>>>>>>>
>>>>>>>> user
>>>>>
>>>>>> may
>>>>>>>
>>>>>>>> already be holding the lock and not invoking any Ignite APIs, no?
>>>>>>>>>
>>>>>>>>> Yes, this is exactly my point.
>>>>>>>>
>>>>>>>> Imagine that a node already holds a lock and another node is waiting
>>>>>>>>
>>>>>>> for
>>>>>>
>>>>>>> the lock. If all partition nodes leave the grid and the lock is
>>>>>>>>
>>>>>>> re-created,
>>>>>>>
>>>>>>>> this second node will immediately acquire the lock and we will have
>>>>>>>>
>>>>>>> two
>>>>>
>>>>>> lock owners. I think in this case this second node (blocked on
>>>>>>>>
>>>>>>> lock())
>>>>>
>>>>>> should get an exception saying that the lock was lost (which is, by
>>>>>>>>
>>>>>>> the
>>>>>
>>>>>> way, the current behavior), and the first node should get an
>>>>>>>>
>>>>>>> exception
>>>>>
>>>>>> on
>>>>>>
>>>>>>> unlock.
>>>>>>>>
>>>>>>>> Makes sense.
>>>>>>>
>>>>>>>
>>>
>>
>>
>
>
>

Re: IgniteSemaphore and failoverSafe flag

2017-04-14 Thread Vladisav Jelisavcic

Hmm, I cannot reproduce this behavior locally,
my guess is interrupt flag is not always cleared properly in
#GridCacheSemaphore.acquire method (but it doesn't have anything to do with
latest fix)

Can you make it reproducible?

On Fri, Apr 14, 2017 at 2:46 PM, Dmitry Karachentsev <
dkarachent...@gridgain.com> wrote:

> Vladislav,
>
> One more thing, This test [1] started failing on semaphore close when this
> fix [2] was introduced.
> Could you check it please?
>
> [1] http://ci.ignite.apache.org/viewLog.html?buildId=547151;
> tab=buildResultsDiv=IgniteTests_IgniteDataStrucutures#
> testNameId-979977708202725050
> [2] https://issues.apache.org/jira/browse/IGNITE-1977
>
> Thanks!
>
> 14.04.2017 15:27, Dmitry Karachentsev пишет:
>
> Vladislav,
>
> Yep, you're right. I'll fix it.
>
> Thanks!
>
> 14.04.2017 15:18, Vladisav Jelisavcic пишет:
>
> Hi Dmitry,
>
> it looks to me that this test is not valid - after the semaphore 2 fails
> the permits are redistributed
> so the expected number of permits should really be 20 not 10. Do you agree?
>
> I guess before latest fix this test was (incorrectly) passing because
> permits weren't released properly.
>
> What do you think?
>
> On Fri, Apr 14, 2017 at 11:27 AM, Dmitry Karachentsev <
> dkarachent...@gridgain.com> wrote:
>
>> Hi Vladislav,
>>
>> It looks like after fix was merged these tests [1] started failing. Could
>> you please take a look?
>>
>> [1] http://ci.ignite.apache.org/viewLog.html?buildId=544238=
>> buildResultsDiv=IgniteTests_IgniteBinaryObject
>> sDataStrucutures
>>
>> Thanks!
>>
>> -Dmitry.
>>
>> 13.04.2017 16:15, Dmitry Karachentsev пишет:
>>
>> Thanks a lot!
>>
>> 12.04.2017 16:35, Vladisav Jelisavcic пишет:
>>
>> Hi Dmitry,
>>
>> sure, I made a fix, take a look at the PR and the comments in the ticket.
>>
>> Best regards,
>> Vladisav
>>
>> On Tue, Apr 11, 2017 at 3:00 PM, Dmitry Karachentsev <
>> dkarachent...@gridgain.com> wrote:
>>
>>> Hi Vladislav,
>>>
>>> Thanks for your contribution! But it seems doesn't fix related tickets,
>>> in particular [1].
>>> Could you please take a look?
>>>
>>> [1] https://issues.apache.org/jira/browse/IGNITE-4173
>>>
>>> Thanks!
>>>
>>> 06.04.2017 16:27, Vladisav Jelisavcic пишет:
>>>
>>> Hey Dmitry,
>>>
>>> sorry for the late reply, I'll try to bake a pr later during the day.
>>>
>>> Best regards,
>>> Vladisav
>>>
>>>
>>>
>>> On Tue, Apr 4, 2017 at 11:05 AM, Dmitry Karachentsev <
>>> dkarachent...@gridgain.com> wrote:
>>>
>>>> Hi Vladislav,
>>>>
>>>> I see you're developing [1] for a while, did you have any chance to fix
>>>> it? If no, is there any estimate?
>>>>
>>>> [1] https://issues.apache.org/jira/browse/IGNITE-1977
>>>>
>>>> Thanks!
>>>>
>>>> -Dmitry.
>>>>
>>>>
>>>>
>>>> 20.03.2017 10:28, Alexey Goncharuk пишет:
>>>>
>>>> I think re-creation should be handled by a user who will make sure that
>>>>> nobody else is currently executing the guarded logic before the
>>>>> re-creation. This is exactly the same semantics as with
>>>>> BrokenBarrierException for j.u.c.CyclicBarrier.
>>>>>
>>>>> 2017-03-17 2:39 GMT+03:00 Vladisav Jelisavcic <vladis...@gmail.com>:
>>>>>
>>>>> Hi everyone,
>>>>>>
>>>>>> I agree with Val, he's got a point; recreating the lock doesn't seem
>>>>>> possible
>>>>>> (at least not the with the transactional cache lock/semaphore we
>>>>>> have).
>>>>>> Is this re-create behavior really needed?
>>>>>>
>>>>>> Best regards,
>>>>>> Vladisav
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 16, 2017 at 8:34 PM, Valentin Kulichenko <
>>>>>> valentin.kuliche...@gmail.com> wrote:
>>>>>>
>>>>>> Guys,
>>>>>>>
>>>>>>> How does recreation of the lock helps? My understanding is that
>>>>>>> scenario
>>>>>>>
>>>>>> is
>>>>>>
>>>>>>> the following:
>>>>>>

Re: Ignite ML, next steps (IGNITE-5029)

2017-04-23 Thread Vladisav Jelisavcic

Hi,

excellent job so far!

What about classification algorithms?
If everyone agrees, let's start by adding logistic regression to the list:
https://issues.apache.org/jira/browse/IGNITE-5059


Best regards,
Vladisav


On Fri, Apr 21, 2017 at 10:00 PM, Nikita Ivanov  wrote:

> Sounds like a good plan to tackle for 1.0 GA release sometime in the
> future.
>
> --
> Nikita Ivanov
>
>
> On Fri, Apr 21, 2017 at 9:43 AM, Yury Babak  wrote:
>
> > Guys,
> >
> > Since the first version of Ignite ML module was merged into ignite 2.0 we
> > want to discuss our next steps.
> >
> > Currently we think about 3 big areas to explore:
> >
> > 1) Regression and clustering algorithms.
> > 2) Deep Learning/Neural Networks stuff.
> > 3) DSL/scripting support.
> >
> > Suggestions/thoughts about these topics (or something else which you
> think
> > we have missed) are welcome here as well as in IGNITE-5029.
> >
> > Some details about above topics.
> >
> > * First draft of ordinary least squares linear regression is in progress
> > (by
> > Artem, IGNITE-5012).
> > * Deep learning/other NN stuff: currently Artem is investigating existing
> > frameworks like Tensorflow/Encog/etc to find out if we can integrate with
> > them somehow or at least define the scope/ideas for API of DL/NN
> > functionality we need.
> > * Also we think about using Java 8 Nashorn as script engine and
> possibility
> > of build R-like DSL (mostly by me).
> >
> > Thanks,
> > Yury Babak.
> >
> >
> >
> >
> >
> > --
> > View this message in context: http://apache-ignite-
> > developers.2346864.n4.nabble.com/Ignite-ML-next-steps-
> > IGNITE-5029-tp17096.html
> > Sent from the Apache Ignite Developers mailing list archive at
> Nabble.com.
> >
>

Re: Ignite ML Models improvements

2017-10-16 Thread Vladisav Jelisavcic

Hi Artem,

I agree, it is not supported in many frameworks;
on the other hand, Spark MLlib supports it [1].

I think it is good thing to check with users if there is a need for this,
since we are already on the topic of model importing/exporting.

Best regards,
Vladisav

[1] https://spark.apache.org/docs/2.1.1/mllib-pmml-model-export.html

On Mon, Oct 16, 2017 at 2:57 PM, ArtemM  wrote:

> Hi, Vladislav,
>
> I'm not familiar with PMML, but quick googling has shown that Tensorflow,
> Keras, DL4j and some other major contemporary ML frameworks do not have
> support of it (at least native). So the question is why should we include
> it, can you please elaborate?
>
> Best regards, Artem.
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

Re: Ignite ML Models improvements

2017-10-16 Thread Vladisav Jelisavcic

Hi Yury,

since we're already on topic for importing/exporting models,
just as a thought: maybe we should add support for PMML [1] [2]?

Best regards,
Vladisav

[1] http://dmg.org/pmml/v4-1/GeneralStructure.html
[2] https://github.com/jpmml/jpmml-model

On Mon, Oct 16, 2017 at 2:20 PM, Yury Babak  wrote:

> Hi all.
>
> I want to improve our models. Currently our models can predict result and
> be
> combined with other models, thats all. So I will add import/export
> functionality, check serialization performance and add some related tests.
>
> And also I want to ask community - may be we need something else from our
> models?
>
> Thanks,
> Yury
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

Re: Ignite Semaphore Bug 7090

2018-01-20 Thread Vladisav Jelisavcic

Hi Tim,

I reviewed your contribution and left you some comments on the pr.
Thanks!

Vladisav

On Wed, Jan 17, 2018 at 10:14 PM, Vladisav Jelisavcic <vladis...@gmail.com>
wrote:

> Hi Tim,
>
> thank you for the contribution!
> I'll do the review soon and let you know.
>
>
>
> On Wed, Jan 17, 2018 at 8:56 AM, Yakov Zhdanov <yzhda...@apache.org>
> wrote:
>
>> Thanks Tim! I hope Vlad can review your patch. If this does not happen in
>> 2-3 days I will take a look. Can you please let me know on weekend if I
>> need to?
>>
>> --Yakov
>>
>> 2018-01-16 23:36 GMT+03:00 Tim Onyschak <tonysc...@gmail.com>:
>>
>> > Hey all,
>> >
>> > I created a patch and posted to user group, was told feed back would be
>> > left on the jira. I wanted to see if we could get a fix in with 2.4,
>> could
>> > somebody please review.
>> >
>> > http://apache-ignite-users.70518.x6.nabble.com/Semaphore-
>> > Stuck-when-no-acquirers-to-assign-permit-td18639.html
>> >
>> > https://issues.apache.org/jira/browse/IGNITE-7090
>> >
>> > https://github.com/apache/ignite/pull/3138
>> >
>> > Thanks,
>> > Tim
>> >
>>
>
>

Re: Ignite Semaphore Bug 7090

2018-01-25 Thread Vladisav Jelisavcic

Hi Tim,

thank you for delving deeper into the problem,
I left you a comment/question on the JIRA.

Best regards,
Vladisav

On Tue, Jan 23, 2018 at 3:00 PM, Vladisav Jelisavcic <vladis...@gmail.com>
wrote:

> Hi Tim,
>
> thanks for the update! I left you a comment on Jira.
>
> Best regards,
> Vladisav
>
> On Mon, Jan 22, 2018 at 6:17 PM, Tim Onyschak <tonysc...@gmail.com> wrote:
>
>> Hey Vladisav,
>>
>> I implemented your requests. Take a look, specifically, i created an
>> interface to encapsulate the NodeUpdates and let
>> the DataStructuresProcessor handle the execution by checking for one type
>> as opposed to multiple if checks. In this case it checks for 
>> GridCacheNodeUpdate
>> instance and executes onNodeRemoved. Let me know what you think.
>>
>> Thanks,
>> Tim
>>
>>
>>
>> On Sat, Jan 20, 2018 at 8:10 AM, Vladisav Jelisavcic <vladis...@gmail.com
>> > wrote:
>>
>>> Hi Tim,
>>>
>>> I reviewed your contribution and left you some comments on the pr.
>>> Thanks!
>>>
>>> Vladisav
>>>
>>> On Wed, Jan 17, 2018 at 10:14 PM, Vladisav Jelisavcic <
>>> vladis...@gmail.com> wrote:
>>>
>>>> Hi Tim,
>>>>
>>>> thank you for the contribution!
>>>> I'll do the review soon and let you know.
>>>>
>>>>
>>>>
>>>> On Wed, Jan 17, 2018 at 8:56 AM, Yakov Zhdanov <yzhda...@apache.org>
>>>> wrote:
>>>>
>>>>> Thanks Tim! I hope Vlad can review your patch. If this does not happen
>>>>> in
>>>>> 2-3 days I will take a look. Can you please let me know on weekend if I
>>>>> need to?
>>>>>
>>>>> --Yakov
>>>>>
>>>>> 2018-01-16 23:36 GMT+03:00 Tim Onyschak <tonysc...@gmail.com>:
>>>>>
>>>>> > Hey all,
>>>>> >
>>>>> > I created a patch and posted to user group, was told feed back would
>>>>> be
>>>>> > left on the jira. I wanted to see if we could get a fix in with 2.4,
>>>>> could
>>>>> > somebody please review.
>>>>> >
>>>>> > http://apache-ignite-users.70518.x6.nabble.com/Semaphore-
>>>>> > Stuck-when-no-acquirers-to-assign-permit-td18639.html
>>>>> >
>>>>> > https://issues.apache.org/jira/browse/IGNITE-7090
>>>>> >
>>>>> > https://github.com/apache/ignite/pull/3138
>>>>> >
>>>>> > Thanks,
>>>>> > Tim
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
>

Re: Semaphore Stuck when no acquirers to assign permit

2018-02-19 Thread Vladisav Jelisavcic

Hi Alexey,

I already reviewed it, but wanted to see the resolution of IGNITE-6454
first before I merge.

Thanks,
Vladisav


On Fri, Feb 16, 2018 at 12:39 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Hi Vladislav,
>
> Can you please finalize the review? I would like to include the fix in one
> of the nightly Ignite builds for my own project.
>
> Thanks.
> --AG
>
> 2018-02-01 4:47 GMT+03:00 Dmitriy Setrakyan :
>
>> Hi Tim, Vlad,
>>
>> Any update on this ticket? I looked inside, but cannot understand the
>> status.
>>
>> Thanks,
>> D.
>>
>> -- Forwarded message --
>> From: Denis Magda 
>> Date: Fri, Jan 19, 2018 at 9:14 PM
>> Subject: Re: Semaphore Stuck when no acquirers to assign permit
>> To: u...@ignite.apache.org, dev@ignite.apache.org
>>
>>
>> Igniters,
>>
>> Who can check out Tim’s fix for the semaphore?
>>
>> pull request: https://github.com/apache/ignite/pull/3138 <
>> https://github.com/apache/ignite/pull/3138>
>> jira: https://issues.apache.org/jira/browse/IGNITE-7090 <
>> https://issues.apache.org/jira/browse/IGNITE-7090>
>>
>> —
>> Denis
>>
>> > On Jan 15, 2018, at 12:02 PM, Timay  wrote:
>> >
>> > I saw a release date set for 2.4 but have not had any feedback on the
>> jira so
>> > i wanted to check in on this. Can this make it into the 2.4 release?
>> >
>> > Thanks
>> > Tim
>> >
>> >
>> >
>> > --
>> > Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>
>
>

Re: Ignite Semaphore Bug 7090

2018-01-23 Thread Vladisav Jelisavcic

Hi Tim,

thanks for the update! I left you a comment on Jira.

Best regards,
Vladisav

On Mon, Jan 22, 2018 at 6:17 PM, Tim Onyschak <tonysc...@gmail.com> wrote:

> Hey Vladisav,
>
> I implemented your requests. Take a look, specifically, i created an
> interface to encapsulate the NodeUpdates and let
> the DataStructuresProcessor handle the execution by checking for one type
> as opposed to multiple if checks. In this case it checks for 
> GridCacheNodeUpdate
> instance and executes onNodeRemoved. Let me know what you think.
>
> Thanks,
> Tim
>
>
>
> On Sat, Jan 20, 2018 at 8:10 AM, Vladisav Jelisavcic <vladis...@gmail.com>
> wrote:
>
>> Hi Tim,
>>
>> I reviewed your contribution and left you some comments on the pr.
>> Thanks!
>>
>> Vladisav
>>
>> On Wed, Jan 17, 2018 at 10:14 PM, Vladisav Jelisavcic <
>> vladis...@gmail.com> wrote:
>>
>>> Hi Tim,
>>>
>>> thank you for the contribution!
>>> I'll do the review soon and let you know.
>>>
>>>
>>>
>>> On Wed, Jan 17, 2018 at 8:56 AM, Yakov Zhdanov <yzhda...@apache.org>
>>> wrote:
>>>
>>>> Thanks Tim! I hope Vlad can review your patch. If this does not happen
>>>> in
>>>> 2-3 days I will take a look. Can you please let me know on weekend if I
>>>> need to?
>>>>
>>>> --Yakov
>>>>
>>>> 2018-01-16 23:36 GMT+03:00 Tim Onyschak <tonysc...@gmail.com>:
>>>>
>>>> > Hey all,
>>>> >
>>>> > I created a patch and posted to user group, was told feed back would
>>>> be
>>>> > left on the jira. I wanted to see if we could get a fix in with 2.4,
>>>> could
>>>> > somebody please review.
>>>> >
>>>> > http://apache-ignite-users.70518.x6.nabble.com/Semaphore-
>>>> > Stuck-when-no-acquirers-to-assign-permit-td18639.html
>>>> >
>>>> > https://issues.apache.org/jira/browse/IGNITE-7090
>>>> >
>>>> > https://github.com/apache/ignite/pull/3138
>>>> >
>>>> > Thanks,
>>>> > Tim
>>>> >
>>>>
>>>
>>>
>>
>

[jira] [Created] (IGNITE-2399) Add asynchronous acquire to IgniteSemaphore

2016-01-18 Thread Vladisav Jelisavcic (JIRA)

Vladisav Jelisavcic created IGNITE-2399:
---

 Summary: Add asynchronous acquire to IgniteSemaphore
 Key: IGNITE-2399
 URL: https://issues.apache.org/jira/browse/IGNITE-2399
 Project: Ignite
  Issue Type: Improvement
  Components: data structures
Reporter: Vladisav Jelisavcic
 Fix For: 1.6


Usually a permit acquisition is followed by an action, followed by a release of 
the permit. A simple enhancement to the existing Semaphore API can be made that 
enables asynchronous acquire:

 IgniteFuture acquireAndExecute(Callable action, int numPermits);

The method would immediately return a future to be later completed by the 
action's result. Permits are to be released after the future is completed.



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

[jira] [Created] (IGNITE-2735) Interrupt all acquires on local node after ignite.close

2016-02-29 Thread Vladisav Jelisavcic (JIRA)

Vladisav Jelisavcic created IGNITE-2735:
---

 Summary: Interrupt all acquires on local node after ignite.close
 Key: IGNITE-2735
 URL: https://issues.apache.org/jira/browse/IGNITE-2735
 Project: Ignite
  Issue Type: Bug
  Components: data structures
Affects Versions: 1.6
Reporter: Vladisav Jelisavcic
 Fix For: 1.5.0.final


"acquire" method should throw an exception when semaphore is no longer 
accessible when node is stopped.



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

[jira] [Created] (IGNITE-2768) Public API for data structures should be guarded from being invoked after node is stopped

2016-03-06 Thread Vladisav Jelisavcic (JIRA)

Vladisav Jelisavcic created IGNITE-2768:
---

 Summary: Public API for data structures should be guarded from 
being invoked after node is stopped
 Key: IGNITE-2768
 URL: https://issues.apache.org/jira/browse/IGNITE-2768
 Project: Ignite
  Issue Type: Bug
  Components: data structures
Affects Versions: 1.6
Reporter: Vladisav Jelisavcic
Priority: Minor
 Fix For: 1.5.0.final


For such functionality we have GridKernalGateway, which guards all public API 
calls from being invoked after node is stopped. Public method implementations 
should be surrounded with ctx.gateway().readLock() and 
ctx.gateway().readUnlock(). As an example see GridExecutorService.
This ticket is based on conversation: 
[https://issues.apache.org/jira/browse/IGNITE-2735?focusedCommentId=15181493=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15181493]




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

[jira] [Created] (IGNITE-5059) Implement logistic regression

2017-04-23 Thread Vladisav Jelisavcic (JIRA)

Vladisav Jelisavcic created IGNITE-5059:
---

 Summary: Implement logistic regression 
 Key: IGNITE-5059
 URL: https://issues.apache.org/jira/browse/IGNITE-5059
 Project: Ignite
  Issue Type: New Feature
  Components: ml
Reporter: Vladisav Jelisavcic


Implement logistic regression using ignite ml.math. Model should be able to 
incorporate L1 and L2 regularization. 

Model should also work with stochastic gradient descent (SGD) as well as batch 
and mini-batch gradient descent optimization algorithms.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

41 matches

Mail list logo