://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
to succeed even if the value has changed in
between the read time and commit time. But that's only if your application can
live with that, i.e. an application specific decision.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan
to the same infinispan key then?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Hi,
There are some very important pull requests pending:
- protostream[1] integration in the java hotrod client
- file cache store
- advanced stats
Let's release on Mon given that the above would make it in.
[1] https://github.com/infinispan/protostream
Cheers,
--
Mircea Markus
Infinispan
needs to be aware of the staggering. I'd think it is the
responsibility of the caller (DistributionInterceptor) to orchestrate
staggering..
Also, would the changes in configuration would require making a change in XSD
schema file?
Thanks!
Hammad
`
Cheers,
--
Mircea Markus
On 12 Jul 2013, at 18:22, Mircea Markus mmar...@redhat.com wrote:
(Adding -dev)
On 12 Jul 2013, at 05:04, Hammad Said hs...@redhat.com wrote:
I have implemented the change for address ordering in and created the topic
branch optimize_staggered-get in:
https://github.com/hsaid4327
an entry is
committed to the data container.
Any comments/concerns would be appreciated.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman
implementation entirely by the end of 6.0 then
I don't see a problem with having different packages.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org
in that file :-)
AppendOnlyFileCacheStore looks good to me...
or name it FileCacheStore but move it in another package, e.g.
org.infinispan.loaders.filestore
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing
in the
InternalCacheEntrie's implementation, including serialization format
(Metadata..CacheEntry). Do you have a stack trace for that?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev
compatible. At least up to Infinispan 5.3.0
as per Sanne's email.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
likely be easier for
you to provide such a tool in ModeShape to extract all data and dump
it to some external file, than to provide the hooks in Infinispan as
the transcoding tool would need to depend on multiple Infinispan
versions.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
compatibility
will allow library-mode rolling upgrades as well.
Still, I'd prefer any migration to happen via rolling upgrades over some
custom cache-store migration, if that would be possible.
+1. Curious to see Tristan's thoughts on this :-)
Cheers,
--
Mircea Markus
Infinispan lead
of this
WriteSkewTest.testWriteSkewWithOnlyPut.
Is it to test the write skew check in Local mode caches?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org
way.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
is locked only in prepare (and the
write skew check is performed).
I'm gonna change the test to use the IGNORE_RETURN_VALUES in the put
operation. This should not trigger the write skew check and all the
threads should run as expected
+1
Cheers,
--
Mircea Markus
Infinispan lead
) will keep a reference to L1DC to query, store, etc.
The EntryWrappingInterceptor (EntryFactory) also look up values in the DC.
Makes sense.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev
adaptive system.
+1
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
likely to be passivated (it
counts as a hit), the current design naturally provides an optimal
balance for memory usage.
At the opposite site, I don't see how - as a user - I could optimally
tune a separate container.
Very good points Sanne.
Cheers,
--
Mircea Markus
Infinispan lead
an important reason to always favour owned
entries over *hotter* entries I'd be less skeptical, but even so that
would be a step backwards in ease of configuration as today the grid
basically self-tunes ergonomically.
+1
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
Does it come with other indirect dependencies or is just that?
On 2 Jul 2013, at 16:18, Galder Zamarreño gal...@redhat.com wrote:
If it's in a separate module, I'm fine with it.
+1.
I'll comment on specifics about the stats in the pull req...
Cheers,
--
Mircea Markus
Infinispan lead
.
Brno, Purkyňova 99/71, PSČ 612 45
Czech Republic
sources.zip___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
be disabled for obvious reasons.
+1
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
with previous releases as
SiteUUID is now different. The change would be in 3.4 (not 3.3.x), and
as it will be used by Infinispan 6.0, I don't think this should be an
issue...
Thoughts ?
I don't see any issue with it either.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
it is included in future releases.
Tristan
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
if the primary owner is passivating it.
Write operations are inherently safe as they have to go through the
owner and trigger entry activation as needed.
+1
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing
/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
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
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing
interfaces: AsyncCache, TransactionalCache, QueryableCache, etc and add
them to the RemoteCache as we will in the blanks, since we are aiming at
feature parity. This could also mix well with the ideal of having the
JCache API as our public API.
Cheers,
--
Mircea Markus
Infinispan lead
ugly.
From a user point of view, I tend to like this approach more than the stream
one. Especially since I don't have to do anything for the first schema
version.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https
cache.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
, this would prove as the validation that the data have really
been written to the persistence layer. Or is this queue simply unbounded?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev
On 9 Jul 2013, at 13:15, Sanne Grinovero sa...@infinispan.org wrote:
On 8 July 2013 20:37, Mircea Markus mmar...@redhat.com wrote:
TBH I think having the RemoteCache implementing Cache wasn't such a good
idea as it caused confusion through users: e.g. people trying to use
transactions
On 9 Jul 2013, at 13:47, Sanne Grinovero sa...@infinispan.org wrote:
Indeed that's an excellent idea. But I would add also a common parent
interface having the basic functionality common to all.
If ConcurrentMap doesn't have what we need, of course :-)
On 9 July 2013 11:39, Mircea Markus
On 9 Jul 2013, at 20:07, Sanne Grinovero sa...@infinispan.org wrote:
On 9 July 2013 18:01, Mircea Markus mmar...@redhat.com wrote:
On 9 Jul 2013, at 13:47, Sanne Grinovero sa...@infinispan.org wrote:
Indeed that's an excellent idea. But I would add also a common parent
interface having
On 5 Jul 2013, at 12:31, Sanne Grinovero sa...@infinispan.org wrote:
On 4 July 2013 23:25, Mircea Markus mmar...@redhat.com wrote:
On 4 Jul 2013, at 14:23, Sanne Grinovero sa...@infinispan.org wrote:
I'm puzzled by the pace.
We just forked from 5.3,
Just forked ? :-)
By the time we
And here is the list of issues scheduled for this release: http://goo.gl/45Osp
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo
Hibernate Search 5.0, but
we barely started that work. With this pace it means we'll switch to
Search 5.0 (and new API) in a late phase of Infinispan 6.0 releases.
Again I don't see how these are related. There are more alphas on the way in
which we can tackle that.
Cheers,
--
Mircea Markus
Adding infinispan dev.
Sent from my iPhone
On 27 Jun 2013, at 22:59, Divya Mehra dme...@redhat.com wrote:
Fyi -
Input from Hiram on #jdg regarding levelDB configuration for better
performance [1]
chirino
2:48 was reviewing the leveldb bits and it seems like compression is off by
a
little bit cleaner as to where it's located.
Thoughts?
Indeed sounds is a good suggestion but as Sanne mentioned this would break the
backward compatibility which is something we want to avoid.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
and commits
cache.get(k) //return the new value. IMO, this is not valid for
REPEATABLE_READ isolation level!
Indeed sounds like a bug, well spotted.
Can you please add a UT to confirm it and raise a JIRA?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
above should be valid after a removal of a key.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
happen:
There is a lock happening *without* L1 enabled.
tx1@A: remote get(k1) from B - stores k1=v1 in invocation context
tx2@A: write(k1, v2)
tx2@A: commit - writes k1=v2 in L1
tx1@A: commit - overwrites k1=v1 in L1
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
More about it here:
http://infinispan.blogspot.de/2013/06/infinispan-530cr2-is-out.html
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman
Hi,
Master was updated to point to 6.0.0. Please port any pending 5.3.x fixes to
both master and the 5.3.x branch.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https
Hi,
Following the tradition, each Infinispan release is code is a beer.
Suggestions?
I'll start:
- Infinium
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https
-mode-it/module
modulejcache/module
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
with reordered commits.
Do you still need the JProfiler output with/without ISPN-2772?
Radim
- Original Message -
| From: Mircea Markus mmar...@redhat.com
| To: infinispan -Dev List infinispan-dev@lists.jboss.org
| Sent: Thursday, June 13, 2013 9:30:56 PM
| Subject: [infinispan-dev
Sent from my iPhone
On 14 Jun 2013, at 13:43, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
Thanks for this reply, Mircea.
Very interesting approach. By dispatching a distributed executor back to
the node (node 0) that produced the pinned key affinity for the object's
natural key, we
Sent from my iPhone
On 14 Jun 2013, at 19:14, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
/ Another thing you can do is have a replicated Cache holding the mapping
between the actual keys and the affinity keys./
Yes, no doubt about it. This will work.
But, it technically
Sent from my iPhone
On 14 Jun 2013, at 19:39, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
/ Can you leave with this limitations? /
Yes.
Just to reiterate, your *never* expects a node to crash?
--
View this message in context:
Sent from my iPhone
On 14 Jun 2013, at 20:08, Dan Berindei dan.berin...@gmail.com wrote:
Just to be clear, KAS doesn't really allow you to pin a key to a certain
node. It only gives you a key that maps to the given node the moment you
called KAS.getKeyForAddress(Address) - by the time you
Sent from my iPhone
On 14 Jun 2013, at 20:54, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
so, in the event that no topology change takes place, may I otherwise
consider this key2node association /reliable/?
Yes
___
infinispan-dev mailing list
Sent from my iPhone
On 14 Jun 2013, at 20:02, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
/
Just to reiterate, your *never* expects a node to crash? /
Easy now, Mircea!
All of us in the distributed computing community know
I'm just trying to help Ben.
that we live in a
world
(as found
in 113842c8cf91cbb5a1bbd26e05fab7024fdec081) to true (as appears in later
commits), is this desired?
That has been changed on purpose to be true later on when fixing: ISPN-3043:
Make synchronous backup calls use the OOB thread pool.
Cheers,
--
Mircea Markus
Infinispan lead
config) had:
- old bundler: 1.3M reads/s, 4300 writes/s
In other words there's no performance regression, but the contrary.
BTW what's the performance of 5.2.x branch with which we should compare against.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
.
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing
.
If I'm not we should provide a backward compatible layer for the sake of
performance.
[1]
https://docs.jboss.org/author/display/ISPN/Locking+and+Concurrency#LockingandConcurrency-Nontransactionalcachesandconcurrentupdates%26nbsp%3B
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
Sent from my iPhone
On 13 Jun 2013, at 17:45, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
We need a way for a foreign node to be able to come up with the same
affinityKey produced earlier by a local node.
Thanks for the response, Mircea. Let me elaborate.
E.g. consider the
document there's a (very common-sense) exception for conditional
writes were the flag is ignored (ISPN-3141).
+1
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https
On 10 Jun 2013, at 10:33, Dan Berindei dan.berin...@gmail.com wrote:
On Thu, Jun 6, 2013 at 9:08 PM, Ray Tsang saturn...@gmail.com wrote:
On Jun 6, 2013, at 13:26, Mircea Markus mmar...@redhat.com wrote:
On 4 Jun 2013, at 13:55, Dan Berindei dan.berin...@gmail.com wrote
have not noticed the regression between
these builds.
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea
the fix in 5.3.1.Final
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Radim, can you please give Pedro's branch a try?
https://github.com/infinispan/infinispan/pull/1896
If all good we'll release CR2 from that one.
On 12 Jun 2013, at 16:02, Bela Ban b...@redhat.com wrote:
On 06/12/2013 10:57 AM, Mircea Markus wrote:
I think we should treat this as a bug
Given the amount of pending fixed, I'm thinking to cut an 5.3.0.CR2 (last CR)
on Tue 11 June.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org
large change.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
+ IGNORE_RETURN_VALUES doesn't make any sense :-)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
have updated the main page but I haven't found how to delete the child
page.
The blog post has been updated you can publish whenever you want to.
Guillaume
2013/5/30 Mircea Markus mmar...@redhat.com
Also better place the content in the parent document directly instead
used for a get() operation… I can see myself
thinking: Why on earth do you call get with IGNORE_RETURN_VALUES?
Isn't Galder's point not to allow invoking get with IGNORE_RETURN_VALUES? As
both of you pointed out, Get + IGNORE_RETURN_VALUES doesn't make any sense :-)
Cheers,
--
Mircea Markus
misses the example (Here is an exemple: - blank) and
your signature :-)
Please add that and the publish it ;)
Guillaume
2013/5/30 Mircea Markus mmar...@redhat.com
Also better place the content in the parent document directly instead of
making it a separate child document (see the rest
-dev/2013-May/012920.html
+1. I think this is the way to go, as running mongodb wouldn't require
additional setup.
Guillaume, is this something you can look at?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev
/2013-May/012920.html
+1
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
of option would only be used where data loss isn't an issue
(such as a distributed cache). Where data loss is an issue, we'd need more
control - ISPN-1394.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing
On 4 Jun 2013, at 10:42, Guillaume SCHEIBEL guillaume.schei...@gmail.com
wrote:
I'll have a look for the embedding mongo part.
Thank you Guillaume.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
should be done with
care. I think they make sense at times, especially with local cache. Having
them partially implemented creates confusion through the users.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev
at the local level (tools can be used to aggregate results, or
even map/reduce?)
Agreed. Infinispan 6.0 is quite loaded as it is, let's do it in next major.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
,
- Will
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing
:
infinispan.blogspot.com/2013/05/infinispan-530cr1-is-out.html
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
://docs.jboss.org/author/display/ISPN/MongoDB+CacheStore
WDYT ?
about the blog post a gist (script tag) is already there but it's not visible
in the editor view.
Guillaume
2013/5/27 Mircea Markus mmar...@redhat.com
On 22 May 2013, at 11:01, Guillaume SCHEIBEL guillaume.schei
, 2013, at 8:25, Mircea Markus mmar...@redhat.com wrote:
Hi Ray,
First of all big thanks for developing this feature, it's been a while
since it has been on the roadmap and judging by the number of JIRA watches
quite a popular pice of functionality too! Can you please add a blog post
with such non-deterministic behaviour.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
/ModeShape/modeshape/blob/master/modeshape-jcr/src/test/java/org/modeshape/jcr/value/binary/MongodbBinaryStoreTest.java
On May 21, 2013, at 1:04 PM, Mircea Markus mmar...@redhat.com wrote:
Thanks to Guillaume Scheibel, Infinispan now has an mongodb cache store that
will be shipped
/jcr/value/binary/MongodbBinaryStoreTest.java
Thanks Randall, looks practical.
Guillaume is this something you can add at some point?
On May 21, 2013, at 1:04 PM, Mircea Markus mmar...@redhat.com wrote:
Thanks to Guillaume Scheibel, Infinispan now has an mongodb cache store
as well[2].
[1] infinispan.blogspot.com
[2] https://docs.jboss.org/author/display/ISPN/Cache+Loaders+and+Stores
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https
Sent from my iPhone
On 20 May 2013, at 16:59, Galder Zamarreño gal...@redhat.com wrote:
Right, that script should not be there any more since we know have a
separated download for Infinispan servers.
@Tristan, can we get it sorted for next release? Maybe do a little blog post
about it
Sent from my iPhone
On 20 May 2013, at 12:58, Dan Berindei dan.berin...@gmail.com wrote:
On Mon, May 20, 2013 at 1:57 PM, Manik Surtani msurt...@redhat.com wrote:
On 16 May 2013, at 15:04, Dan Berindei dan.berin...@gmail.com wrote:
Hi guys
I'm working on an intermittent failure
:
On 7 May 2013, at 15:39, Martin Gencur mgen...@redhat.com wrote:
I can make a blog post once we have this for Memcached and REST. I guess
it is not ready yet.
Yes please. Nice work. :)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
Sent from my iPhone
On 23 May 2013, at 12:06, Bela Ban b...@redhat.com wrote:
On 5/23/13 12:38 PM, Manik Surtani wrote:
Yup, it needs to happen sometime. But the question is, when?
Is there anyone out there who desperately needs Infinispan to work on Java 6?
I got a lot of
-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https
replaceIfPresentOrPutIfNotPresentAndHashCodeIsEvenOtherwiseRemoveNextKey();
for clarity.
I'll blame it on the London weather :-)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
On 22 May 2013, at 12:36, Bela Ban b...@redhat.com wrote:
On 5/22/13 1:17 PM, Mircea Markus wrote:
On 21 May 2013, at 11:14, Bela Ban b...@redhat.com wrote:
[Mircea]
Might be a problem in xsite replication when the keys that are updated
are not present. This happens all the time
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan
/author/display/ISPN/Cache+Loaders+and+Stores
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
301 - 400 of 986 matches
Mail list logo
