erz/infinispan/commit/2934e0b3e8ab9af5fb1471c5fdbb0716e5a11c31
> [2]
>
> https://github.com/infinispan/infinispan/blob/master/hibernate/cache-v53/src/main/java/org/infinispan/hibernate/cache/v53/impl/Sync.java
>
--
Radim Vansa
JBoss Performance Team
On 12/14/2018 11:49 AM, Sebastian Laskawiec wrote:
>
>
> On Thu, Dec 13, 2018 at 4:42 PM Radim Vansa <mailto:rva...@redhat.com>> wrote:
>
> Hey Sebastian,
>
> I am sorry that you took my comment about errors between chair and
> keyboard completely wro
On 12/12/2018 03:30 PM, Sebastian Laskawiec wrote:
> On Tue, Dec 11, 2018 at 11:13 AM Radim Vansa <mailto:rva...@redhat.com>> wrote:
>
> I dislike having any logic based on the port number in some range;
> it's
> not common that behaviour would change
osed on different
> port (like ) or Hot Rod exposed on port that starts with 8.
>
> What do you think about such simplification?
>
> Thanks,
> Sebastian
>
>
>
>
> _______
> infinispan-d
suggest the Intrinsics.
Radim
On 08/20/2018 02:43 PM, Galder Zamarreno wrote:
> Header is just one part of the operation. Individual operation
> parameters, like version in replaceWithVersion are not logged
>
> On Tue, Aug 14, 2018 at 6:22 PM Radim Vansa <mailto:rva...@red
stening for that and in the other case we should
still drop the connection.
Radim
>
> Cheers
>
> On Mon, Jun 25, 2018 at 2:47 PM Radim Vansa <mailto:rva...@redhat.com>> wrote:
>
> You mean that the writes are executed by the Netty thread instead of
> r
>
> In which case the client will need to compute the hash before it can
> hint the network layer were to connect to.
>
> Thanks,
> Sanne
>
>> On 05/30/2018 02:47 PM, Radim Vansa wrote:
>>> On 05/30/2018 12:46 PM, Adrian Nistor wrote:
>>>> Thanks for cl
fit in a grpc architecture?
>>>>
>>>> Thank you
>>>> Vittorio
>>>>
>>>> [1] https://github.com/rigazilla/ispn-grpc
>>>> [2] https://github.com/rigazilla/ispn-grpc/issues
>>>>
>>>> --
>>
of allowed users
>
> Cheers,
> Galder
>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rva...@redhat.com>
ss.org>
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
> --
> Bela Ban | http://www.jgroups.org
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org <
t;>
>> Here's our XML config:
>> https://github.com/vert-x3/vertx-infinispan/blob/ispn92/src/main/resources/default-infinispan.xml
>>
>> Does that ring a bell? Do you need more info?
>>
>> Regards,
>> Thomas
>>
>>
>>
>&
9.2.1.Final next
> week.
>
>
> [1] https://github.com/infinispan/infinispan/pull/5746
> [2] https://github.com/infinispan/infinispan/pull/5803
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
somehow distinguishable from the 'online' ones?
Given all the non-reliability with listeners failover I don't think this
is needed, but I'll rather check in the crowd.
Radim
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinisp
/concurrent/locks/impl/DefaultLockManager.java#L115
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
On 12/01/2017 10:04 AM, Radim Vansa wrote:
> On 12/01/2017 09:26 AM, Tristan Tarrant wrote:
>> Hello people,
>>
>> I'd like to rationalize the PR labels because I believe some of them are
>> useless:
>>
>> [Ready for review] - Any PR without the [Preview]
us. Checking CI failures should apply to ALL PRs.
> [On Ice] PR should be closed and reopened when relevant again.
>
> Comments/suggestions ?
>
> Tristan
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev ma
lists.jboss.org
> <mailto:infinispan-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
> https://lists.jbo
; infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-d
On 10/10/2017 11:08 AM, Thomas SEGISMONT wrote:
>
>
> 2017-10-09 18:30 GMT+02:00 Radim Vansa <rva...@redhat.com
> <mailto:rva...@redhat.com>>:
>
> On 10/09/2017 03:04 PM, Thomas SEGISMONT wrote:
> > Hi,
> >
> > I've created a b
i-value to @EntryCreated on the new value) would appear less crude.
R.
>
> 1/ is easy, but do you think 2/ could be added in 9.2?
>
> Thank you,
> Thomas
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.o
> Thanks,
> Sebastian
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinis
, Red Hat
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
__
keen on trying to find a potential solution using 2), but wondered if you
> have other ideas.
>
> Cheers,
>
> [1] https://gist.github.com/galderz/0bce6dce16de018375e43e25c0cf3913
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
--
Radim Vansa <rva...@re
nd-partit
>>>>>> ion.html
>>>>>>
>>>>>> Cheers
>>>>>> Ryan
>>>>>> ___
>>>>>> infinispan-dev mailing list
>>>>>> infinispan-dev@lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> ___
>>> infinispan-dev mailing list
>>> infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> some unexpected nulls among other valid results. The fix was to just
>> filter out those nulls. We could enhance that to double check that the
>> returned entry is indeed of the requested type, to also cover the issue
>> that you encountered.
>>
>>
e, to also cover
> the issue that you encountered.
It's not just entity type, criteria may be invalidated by any field
change. Would a full criteria check on the returned entities be too
expensive? Can you even check e.g. native queries against provided set
of objects?
Radim
>
> Adria
was not correct, though.
[1]
https://github.com/rvansa/infinispan/commit/1d62c9b84888c7ac21a9811213b5657aa44ff546
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
[1] https://checkerframework.org/jsr308/
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
answered in the user documentation, that would be
> fine but I feel these are things that should be explained/clarified in the
> blog post itself.
>
> Cheers,
>
> [1] http://blog.infinispan.org/2017/07/scattered-cache.html
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>
On 06/29/2017 02:36 PM, Dan Berindei wrote:
> On Thu, Jun 29, 2017 at 2:19 PM, Radim Vansa <rva...@redhat.com> wrote:
>> On 06/29/2017 11:16 AM, Dan Berindei wrote:
>>> On Thu, Jun 29, 2017 at 11:53 AM, Radim Vansa <rva...@redhat.com> wrote:
>>>>
On 06/29/2017 11:16 AM, Dan Berindei wrote:
> On Thu, Jun 29, 2017 at 11:53 AM, Radim Vansa <rva...@redhat.com> wrote:
>> On 06/28/2017 04:20 PM, Dan Berindei wrote:
>>> On Wed, Jun 28, 2017 at 2:17 PM, Radim Vansa <rva...@redhat.com> wrote:
>>>>
On 06/29/2017 10:23 AM, Dan Berindei wrote:
> On Wed, Jun 28, 2017 at 5:25 PM, Radim Vansa <rva...@redhat.com> wrote:
>> On 06/28/2017 01:17 PM, Radim Vansa wrote:
>>> On 06/28/2017 10:40 AM, Dan Berindei wrote:
>>>> On Wed, Jun 28, 2017 at 10:17 AM, R
On 06/28/2017 04:20 PM, Dan Berindei wrote:
> On Wed, Jun 28, 2017 at 2:17 PM, Radim Vansa <rva...@redhat.com> wrote:
>> On 06/28/2017 10:40 AM, Dan Berindei wrote:
>>> On Wed, Jun 28, 2017 at 10:17 AM, Radim Vansa <rva...@redhat.com> wrote:
>>>>
On 06/28/2017 01:17 PM, Radim Vansa wrote:
> On 06/28/2017 10:40 AM, Dan Berindei wrote:
>> On Wed, Jun 28, 2017 at 10:17 AM, Radim Vansa <rva...@redhat.com> wrote:
>>> On 06/27/2017 03:54 PM, Dan Berindei wrote:
>>>> On Tue, Jun 27, 2017 at 2:43 PM, Adri
On 06/28/2017 10:40 AM, Dan Berindei wrote:
> On Wed, Jun 28, 2017 at 10:17 AM, Radim Vansa <rva...@redhat.com> wrote:
>> On 06/27/2017 03:54 PM, Dan Berindei wrote:
>>> On Tue, Jun 27, 2017 at 2:43 PM, Adrian Nistor <anis...@redhat.com> wrote:
>>>> I've s
e it the default and add a method
> AdvancedCache.forceReturnPreviousValues()?
Please don't derail the thread.
>
>>
>>
>> On 06/27/2017 01:28 PM, Sanne Grinovero wrote:
>>
>>
>>
>> On 27 Jun 2017 10:13, "Radim Vansa" <rva...
broken)
>>>
>>>
>>> Might be useful for making a POC work, but I believe query will be very
>>> likely to be often enabled.
>>> Having an either / or switch for different features in Infinispan will make
>>> it harder to use and understand, so
is ran without a fancy setup,
though, but it's asking for trouble.
WDYT?
Radim
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infi
On 06/13/2017 03:07 PM, William Burns wrote:
>
>
> On Tue, Jun 13, 2017, 3:54 AM Radim Vansa <rva...@redhat.com
> <mailto:rva...@redhat.com>> wrote:
>
> On 06/12/2017 04:52 PM, William Burns wrote:
> >
> >
> > On Sat, Jun 10,
On 06/12/2017 04:52 PM, William Burns wrote:
>
>
> On Sat, Jun 10, 2017 at 12:56 AM Radim Vansa <rva...@redhat.com
> <mailto:rva...@redhat.com>> wrote:
>
> Hi guys,
>
> when the functional API has been outline, the interfaces were put into
>
I did not, I swear to Ctulhu!
On 06/09/2017 03:10 PM, Tristan Tarrant wrote:
> I told you not to read it.
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
nd out that
SerializableFunction et all are only in infinispan-core (for good).
Please let me know if you have objections/if there something I have missed.
Radim
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
in
bedded also needs to depend on core.
>>> >
>>> > Any more details behind this decision?
>>> >
>>> > Cheers,
>>> > --
>>> > Galder Zamarreño
>>> > Infinispan, Red Hat
>>> >
>>> > --
>>> > SEBASTIAN ŁASKAWIEC
>>> > INFINISPAN DEVELOPER
>>> > Red Hat EMEA
>>> >
>>>
>>>
>>> ___
>>> infinispan-dev mailing list
>>> infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>>
>>>
>>>
>>>
>>> ___
>>> infinispan-dev mailing list
>>> infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>> --
>> Tristan Tarrant
>> Infinispan Lead
>> JBoss, a division of Red Hat
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
;
> [3]
> https://github.com/slaskawi/external-ip-proxy/tree/master/benchmark
> <https://github.com/slaskawi/external-ip-proxy/tree/master/benchmark>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists
On 05/24/2017 10:44 AM, Sebastian Laskawiec wrote:
>
>
> On Tue, May 23, 2017 at 5:06 PM Radim Vansa <rva...@redhat.com
> <mailto:rva...@redhat.com>> wrote:
>
> On 05/16/2017 11:05 AM, Sebastian Laskawiec wrote:
> > Hey guys!
> >
> &
t; <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> <mailto:infinispan-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
> --
>
> SEBASTIANŁASKAWIEC
>
> INFINISPAN DEVELOPER
>
> Red HatEMEA <https://www.redhat.com/>
>
> <https://red.ht/sig>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> <mailto:infinispan-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
it
>>> to compile and the tests to pass
>>>> pferraro: need to switch to async interceptor stack in 2lc
>>> integration and get all the subtle changes right
>>>> pferraro: it's a painstaking job basically
>>>>
return 200 & entity or 204 and no
response)
* Do we handle OPTIONS in any way?
Radim
>
> Thanks,
> Sebastian
>
> --
>
> SEBASTIANŁASKAWIEC
>
> INFINISPAN DEVELOPER
>
> Red HatEMEA <https://www.redhat.com/>
>
> <https://red.ht/sig>
>
>
gt; that steve had since master was focused on 5.x
>>> pferraro: i've no idea when/where we'll integrate this, but one
>> thing is for sure: it's nowhere near backwards compatible
>>> actually, fixed one this morning, so down to 15 failures
>>> pferraro: any suggestions/wishes?
>>> is anyone out there? ;)
>> Cheers,
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
g if
>> most people think like Radim because working on commands has helped me to
>> learn and understand more about infinispan internals, so this hasn't been a
>> waste of time for me.
>>
>> Katia
>>
>> [1] https://issues.jboss.org/browse/ISPN-5728
>> [2] https://github.com
gt; --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 11 Apr 2017, at 15:57, Radim Vansa <rva...@redhat.com> wrote:
>>
>> Since these tests use real server(s), many of them test not only the
>> client behaviour (generating correct commands according to th
dhat.com/>
>>
>> <https://red.ht/sig>
>>
>>
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> <mailto:infinispan-dev@lists.jboss.org>
>
s citizen API-wise.
> For this reason I propose that we extract the query API to
> infinispan-commons, put the query SPI in infinispan-core together with
> the non-indexed implementation and have the hibernate-search backend as
> a pluggable
b.com/ugol/infinispan-go).
>
> And in my opinion, a final version of this document go to infinispan
> design repository: https://github.com/infinispan/infinispan-designs
>
> Apart from that, that's huge effort and really great job!
>
> On Tue, Apr 11, 2017 at 5:05 PM Radim Vansa &l
giQNDZWzFNPWrF5G4/edit#gid=0
> [2] https://en.wikipedia.org/wiki/Technology_Compatibility_Kit
> [3] https://github.com/infinispan/infinispan/pull/5012
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
boss.org/meeting/irc.freenode.org/infinispan/2017/infinispan.2017-04-10-14.00.html
>>
>> Cheers
>> Dan
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinf
d but I don't know for sure.
>
> On Mon, Apr 10, 2017 at 6:41 AM Radim Vansa <rva...@redhat.com
> <mailto:rva...@redhat.com>> wrote:
>
> Hi Will,
>
> rebasing scattered cache PR I've found a test failure when handling
> streams, and I'd like to a
, and
it seems that segments are suspected after any unsuccessful response.
Which components should react to topology changes?
Thanks!
Radim
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
infinispan-dev@lists.jbo
On 04/06/2017 12:15 AM, Katia Aresti wrote:
>
>
> On Wed, Apr 5, 2017 at 9:56 AM, Radim Vansa <rva...@redhat.com
> <mailto:rva...@redhat.com>> wrote:
>
> On 04/04/2017 06:40 PM, William Burns wrote:
> >
> >
> > On Tue, Apr 4, 2
ailman/listinfo/infinispan-dev
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
&
https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/infini
void if not really needed" : not cool to
> allocate objects for no reason.
>
> On 30 Mar 2017 16:57, "Radim Vansa" <rva...@redhat.com
> <mailto:rva...@redhat.com>> wrote:
>
> Hi,
>
> I was wondering what's the common attitude toward
add-user script.
>> This would achieve two goals:
>> - secure out-of-the-box configuration, which is always a good idea
>> - access to the "protected" schema and script caches which is prevented
>> when not on loopback on non-authenticated endpoints.
>>
on't use/use at developer's
discretion) and naming conventions? Is it acceptable to start adding
default Optional foo() { Optional.ofNullable(getFoo()); }
whenever we feel the urge to chain Optionals?
Radim
--
Radim Vansa <rva...@redhat.com>
JBoss Pe
On 03/27/2017 01:16 PM, Sebastian Laskawiec wrote:
>
>
> On Mon, Mar 27, 2017 at 12:59 PM Radim Vansa <rva...@redhat.com
> <mailto:rva...@redhat.com>> wrote:
>
> On 03/27/2017 12:45 PM, Sebastian Laskawiec wrote:
> > From my past experience, if a c
the PR with nice history of comments (some of them
not addressed yet) and open another PR?
R.
>
> After a while it became a habit that each dev who submitted a code
> that could result in conflicts, did all the merges.
>
> On Mon, Mar 27, 2017 at 12:37 PM Radim Vansa <rva...@r
>
>
> On Mon, Mar 27, 2017 at 11:59 AM, Sebastian Laskawiec
> <slask...@redhat.com> wrote:
>> Sounds good...
>>
>> Sadly our build infrastructure is not very fast...
>>
>> On Mon, Mar 27, 2017 at 10:58 AM Radim Vansa <rva...@redhat.com> wrote:
&
here is nothing for free, and we would
> need to get used to pushing merged directly into master (which is fine
> to me but some of you might not like it).
>
> Thanks,
> Sebastian
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jb
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
to sort this out,
we should keep the Streams API and Cache API in sync.
I think that having this as compilation issue in user code at least
forces user to define the lambda as serializable, it's not necessarily a
bad thing (though annoying).
>
> Cheers
> Dan
>
>
> On Thu, Mar 23, 2017
___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
he optimistic exclusion is acceptable.
>
> Thanks,
>
> - Will
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > infinispan-dev mailing list
> > infinispan-dev@lists.jboss.org
> <mailto:infinispan-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
bout the future, disconnecting the cache definition
> and retrieval would be the best option, but we can't do that this late
> in the game.
>
> What do you guys think?
>
> - Will
>
>
> ___
> infinispan-dev mailing list
>
in couple of
other places, haven't tried that.
Seems that HashMap already does so, so the other types of contexts
should work OOTB.
Radim
[1]
http://stackoverflow.com/questions/13521184/equals-returns-false-yet-object-is-found-in-map
On 02/20/2017 05:22 PM, Radim Vansa wrote:
> On 02/20/2017 03
h transactions
>> are isolated from external transactions). That would be at odds with
>> Sanne's suggestions in the "major version cleaning" thread, because
>> those would require a batch to join any external transaction.
>>
>> Cheers
>> Dan
>>
nispan-dev+order:date-backward
[6] https://issues.jboss.org/browse/ISPN-3927
[7] https://issues.jboss.org/browse/ISPN-7507
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
infinispan-dev@lists
ust my 2c
Radim
>
> Cheers,
> Pedro
>
> [1] actually, I need a thread dump to confirm it.
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jbos
On 02/22/2017 09:53 AM, Radim Vansa wrote:
> On 02/22/2017 09:11 AM, Dan Berindei wrote:
>> On Tue, Feb 21, 2017 at 8:28 PM, Radim Vansa <rva...@redhat.com> wrote:
>>> On 02/21/2017 07:14 PM, Dan Berindei wrote:
>>>> But doesn't the functional API's evalMany
On 02/22/2017 09:11 AM, Dan Berindei wrote:
> On Tue, Feb 21, 2017 at 8:28 PM, Radim Vansa <rva...@redhat.com> wrote:
>> On 02/21/2017 07:14 PM, Dan Berindei wrote:
>>> But doesn't the functional API's evalMany() provide something very
>>> close to the A
On 02/21/2017 07:14 PM, Dan Berindei wrote:
> But doesn't the functional API's evalMany() provide something very
> close to the API you're suggesting?
>
> Dan
>
>
> On Tue, Feb 21, 2017 at 7:55 PM, Radim Vansa <rva...@redhat.com> wrote:
>> On 02/21/2017 05:16 PM,
e being.
I don't find the current API ideal either, as it depends on thread
locals (JTA does as well, but...) while it does not seem useful enough
to me. I would prefer
interface BatchingCache {
Batch start();
}
@NotThreadSafe
interface Batch {
void put
> wanna wait for its commit:
>>>>
>>>> tm.begin()
>>>> doWork()
>>>> tx = tm.suspend()
>>>> new_thread {
>>>> tm.resume(tx)
>>>> tm.commit()
>>>> }
>>>>
>>>> The best thing I can think of is to keep the batching API
can still move a transaction commit to another thread if you don't
>>>>> wanna wait for its commit:
>>>>>
>>>>> tm.begin()
>>>>> doWork()
>>>>> tx = tm.suspend()
>>>&
On 02/20/2017 03:52 PM, Galder Zamarreño wrote:
> I've just verified the problem and the NPE can be reproduced with Infinispan
> alone.
>
> More replies below:
>
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 16 Feb 2017, at 10:44, Radim Vansa <rva...@re
> Cheers,
>>
>> p.s. A lot of tests still failing, so the work in [2] is nowhere near
>> finished.
>>
>> [1] https://gist.github.com/galderz/e26ea9d4838a965500906a6df87e064a
>> [2]
>> https://github.com/galderz/hibernate-orm/commit/5e36a021db4eaad75d835d
On 02/16/2017 02:53 PM, William Burns wrote:
>
>
> On Thu, Feb 16, 2017 at 8:51 AM Radim Vansa <rva...@redhat.com
> <mailto:rva...@redhat.com>> wrote:
>
> On 02/16/2017 10:44 AM, Radim Vansa wrote:
> > On 02/15/2017 06:07 PM, Galder Zamarreño wrote:
&
On 02/16/2017 10:44 AM, Radim Vansa wrote:
> On 02/15/2017 06:07 PM, Galder Zamarreño wrote:
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>>> On 15 Feb 2017, at 12:21, Radim Vansa <rva...@redhat.com> wrote:
>>>
>>> On
On 02/15/2017 06:07 PM, Galder Zamarreño wrote:
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 15 Feb 2017, at 12:21, Radim Vansa <rva...@redhat.com> wrote:
>>
>> On 02/15/2017 11:28 AM, Galder Zamarreño wrote:
>>> Hey Radim,
>>
t; https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysFactoryTest.java#L58
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
aware off?
>
> Cheers,
>
> [1] https://gist.github.com/galderz/676f689884969658b01a7695f08dd7a2
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>
> ___
> infinispan-dev mailing list
> infi
On 01/19/2017 11:14 PM, William Burns wrote:
>
>
> On Thu, Jan 19, 2017 at 11:13 AM Radim Vansa <rva...@redhat.com
> <mailto:rva...@redhat.com>> wrote:
>
> Hi,
>
> I've started (again) working on ISPN-5021 [1], and I'd like to get
> some
>
wiped out). Should I add another StateTransferEvent event (and
appropriate listeners)? That would break the compatibility with tightly
related implementations...
WDYT?
Radim
[1] https://issues.jboss.org/browse/ISPN-5021
--
Radim Vansa <rva...@redhat.com>
JBoss Performanc
github/benmanes/caffeine/cache/Caffeine.java#L347
>
> On Tue, Dec 20, 2016 at 4:16 AM Radim Vansa <rva...@redhat.com
> <mailto:rva...@redhat.com>> wrote:
>
> Regarding another use of Weighter in Caffeine: would it be possible to
> guarantee that an object with
ailman/listinfo/infinispan-dev
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
heoretically Debezium can do the same, boldly claim that "your
apps can respond quickly and never miss an event, even when things go
wrong" and push the blame to Infinispan :)
Radim
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rva...@redhat.com>
JBoss Performance Team
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
id per
> operation to dedup.
And a suitable definition for Debezium if the operation "happened" or not.
Radim
>
> Emmanuel
>
>
> On Fri 16-12-09 10:08, Randall Hauch wrote:
>>> On Dec 9, 2016, at 3:13 AM, Radim Vansa <rva...@redhat.com> wrote:
>&g
On 12/09/2016 05:08 PM, Randall Hauch wrote:
>
>> On Dec 9, 2016, at 3:13 AM, Radim Vansa <rva...@redhat.com
>> <mailto:rva...@redhat.com>> wrote:
>>
>> On 12/08/2016 10:13 AM, Gustavo Fernandes wrote:
>>>
>>> I recently updated a proposa
t work right now because the internals are only
> implemented half way. Thanks for reminding me to finish it :)
>
> Adrian
>
> On 12/08/2016 06:20 PM, Radim Vansa wrote:
>> Nice! I wonder when we'll find out that we need prepared statements, though.
>>
>> R.
>>
m
>
>
> [1]
> https://github.com/infinispan/infinispan/wiki/Remote-Listeners-improvement-proposal
>
> Thanks,
> Gustavo
>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jb
1 - 100 of 361 matches
Mail list logo
