6:48 p.m.
Hello all,
I have been working with notifications and most recently I have come
to look into events generated when a new entry is created. Now
normally I would just expect a CacheEntryCreatedEvent to be raised.
However we currently raise a CacheEntryModifiedEvent event and then a
CacheEntryCreatedEvent. I notice that there are comments around the
code saying that tests require both to be fired.
I am wondering if anyone has an objection to only raising a
CacheEntryCreatedEvent on a new cache entry being created. Does
anyone know why we raise both currently? Was it just so the
PutKeyValueCommand could more ignorantly just raise the
CacheEntryModified pre Event?
Any input would be appreciated, Thanks.
- Will
6:54 p.m.
On Jan 23, 2014, at 5:48 PM, William Burns <mudokonman(a)gmail.com> wrote:
Hello all,
I have been working with notifications and most recently I have come
to look into events generated when a new entry is created. Now
normally I would just expect a CacheEntryCreatedEvent to be raised.
However we currently raise a CacheEntryModifiedEvent event and then a
CacheEntryCreatedEvent. I notice that there are comments around the
code saying that tests require both to be fired.
it doesn't sound right to me: modified is different than created.
I am wondering if anyone has an objection to only raising a
CacheEntryCreatedEvent on a new cache entry being created. Does
anyone know why we raise both currently? Was it just so the
PutKeyValueCommand could more ignorantly just raise the
CacheEntryModified pre Event?
Any input would be appreciated, Thanks.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
10:35 a.m.
On 23 January 2014 17:54, Mircea Markus <mmarkus(a)redhat.com> wrote:
On Jan 23, 2014, at 5:48 PM, William Burns <mudokonman(a)gmail.com> wrote:
> Hello all,
>
> I have been working with notifications and most recently I have come
> to look into events generated when a new entry is created. Now
> normally I would just expect a CacheEntryCreatedEvent to be raised.
> However we currently raise a CacheEntryModifiedEvent event and then a
> CacheEntryCreatedEvent. I notice that there are comments around the
> code saying that tests require both to be fired.
it doesn't sound right to me: modified is different than created.
I'd tend to agree with you, still it's a matter of perception as I could say
"a key is changing value from null to some new value so it's an update"..
I realize it's a bit far fetched, still if you start introducing
tombstones for eventual consistency you can have a longer history of
changes to append to even if it's just a "creation".
For example with this sequence of commands:
Put(K1, V1), Remove(K1), Put(K1, V2) < Creation event?
As the history sequence for this entry is
V1 - null - V2
And in case of asynchronous CacheStores, Remote eventlistener, X-site,
.. and all other features where you might have coalescing of changes
applied, this sequence could be "compacted" as
V1 - V2
Is the write of V2 still a creation event?
I don't necessarily disagree with the choice, but it's not that simple
and will have consequent complexities down the road.
Personally I think you should drop the differentiation between the two
event types, as it's over-promising on something that we can't deliver
consistently.
Sanne
>
> I am wondering if anyone has an objection to only raising a
> CacheEntryCreatedEvent on a new cache entry being created. Does
> anyone know why we raise both currently? Was it just so the
> PutKeyValueCommand could more ignorantly just raise the
> CacheEntryModified pre Event?
>
> Any input would be appreciated, Thanks.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
11:48 p.m.
On Jan 27, 2014, at 9:35 AM, Sanne Grinovero <sanne(a)infinispan.org> wrote:
On 23 January 2014 17:54, Mircea Markus <mmarkus(a)redhat.com>
wrote:
>
> On Jan 23, 2014, at 5:48 PM, William Burns <mudokonman(a)gmail.com> wrote:
>
>> Hello all,
>>
>> I have been working with notifications and most recently I have come
>> to look into events generated when a new entry is created. Now
>> normally I would just expect a CacheEntryCreatedEvent to be raised.
>> However we currently raise a CacheEntryModifiedEvent event and then a
>> CacheEntryCreatedEvent. I notice that there are comments around the
>> code saying that tests require both to be fired.
>
> it doesn't sound right to me: modified is different than created.
I'd tend to agree with you, still it's a matter of perception as I could say
"a key is changing value from null to some new value so it's an update"..
I realize it's a bit far fetched,
there were actually discussions about implementing all the ISPN operations as a single
generic one, so you do have a point :-)
still if you start introducing
tombstones for eventual consistency you can have a longer history of
changes to append to even if it's just a "creation".
Whilst I agree with you in theory, IMO the users have a clear expectations on what an
update vs an create is (as in CRUD). Using tombstones is an implementation detail, but
there is a general accepted semantical difference between a create and an update.
For example with this sequence of commands:
Put(K1, V1), Remove(K1), Put(K1, V2) < Creation event?
As the history sequence for this entry is
V1 - null - V2
And in case of asynchronous CacheStores, Remote eventlistener, X-site,
.. and all other features where you might have coalescing of changes
applied, this sequence could be "compacted" as
V1 - V2
Is the write of V2 still a creation event?
I don't necessarily disagree with the choice, but it's not that simple
and will have consequent complexities down the road.
Personally I think you should drop the differentiation between the two
event types, as it's over-promising on something that we can't deliver
consistently.
Sanne
>
>>
>> I am wondering if anyone has an objection to only raising a
>> CacheEntryCreatedEvent on a new cache entry being created. Does
>> anyone know why we raise both currently? Was it just so the
>> PutKeyValueCommand could more ignorantly just raise the
>> CacheEntryModified pre Event?
>>
>> Any input would be appreciated, Thanks.
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
5:07 p.m.
On 23 Jan 2014, at 18:54, Mircea Markus <mmarkus(a)redhat.com> wrote:
On Jan 23, 2014, at 5:48 PM, William Burns <mudokonman(a)gmail.com> wrote:
> Hello all,
>
> I have been working with notifications and most recently I have come
> to look into events generated when a new entry is created. Now
> normally I would just expect a CacheEntryCreatedEvent to be raised.
> However we currently raise a CacheEntryModifiedEvent event and then a
> CacheEntryCreatedEvent. I notice that there are comments around the
> code saying that tests require both to be fired.
it doesn't sound right to me: modified is different than created.
I’ve lost count the number of times I’ve raised this up in the dev mailing list :|
And, if CacheEntryModifiedEvent has a method called isCreated(), is cos I added it in
order to differentiate between a modify and a create without breaking backwards
compatibility and expectations of events to be received. Just need to trace back the jira
issue number, and associated forum threads ;) :p
>
> I am wondering if anyone has an objection to only raising a
> CacheEntryCreatedEvent on a new cache entry being created.
It’d break expectations of existing applications that expect certain events. It’s a very
difficult one to swallow.
Plus, there’s JCache specifications, which adds listeners, and gets them right. Eventually
everyone should move towards that.
> Does
> anyone know why we raise both currently?
Legacy really.
> Was it just so the
> PutKeyValueCommand could more ignorantly just raise the
> CacheEntryModified pre Event?
>
> Any input would be appreciated, Thanks.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
5:29 p.m.
On Mon, Feb 3, 2014 at 11:07 AM, Galder Zamarreño <galder(a)redhat.com> wrote:
On 23 Jan 2014, at 18:54, Mircea Markus <mmarkus(a)redhat.com> wrote:
>
> On Jan 23, 2014, at 5:48 PM, William Burns <mudokonman(a)gmail.com> wrote:
>
>> Hello all,
>>
>> I have been working with notifications and most recently I have come
>> to look into events generated when a new entry is created. Now
>> normally I would just expect a CacheEntryCreatedEvent to be raised.
>> However we currently raise a CacheEntryModifiedEvent event and then a
>> CacheEntryCreatedEvent. I notice that there are comments around the
>> code saying that tests require both to be fired.
>
> it doesn't sound right to me: modified is different than created.
I've lost count the number of times I've raised this up in the dev mailing list
:|
And, if CacheEntryModifiedEvent has a method called isCreated(), is cos I added it in
order to differentiate between a modify and a create without breaking backwards
compatibility and expectations of events to be received. Just need to trace back the jira
issue number, and associated forum threads ;) :p
Ah nice I didn't even notice the method until you pointed it out.
>
>>
>> I am wondering if anyone has an objection to only raising a
>> CacheEntryCreatedEvent on a new cache entry being created.
It'd break expectations of existing applications that expect certain events. It's
a very difficult one to swallow.
I agree. Maybe I should change to if anyone minds if Cluster Listeners
only raise the CacheEntryModifiedEvent on an entry creation for
cluster listeners instead? This wouldn't break existing assumptions
since we don't currently support Cluster Listeners. The only thing is
it wouldn't be consistent with regular listeners...
Plus, there's JCache specifications, which adds listeners, and gets them right.
Eventually everyone should move towards that.
Just to be clear you are saying the JCache only raises a single event
for change and create right?
>> Does
>> anyone know why we raise both currently?
Legacy really.
>> Was it just so the
>> PutKeyValueCommand could more ignorantly just raise the
>> CacheEntryModified pre Event?
>>
>> Any input would be appreciated, Thanks.
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
3:40 p.m.
On 03 Feb 2014, at 17:29, William Burns <mudokonman(a)gmail.com> wrote:
On Mon, Feb 3, 2014 at 11:07 AM, Galder Zamarreño
<galder(a)redhat.com> wrote:
>
> On 23 Jan 2014, at 18:54, Mircea Markus <mmarkus(a)redhat.com> wrote:
>
>>
>> On Jan 23, 2014, at 5:48 PM, William Burns <mudokonman(a)gmail.com> wrote:
>>
>>> Hello all,
>>>
>>> I have been working with notifications and most recently I have come
>>> to look into events generated when a new entry is created. Now
>>> normally I would just expect a CacheEntryCreatedEvent to be raised.
>>> However we currently raise a CacheEntryModifiedEvent event and then a
>>> CacheEntryCreatedEvent. I notice that there are comments around the
>>> code saying that tests require both to be fired.
>>
>> it doesn't sound right to me: modified is different than created.
>
> I've lost count the number of times I've raised this up in the dev mailing
list :|
>
> And, if CacheEntryModifiedEvent has a method called isCreated(), is cos I added it in
order to differentiate between a modify and a create without breaking backwards
compatibility and expectations of events to be received. Just need to trace back the jira
issue number, and associated forum threads ;) :p
Ah nice I didn't even notice the method until you pointed it out.
>
>>
>>>
>>> I am wondering if anyone has an objection to only raising a
>>> CacheEntryCreatedEvent on a new cache entry being created.
>
> It'd break expectations of existing applications that expect certain events.
It's a very difficult one to swallow.
I agree. Maybe I should change to if anyone minds if Cluster Listeners
only raise the CacheEntryModifiedEvent on an entry creation for
cluster listeners instead? This wouldn't break existing assumptions
since we don't currently support Cluster Listeners. The only thing is
it wouldn't be consistent with regular listeners…
Yeah, it’s a tricky one. You don’t wanna raise both cos that’d be expensive to ship it
around for no extra gain. If you are going to choose one that’d be CacheEntryModifiedEvent
indeed. I think we can break off here for clustered listeners specifying it clearly. I
don’t think there’s much point in creating a new set of listeners/event/annotations for
the clustered option since eventually we should move towards JCache listeners and only
have custom ones for the extra stuff we provide callbacks for.
>
> Plus, there's JCache specifications, which adds listeners, and gets them right.
Eventually everyone should move towards that.
Just to be clear you are saying the JCache only raises a single event
for change and create right?
Yeah, see JCacheListenerAdapter class.
>
>>> Does
>>> anyone know why we raise both currently?
>
> Legacy really.
>
>>> Was it just so the
>>> PutKeyValueCommand could more ignorantly just raise the
>>> CacheEntryModified pre Event?
>>>
>>> Any input would be appreciated, Thanks.
>>
>> Cheers,
>> --
>> Mircea Markus
>> Infinispan lead (www.infinispan.org)
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Galder Zamarreño
> galder(a)redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
3:38 p.m.
On Feb 3, 2014, at 4:07 PM, Galder Zamarreño <galder(a)redhat.com> wrote:
>
> On Jan 23, 2014, at 5:48 PM, William Burns <mudokonman(a)gmail.com> wrote:
>
>> Hello all,
>>
>> I have been working with notifications and most recently I have come
>> to look into events generated when a new entry is created. Now
>> normally I would just expect a CacheEntryCreatedEvent to be raised.
>> However we currently raise a CacheEntryModifiedEvent event and then a
>> CacheEntryCreatedEvent. I notice that there are comments around the
>> code saying that tests require both to be fired.
>
> it doesn't sound right to me: modified is different than created.
I’ve lost count the number of times I’ve raised this up in the dev mailing list :|
And, if CacheEntryModifiedEvent has a method called isCreated(), is cos I added it in
order to differentiate between a modify and a create without breaking backwards
compatibility and expectations of events to be received. Just need to trace back the jira
issue number, and associated forum threads ;) :p
Sorry for missing this till now :-) If it was raised that frequently through, must be
because people are confused about it. As we're having a major release next, I think we
should get this right, even if breaking backward compatibility, and document it as such in
the migration guide.
>
>>
>> I am wondering if anyone has an objection to only raising a
>> CacheEntryCreatedEvent on a new cache entry being created.
It’d break expectations of existing applications that expect certain events. It’s a very
difficult one to swallow.
we're at a major now, so we should break compatibility if it makes sense.
Plus, there’s JCache specifications, which adds listeners, and gets them right.
Eventually everyone should move towards that.
Not sure I understand: JCache raises both an "created" and a
"modified" event when an entry is created? or just "created" events?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
4:03 p.m.
On 05 Feb 2014, at 15:38, Mircea Markus <mmarkus(a)redhat.com> wrote:
On Feb 3, 2014, at 4:07 PM, Galder Zamarreño <galder(a)redhat.com> wrote:
>>
>> On Jan 23, 2014, at 5:48 PM, William Burns <mudokonman(a)gmail.com> wrote:
>>
>>> Hello all,
>>>
>>> I have been working with notifications and most recently I have come
>>> to look into events generated when a new entry is created. Now
>>> normally I would just expect a CacheEntryCreatedEvent to be raised.
>>> However we currently raise a CacheEntryModifiedEvent event and then a
>>> CacheEntryCreatedEvent. I notice that there are comments around the
>>> code saying that tests require both to be fired.
>>
>> it doesn't sound right to me: modified is different than created.
>
> I’ve lost count the number of times I’ve raised this up in the dev mailing list :|
>
> And, if CacheEntryModifiedEvent has a method called isCreated(), is cos I added it in
order to differentiate between a modify and a create without breaking backwards
compatibility and expectations of events to be received. Just need to trace back the jira
issue number, and associated forum threads ;) :p
Sorry for missing this till now :-) If it was raised that frequently through, must be
because people are confused about it. As we're having a major release next, I think we
should get this right, even if breaking backward compatibility, and document it as such in
the migration guide.
-1.
As already mentioned, the reason why we’ve never this tackled this problem is cos of
JCache, which gets listeners right in this area. JCache is about to go final and people
should start moving towards that. Redoing our listeners would be a waste of time IMO.
You’d be doing some work to fix something people should stop using in near-medium future.
>
>>
>>>
>>> I am wondering if anyone has an objection to only raising a
>>> CacheEntryCreatedEvent on a new cache entry being created.
>
> It’d break expectations of existing applications that expect certain events. It’s a
very difficult one to swallow.
we're at a major now, so we should break compatibility if it makes sense.
>
> Plus, there’s JCache specifications, which adds listeners, and gets them right.
Eventually everyone should move towards that.
Not sure I understand: JCache raises both an "created" and a
"modified" event when an entry is created? or just "created" events?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
4:40 p.m.
On Feb 5, 2014, at 3:03 PM, Galder Zamarreño <galder(a)redhat.com> wrote:
On 05 Feb 2014, at 15:38, Mircea Markus <mmarkus(a)redhat.com>
wrote:
>
> On Feb 3, 2014, at 4:07 PM, Galder Zamarreño <galder(a)redhat.com> wrote:
>
>>>
>>> On Jan 23, 2014, at 5:48 PM, William Burns <mudokonman(a)gmail.com>
wrote:
>>>
>>>> Hello all,
>>>>
>>>> I have been working with notifications and most recently I have come
>>>> to look into events generated when a new entry is created. Now
>>>> normally I would just expect a CacheEntryCreatedEvent to be raised.
>>>> However we currently raise a CacheEntryModifiedEvent event and then a
>>>> CacheEntryCreatedEvent. I notice that there are comments around the
>>>> code saying that tests require both to be fired.
>>>
>>> it doesn't sound right to me: modified is different than created.
>>
>> I’ve lost count the number of times I’ve raised this up in the dev mailing list
:|
>>
>> And, if CacheEntryModifiedEvent has a method called isCreated(), is cos I added
it in order to differentiate between a modify and a create without breaking backwards
compatibility and expectations of events to be received. Just need to trace back the jira
issue number, and associated forum threads ;) :p
>
> Sorry for missing this till now :-) If it was raised that frequently through, must be
because people are confused about it. As we're having a major release next, I think we
should get this right, even if breaking backward compatibility, and document it as such in
the migration guide.
-1.
As already mentioned, the reason why we’ve never this tackled this problem is cos of
JCache, which gets listeners right in this area. JCache is about to go final and people
should start moving towards that. Redoing our listeners would be a waste of time IMO.
The effort here is minimum, pretty much adding an if statement. The good thing though is
that you won't have to raise this on the mailing list again :-)
You’d be doing some work to fix something people should stop using in
near-medium future.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
4:05 p.m.
On 05 Feb 2014, at 15:38, Mircea Markus <mmarkus(a)redhat.com> wrote:
On Feb 3, 2014, at 4:07 PM, Galder Zamarreño <galder(a)redhat.com> wrote:
>>
>> On Jan 23, 2014, at 5:48 PM, William Burns <mudokonman(a)gmail.com> wrote:
>>
>>> Hello all,
>>>
>>> I have been working with notifications and most recently I have come
>>> to look into events generated when a new entry is created. Now
>>> normally I would just expect a CacheEntryCreatedEvent to be raised.
>>> However we currently raise a CacheEntryModifiedEvent event and then a
>>> CacheEntryCreatedEvent. I notice that there are comments around the
>>> code saying that tests require both to be fired.
>>
>> it doesn't sound right to me: modified is different than created.
>
> I’ve lost count the number of times I’ve raised this up in the dev mailing list :|
>
> And, if CacheEntryModifiedEvent has a method called isCreated(), is cos I added it in
order to differentiate between a modify and a create without breaking backwards
compatibility and expectations of events to be received. Just need to trace back the jira
issue number, and associated forum threads ;) :p
Sorry for missing this till now :-) If it was raised that frequently through, must be
because people are confused about it. As we're having a major release next, I think we
should get this right, even if breaking backward compatibility, and document it as such in
the migration guide.
>
>>
>>>
>>> I am wondering if anyone has an objection to only raising a
>>> CacheEntryCreatedEvent on a new cache entry being created.
>
> It’d break expectations of existing applications that expect certain events. It’s a
very difficult one to swallow.
we're at a major now, so we should break compatibility if it makes sense.
>
> Plus, there’s JCache specifications, which adds listeners, and gets them right.
Eventually everyone should move towards that.
Not sure I understand: JCache raises both an "created" and a
"modified" event when an entry is created? or just "created" events?
JCache differentiates between an entry being created vs being updated, and hence it sends
different events depending of which case it is. See JCacheListenerAdapter and
JCacheListenerNotifier classes in our JCache impl.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
3738
days inactive
3751
days old
infinispan-dev@lists.jboss.org
10 comments
4 participants
participants (4)
-
Galder Zamarreño -
Mircea Markus -
Sanne Grinovero -
William Burns