[infinispan-dev] Feedback and requests on clustered and remote listeners

[William Burns]

On Tue, Sep 23, 2014 at 8:18 AM, Emmanuel Bernard
<emmanuel at hibernate.org> wrote:
>
>
>
>> On 22 sept. 2014, at 19:23, William Burns <mudokonman at gmail.com> wrote:
>>
>> On Fri, Sep 19, 2014 at 12:39 PM, Emmanuel Bernard
>> <emmanuel at hibernate.org> wrote:
>>>
>>>> On 19 Sep 2014, at 17:09, William Burns <mudokonman at gmail.com> wrote:
>>>>
>>>> Comments regarding embedded usage are inline.  I am not quite sure on
>>>> the hot rod client ones.
>>>>
>>>> On Thu, Sep 18, 2014 at 12:24 PM, Emmanuel Bernard
>>>> <emmanuel at hibernate.org> wrote:
>>>>>
>>>>>
>>>>> That requires us to be able to provide the old and new value to the KeyValueFilter and the Converter interface as well as the type of event (creation, update, deletion).
>>>>
>>>> I agree the oldValue is required for most efficient usage.  From the
>>>> oldValue though it seems you can infer what operation it is.  Create
>>>> has null oldValue and delete has null newValue I would think.
>>>
>>> well except when I do cache.put(key, null) but that might not matter.
>>
>> We don't allow a null value to be passed to put.
>>
>>> The other use case is the includeInitialState where the old value would be either null or the same as the new one? Could a user detect that state based on old == new?
>>
>> It would have prevValue as null in this case.
>>
>>> At any rate the programming model becomes quite awkward and rely on strong understanding, I’d prefer to stick an enum showing the transition explicitly to make things easier.
>>
>> I am not sold on this as it seems pretty trivial to decipher which
>> operation is which and the information would be present on the
>> javadocs as well.
>
> I very strongly disagree. Cf the other thread with Radim 's comment on topology error.
> And think about *future* evolutions. The enum would make that much safer. In the bin enum world you would have to introduce a new YetAnotherKeyValueFilter interface :)
>
>>>>>
>>>>> ## includeCurrentState and very narrow filtering
>>>>>
>>>>> The existing approach is fine (send a create event notif for all existing keys and queue changes in the mean time) as long as the listener plans to consume most of these events.
>>>>> But in case of a big data grid, with a lot of passivated entries, the cost would become non negligible.
>>>>
>>>> The filter and converter are applied while doing the current state so
>>>> it should be performant in that case.
>>>
>>> I don’t understand, the code still has to look all key/value pairs of a given node (at least the primary ones) and send them through the KVF / Converter logic. So you need to unmarshal all of them as well as load from cachestore the passivated ones. Correct? That’s the cost I am describing here.
>>
>> Sorry I didn't realize you were referring to an indexed query.  Yes
>> that could improve performance of the initial retrieval.  I am not as
>> familiar with indexed query, but I don't know if it lends itself well
>> to the individual filtering that is done as each event is fired.  I
>> think this needs to be discussed/investigated further.
>
> Ok. How do we go about this ? JIRA ? Different email thread?

I would suggest both.  We can probably also get some time to discuss
this at the F2F in a few months, unless you think this is more
critical?  I am just thinking this feature might be a bit too late to
get into 7.0 at this point.

>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev