Re: JCache dependency

[Dmitriy Setrakyan]

Romain, I am not sure what you mean by not having access to TCK. Are you
talking about validating compatibility with JCAche using the TCK [1]? In
this case, Apache Ignite does pass the TCK. Moreover, the TCK seems to be
licensed under Apache 2.0 [2]. Can you please explain?

[1] https://github.com/jsr107/jsr107tck
[2] https://github.com/jsr107/jsr107tck/blob/master/LICENSE.txt

On Sun, Mar 27, 2016 at 2:35 AM, Romain Manni-Bucau 
wrote:

> Alpha cause asf doesnt have oracle tck so we cant validate binary compat
> but it targets jcache 1.0. More a legal thing than anything else. If you
> have access to tck and can validate the binaries we can move on 1.0
> Le 27 mars 2016 00:21, "Dmitriy Setrakyan"  a
> écrit :
>
> > Hi Romain,
> >
> > The only issue I see is the version. JSR107 spec is on version 1.0.0 [1],
> > while the Geronimo JCache jar is on version 1.0-alpha-1.
> >
> > Any chance you can upgrade the version?
> >
> > [1] https://github.com/jsr107/jsr107spec/tree/v1.0.0
> >
> > D.
> >
> > On Sat, Mar 26, 2016 at 1:36 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > > wrote:
> >
> >> Hi Dmitriy,
> >>
> >> why not reusing geronimo jar? Generally @apache spec are owned by
> >> geronimo and reused as much as possible using geronimo as umbrella
> >> spec project. What's the issue you hit?
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >>
> >>
> >> 2016-03-26 21:20 GMT+01:00 Dmitriy Setrakyan :
> >> > Sorry, this is the JCache maven dependency I was referring to:
> >> >
> >>
> http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-jcache_1.0_spec
> >> >
> >> >
> >> > On Sat, Mar 26, 2016 at 1:18 PM, Dmitriy Setrakyan <
> >> dsetrak...@apache.org>
> >> > wrote:
> >> >>
> >> >> Hello Geronimo community!
> >> >>
> >> >> I have noticed that Geronimo implements JCache spec and is using its
> >> own
> >> >> JCache library hosted in Apache maven and licensed under Apache 2.0
> >> license
> >> >> [1].
> >> >>
> >> >> We, in Apache Ignite community also have implemented JCache
> >> specification
> >> >> and would like to do something similar. Do you know what steps do we
> >> need to
> >> >> take in order to have the latest JCache spec version licensed under
> >> Apache
> >> >> 2.0?
> >> >>
> >> >> Thanks,
> >> >> Dmitriy Setrakyan
> >> >> Apache Ignite, PMC chair
> >> >
> >> >
> >>
> >
> >
>

Re: JCache dependency

[Romain Manni-Bucau]

Alpha cause asf doesnt have oracle tck so we cant validate binary compat
but it targets jcache 1.0. More a legal thing than anything else. If you
have access to tck and can validate the binaries we can move on 1.0
Le 27 mars 2016 00:21, "Dmitriy Setrakyan"  a écrit :

> Hi Romain,
>
> The only issue I see is the version. JSR107 spec is on version 1.0.0 [1],
> while the Geronimo JCache jar is on version 1.0-alpha-1.
>
> Any chance you can upgrade the version?
>
> [1] https://github.com/jsr107/jsr107spec/tree/v1.0.0
>
> D.
>
> On Sat, Mar 26, 2016 at 1:36 PM, Romain Manni-Bucau  > wrote:
>
>> Hi Dmitriy,
>>
>> why not reusing geronimo jar? Generally @apache spec are owned by
>> geronimo and reused as much as possible using geronimo as umbrella
>> spec project. What's the issue you hit?
>>
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>>
>>
>> 2016-03-26 21:20 GMT+01:00 Dmitriy Setrakyan :
>> > Sorry, this is the JCache maven dependency I was referring to:
>> >
>> http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-jcache_1.0_spec
>> >
>> >
>> > On Sat, Mar 26, 2016 at 1:18 PM, Dmitriy Setrakyan <
>> dsetrak...@apache.org>
>> > wrote:
>> >>
>> >> Hello Geronimo community!
>> >>
>> >> I have noticed that Geronimo implements JCache spec and is using its
>> own
>> >> JCache library hosted in Apache maven and licensed under Apache 2.0
>> license
>> >> [1].
>> >>
>> >> We, in Apache Ignite community also have implemented JCache
>> specification
>> >> and would like to do something similar. Do you know what steps do we
>> need to
>> >> take in order to have the latest JCache spec version licensed under
>> Apache
>> >> 2.0?
>> >>
>> >> Thanks,
>> >> Dmitriy Setrakyan
>> >> Apache Ignite, PMC chair
>> >
>> >
>>
>
>

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

[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  wrote:

> Vlad, can you please check my comments again?
>
> --Yakov
>
> 2016-03-18 17:57 GMT+03:00 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 
> > 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 :
> > >
> > > > 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 :
> > > >
> > > >> 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  >:
> > > >>
> > > >>> 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: Improving Ignite window processing support

[Roman Shtykh]

Dmitriy,
Honestly I was thinking only of window processing to cover only this specific 
area. But I think looking at reactive streams makes sense and window processing 
can be implemented within reactive streams with all three delivery guarantee 
semantics (starting with the easiest two).
Also I am interested in working on it. I will create a JIRA ticket for this and 
may have many questions ;)
-Roman
 

On Sunday, March 27, 2016 5:03 AM, Dmitriy Setrakyan 
 wrote:
 

 Roman,

This is an excellent idea!

The API you are suggesting is very close to the reactive streams APIs [1],
so my suggestion would be to simply implement that API.

Another thing to focus on would be to provide guarantees:
- at least once
- at most once
- exactly once

I am not suggesting that we do it all in one step, but it would help to
identify what will be supported in the first iteration.

Do you mind taking a first step at this? We can discuss all questions
either here or in the chat room.

[1] http://www.reactive-streams.org/

D.

On Fri, Mar 25, 2016 at 8:08 PM, Murthy Kakarlamudi 
wrote:

> Thanks for thinking about this feature. Due to lack of this feature, in our
> application we are currently planning to have some Timer based classes
> query the cache, perform aggregations and send the events to all the
> listeners.
> Having this feature built in into Ignite certainly helps.
>
> Satya.
> On Mar 25, 2016 10:38 PM, "Roman Shtykh" 
> wrote:
>
> > Igniters,
> > I was thinking about improving Ignite window processing support so that
> > queries for windowed data is not user-initiated (which can have timing
> > issues) but rather event-driven, similar to ContinuousQuery but being
> able
> > to fire size-based or time-based entry windows to the listening client.
> > Some thougths on implementation:1. Guarantee all window events go to the
> > same partition (user will need to specify it as a windowed cache). Maybe
> it
> > can be rather implemented by extending IgniteQueue?2. Set a trigger on
> > cache, which will listen to eviction (in case of size-based windowed
> cache)
> > or expiration (time-based cache) events of the cache and fire entries.
> > It has to be exposed to the user by some API, very roughly something
> > likeIgniteStream is = IgniteStream.on(cache).with(windowingType,
> > filterPredidate).aggregate(aggFunc)is.run() // to continuously return
> > windowed results
> > where windowingType is time/size/session-based windows, aggFunc is
> > sum/min/max/etc. or user-specified.
> > It can be an experimental feature and I think it is a useful API to
> > enforce our stream processing, but I would like to know your opinion. Do
> > you think such API is needed? I have a limited knowledge of Ignite
> > internals -- any other ideas on the implementation?
> > For your reference,
> > https://flink.apache.org/news/2015/12/04/Introducing-windows.html is a
> > good introduction on windows processing.
> > -Roman
> >
> > P.S. Other things like operator/event/ingress time but has to be
> > considered for the implementation are omitted.
> >
>