On Mon, Jan 25, 2016 at 10:09 AM Sebastian Laskawiec
wrote:
> Would it be possible to decouple Map implementation from our custom code
> (like eviction policy or setting max size)? Or the dependency between those
> two is too strong?
>
This is possible. I had already thought of doing that at so
On Mon, Jan 25, 2016 at 9:24 AM Sanne Grinovero
wrote:
> On 25 January 2016 at 14:15, William Burns wrote:
> > Unfortunately this isn't really possible to remove these classes. They
> have
> > additional changes over and above the jdk8 classes. We could move it
> into a
> > different package t
Hi Cosmin,
sorry for the delay.
Yes, the correct approach would be to implement some kind of
"UnreliableCacheReader/Writer" as a wrapper to a concrete Cache Store,
which would ignore any errors in the underlying store. This wrapper
would also probably implement some kind of fail-fast mechanism
Hi all,
get the meeting logs from here:
http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2016/infinispan.2016-01-25-15.02.log.html
Cheers
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
___
infinispan-dev maili
Would it be possible to decouple Map implementation from our custom code
(like eviction policy or setting max size)? Or the dependency between those
two is too strong?
On Mon, Jan 25, 2016 at 3:15 PM, William Burns wrote:
> Unfortunately this isn't really possible to remove these classes. They
Is it possible to have #3 and use a dedicated configuration schema per
Cache Store? Otherwise the only way to configure a Cache Store it to use
properties (key/value pairs).
If it's not possible to have a custom configuration schema - I would vote
for #4.
On Mon, Jan 25, 2016 at 3:42 PM, Tristan
Yes, that would be nice.
I found another "cons" for #4: an embedded config would not translate
1:1 to server. Well, it doesn't translate directly now either, but at
least it's "closer".
Tristan
On 25/01/2016 15:39, Radim Vansa wrote:
> Would the deployable cache stores benefit from 4) as well?
Would the deployable cache stores benefit from 4) as well? It seems to
me as the only 'right' option.
R.
On 01/25/2016 02:29 PM, Tristan Tarrant wrote:
> Hi all,
>
> Jakub has recently revived the Cassandra Cache Store (CCS from now on)
> which, as you all will remember, was pushed to an externa
On 25 January 2016 at 14:15, William Burns wrote:
> Unfortunately this isn't really possible to remove these classes. They have
> additional changes over and above the jdk8 classes. We could move it into a
> different package though if we wanted to.
+1 to change package: I have been confused ab
Unfortunately this isn't really possible to remove these classes. They
have additional changes over and above the jdk8 classes. We could move it
into a different package though if we wanted to.
To be honest the only reason this is still really needed is for the
BoundedConcurrentHashMapV8. I hav
Hi all,
As I write the Javascript client for Hot Rod, and Vittorio writes the C++
client, the question the encoding of the byte arrays has popped up.
The reason why encoding matters is mainly because of compatibility mode. How
does a Hot Rod client know how it should transform something a REST
Hi all,
Jakub has recently revived the Cassandra Cache Store (CCS from now on)
which, as you all will remember, was pushed to an external repository
where it lay in abandonment ever since.
We now need to add support for this store to Infinispan Server, but
unfortunately, because of the "monoli
Hi Radim
For RepeatableRead, skipLookup is set to true so valueIsMissing() is
going to return false.
Cheers,
Pedro
On 01/25/2016 10:57 AM, Radim Vansa wrote:
> Hi,
>
> in transactional mode with repeatable reads, the read entry is stored in
> the context, even if it is null (iiuc). However, in
Hi,
in transactional mode with repeatable reads, the read entry is stored in
the context, even if it is null (iiuc). However, in
TxDistributionInterceptor.visitGetKeyValueCommand the valueIsMissing()
is checked which returns true if entry.isNull() (in RepeatableReadEntry
this is implemented as
14 matches
Mail list logo
