://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
/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
On Oct 17, 2013, at 11:29 PM, Sanne Grinovero sa...@infinispan.org wrote:
On 17 October 2013 20:19, Mircea Markus mmar...@redhat.com wrote:
let's keep this on -dev.
+1
On Oct 17, 2013, at 6:24 PM, Sanne Grinovero sa...@redhat.com wrote:
- Original Message -
On Oct 17, 2013
Nice one!
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 Oct 18, 2013, at 1:06 PM, Sanne Grinovero sa...@infinispan.org wrote:
On 18 October 2013 12:12, Mircea Markus mmar...@redhat.com wrote:
On Oct 17, 2013, at 11:29 PM, Sanne Grinovero sa...@infinispan.org wrote:
On 17 October 2013 20:19, Mircea Markus mmar...@redhat.com wrote:
let's
let's keep this on -dev.
On Oct 17, 2013, at 6:24 PM, Sanne Grinovero sa...@redhat.com wrote:
- Original Message -
On Oct 17, 2013, at 2:28 PM, Sanne Grinovero sa...@redhat.com wrote:
- Original Message -
On Oct 17, 2013, at 1:31 PM, Sanne Grinovero sa...@redhat.com
On Oct 14, 2013, at 2:40 AM, Manik Surtani msurt...@redhat.com wrote:
On 13 Oct 2013, at 12:59, Mircea Markus mmar...@redhat.com wrote:
On 13 Oct 2013, at 00:27, Sanne Grinovero sa...@infinispan.org wrote:
I'm having the same question again, but it's about compatibility
On 13 Oct 2013, at 00:27, Sanne Grinovero sa...@infinispan.org wrote:
I'm having the same question again, but it's about compatibility with
Infinispan 5.3.
I've found infinispan-adaptor52, but there is no infinispan-adaptor53 ?
6.0 is allowed to break the compatibility with 5.3.
The
:59, Mircea Markus mmar...@redhat.com wrote:
On 13 Oct 2013, at 00:27, Sanne Grinovero sa...@infinispan.org wrote:
I'm having the same question again, but it's about compatibility with
Infinispan 5.3.
I've found infinispan-adaptor52, but there is no infinispan-adaptor53 ?
6.0
-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
- please follow the JIRA or let me know if there's anything missing:
http://goo.gl/y4Ky7t
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman
___
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
,
--
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 Sep 24, 2013, at 4:15 PM, Vladimir Blagojevic vblag...@redhat.com wrote:
Is there a document that outlines all responsibilities of a developer who is
doing the release?
https://docspace.corp.redhat.com/docs/DOC-28594
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
On 21 Sep 2013, at 23:07, Sanne Grinovero sa...@infinispan.org wrote:
On 19 September 2013 18:29, Mircea Markus mmar...@redhat.com wrote:
(Adding Jonathan who knows a thing or two about transactions.)
Given that READ_COMMITTED (RC) is less performant than REPEATABLE_READ (RR)
I don't see
FGAM.
The API would allow that.
On Sep 20, 2013, at 11:49 AM, Mircea Markus mmar...@redhat.com wrote:
Hi,
Most of the FGAM functionality can be achieved with grouping, by using
the FGAM key as a grouping key.
The single bit that seems to be missing from grouping to equivalent
this
capability for a single read of all aggregate parts. Is that right?
No, Cache.getGroup would allow you to do just that.
On Sep 20, 2013, at 11:49 AM, Mircea Markus mmar...@redhat.com wrote:
Hi,
Most of the FGAM functionality can be achieved with grouping, by using the
FGAM key
?
On Sep 20, 2013, at 11:49 AM, Mircea Markus mmar...@redhat.com wrote:
Hi,
Most of the FGAM functionality can be achieved with grouping, by using the
FGAM key as a grouping key.
The single bit that seems to be missing from grouping to equivalent the
functionality of FGAM is obtaining all
of requirements would need
to be more expert (more complex APIs).
I think the groupping API is slightly cleaner actually than the AtomiMap one,
but is just a matter of taste :-)
Emmanuel
Thanks for your feedback!
On Fri 2013-09-20 17:49, Mircea Markus wrote:
Hi,
Most of the FGAM
On 22 Sep 2013, at 13:57, Sanne Grinovero sa...@infinispan.org wrote:
On 22 September 2013 13:22, Mircea Markus mmar...@redhat.com wrote:
On 21 Sep 2013, at 23:07, Sanne Grinovero sa...@infinispan.org wrote:
On 19 September 2013 18:29, Mircea Markus mmar...@redhat.com wrote:
(Adding
On 22 Sep 2013, at 13:57, Sanne Grinovero sa...@infinispan.org wrote:
On 22 September 2013 13:22, Mircea Markus mmar...@redhat.com wrote:
On 21 Sep 2013, at 23:07, Sanne Grinovero sa...@infinispan.org wrote:
On 19 September 2013 18:29, Mircea Markus mmar...@redhat.com wrote:
(Adding
.
No, that's not supported.
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
,
--
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 guys,
ISPN 6.0 final is scheduled for 11 Oct.
Is there going to be an JBM 2.0 final release prior that date?
Paul, what JBM version does 6.0 integration into AS?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev
a Cache.getGroup does make sense in a general case
- reduce the code base
What do people think?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman
On Sep 20, 2013, at 4:44 PM, Adrian Nistor anis...@redhat.com wrote:
Could you detail please?
+1 :-)
On 09/20/2013 05:43 PM, Sanne Grinovero wrote:
On 20 September 2013 11:19, Mircea Markus mmar...@redhat.com wrote:
Thanks for the heads up!
It's not clear for me what the functional
No for this reason.
Sent from my iPhone
On 19 Sep 2013, at 06:30, Bela Ban b...@redhat.com wrote:
Does this delay the final release accordingly ?
On 9/19/13 12:14 AM, Mircea Markus wrote:
..because of some errors in the server build:
https://gist.github.com/mmarkus/6616484
Cheers
saving.
___
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
.
Thanks to everyone for their involvement and contribution!
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
..because of some errors in the server build:
https://gist.github.com/mmarkus/6616484
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman
http://infinispan.blogspot.co.uk/2013/09/new-persistence-api-in-infinispan.html
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo
.
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
the nodes in the
cluster and within the same node (multiple threads)
Does this apply to entries in the cache as well (ISPN-2284)?
no, only the entries in the store are iterated in parallel.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
the release.
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
PM, Sanne Grinovero wrote:
+1
and maybe you want SNAPSHOT dependencies of Hibernate Search ?
On 12 September 2013 16:08, Mircea Markus mmar...@redhat.com wrote:
Hi,
Whilst having dependencies on SNAPSHOT is not generally good, we do allow
SNAPSHOT dependencies between our own components
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead
.
How does that sound?
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 9 Sep 2013, at 12:13, Sanne Grinovero sa...@infinispan.org wrote:
On 9 September 2013 10:37, Pedro Ruivo pe...@infinispan.org wrote:
On 09/09/2013 10:18 AM, Dan Berindei wrote:
Hi guys
As you know, I'm working on ISPN-3051, allowing each node to take a
higher or lower proportion of
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://lists.jboss.org/mailman/listinfo/infinispan-dev
commits, as you say, may leave the code base
unstable and thus not atomic. Further, multiple commits may cancel each
other out in places (reverting or fixing code from a previous commit, etc)
so squashing will actually make reviewing easier and cleaner.
On 6 Sep 2013, at 13:05, Mircea Markus
with the new API.
Cheers
Guillaume
Le 6 sept. 2013 18:47, Mircea Markus mmar...@redhat.com a écrit :
Hi guys,
Part of Infinispan 6.0 we revamped the CacheStore API and the existing stores
need some work to be adapted to the new API.
Do you feel like updating the HBase(Justin
/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
Hi Ray,
Part of Infinispan 6.0 we revamped the CacheStore API. I've migrated the
LevelDB store to the new API, do you feel like giving it a go with the
Hibernate one?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan
I'll stick to the name, just that the name can get better.
Sent from my iPhone
On 2 Sep 2013, at 10:36, Galder Zamarreño gal...@redhat.com wrote:
On Aug 29, 2013, at 4:48 PM, Mircea Markus mmar...@redhat.com wrote:
That's the name-pair used in JSR-107.
Cache*Reader* and CacheWriter sounds
That's the name-pair used in JSR-107.
Cache*Reader* and CacheWriter sounds way more natural to me.
!load = offload
!read = write
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev
/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
, and viceversa, so keeping these
interfaces separated would make the mental effort required to bridge the
knowledge between the two easier.
+1 for following the JSR-107 approach.
we will.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
timeout);
void setConnection(String connection);
}
This wouldn't require writing a parser and would provide type safety. Wdyt?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev
On 14 Aug 2013, at 10:21, Radim Vansa rva...@redhat.com wrote:
On 08/13/2013 04:50 PM, Mircea Markus wrote:
On 13 Aug 2013, at 15:30, Galder Zamarreño gal...@redhat.com wrote:
On Aug 13, 2013, at 12:20 PM, Mircea Markus mmar...@redhat.com wrote:
On 13 Aug 2013, at 07:59, Galder Zamarreño
with
the fetchPeristentState which is again defined on a per loader basis.
How does it sound?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo
On 14 Aug 2013, at 08:09, Galder Zamarreño gal...@redhat.com wrote:
On Aug 13, 2013, at 1:39 PM, Sanne Grinovero sa...@infinispan.org wrote:
On 13 August 2013 11:48, Mircea Markus mmar...@redhat.com wrote:
On 13 Aug 2013, at 11:40, Galder Zamarreño gal...@redhat.com wrote:
We now have
.
Radim
On 08/14/2013 12:59 PM, Mircea Markus wrote:
Hi,
I'm not sure these config attributes are needed.
- *purgeThreads* configures the number of threads that run the storage
purging (removal of expired entries from the storage). The more threads
the faster the purging processes
restructuring it all,
let's do it all :-)
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
or
members who contribute to that cache store…etc. I don't think we're there
yet though.
Isn't that the goal, though? To have these maintained separately, at their
own pace?
We can still use a single repo with multiple branches.
Cheers,
--
Mircea Markus
Infinispan lead
On 14 Aug 2013, at 15:26, Sanne Grinovero sa...@infinispan.org wrote:
On 14 August 2013 11:15, Mircea Markus mmar...@redhat.com wrote:
Currently the preload attribute is configured at *loaders* level and the
first cache loader in the chain is used for preloading.
A better place for preload
to write their own XML parsing.
+1
The current parsing-free approach will be kept. Just that we'll add a template
for writing stores that would contain a sample optional parser.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
On 14 Aug 2013, at 20:53, Sanne Grinovero sa...@infinispan.org wrote:
On 14 August 2013 17:59, Mircea Markus mmar...@redhat.com wrote:
On 14 Aug 2013, at 15:26, Sanne Grinovero sa...@infinispan.org wrote:
On 14 August 2013 11:15, Mircea Markus mmar...@redhat.com wrote:
Currently
class=x format. With this in mind, given a
xxxStore, Infinispan can look at the xxxStore type, cache loader or writer,
or both, we can inherently determine whether it's a read-only cache store, a
write-only one or both.
Cheers,
On Aug 10, 2013, at 2:22 AM, Mircea Markus mmar...@redhat.com
on a specific ISPN core version so they can be
upgraded and released in isolation. I think both these can be achieved with
some mvn tricks if all of them reside in the same repo - Tristan?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
that you are working on it. Can you please let me know if you want me
to try out any patch. I will be glad to :-)
Thanks,
Madhu
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev
On 13 Aug 2013, at 15:30, Galder Zamarreño gal...@redhat.com wrote:
On Aug 13, 2013, at 12:20 PM, Mircea Markus mmar...@redhat.com wrote:
On 13 Aug 2013, at 07:59, Galder Zamarreño gal...@redhat.com wrote:
My preference is for #1.
The main reason is cos JSR-107 is about to hit
titled migrating data between the FileCacheStore -
SingleFileCacheStore).
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo
On 9 Aug 2013, at 12:06, Sanne Grinovero sa...@infinispan.org wrote:
On 9 August 2013 11:35, Manik Surtani msurt...@redhat.com wrote:
We should actually move all of this to infinispan-dev - cc'ing
infinispan-dev on my response.
On 9 Aug 2013, at 11:19, Mircea Markus mmar...@redhat.com
is more memory
consuming) then you should use replication.
If the amount of data increases or you're doing more writes, distribution is
the way to go.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
is configured or not.
@Manik, It's also interesting from a data grid perspective since it
highlights the boundaries of a cache vs data grid in this area.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
My bad, this was intended for ISPN-dev in the first place.
On 9 Aug 2013, at 16:34, Manik Surtani msurt...@redhat.com wrote:
Can we move this back to infinispan-dev, pls?
On 9 Aug 2013, at 16:29, Mircea Markus mmar...@redhat.com wrote:
On 6 Aug 2013, at 18:13, William Burns wbu
://github.com/jsr107/jsr107spec/tree/v0.8/src/main/java/javax/cache/integration
On Aug 6, 2013, at 7:13 PM, William Burns wbu...@redhat.com wrote:
- Original Message -
From: Manik Surtani msurt...@redhat.com
To: Mircea Markus mmar...@redhat.com
Cc: Infinispan Core Devs infinispan-core
On 9 Aug 2013, at 16:59, Manik Surtani msurt...@redhat.com wrote:
On 9 Aug 2013, at 16:29, Mircea Markus mmar...@redhat.com wrote:
My guess is Mircea was going for an overloaded method for bulkLoadKeys
where we want both one that takes a Collection and one that takes a
KeyFilter
On 9 Aug 2013, at 18:14, Dennis Reed der...@redhat.com wrote:
On 08/09/2013 07:55 AM, Mircea Markus wrote:
The only argument I found was that's the way the spec does it :-) I
think CacheLoader + CacheWriter is a nice OOP design, but is rather
theoretical. In all external users scenarios I
,
--
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 9 Aug 2013, at 23:54, Manik Surtani msurt...@redhat.com wrote:
And I've replied to yours. :)
Thanks! replied back :-)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev
-
From: Mircea Markus mmar...@redhat.com
To: infinispan -Dev List infinispan-dev@lists.jboss.org
Sent: Friday, 9 August, 2013 7:21:14 PM
Subject: [infinispan-dev] CacheLoader and CacheStore
Hi,
Apologies for the long email :-)
There have been several discussions around how the CacheStore
Currently the shared attribute is configured at *loaders* level, so all the
defined cache loaders inherit this attribute.
It should be configured on a per loader basis. Does anyone se any problem with
that?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
/DefensiveCopyTest.java
On Jul 18, 2013, at 2:44 PM, Mircea Markus mmar...@redhat.com wrote:
Hi,
We have the following behaviour when storeAsBinary is enabled:
- when an entry is added it is initially stored in binary format (byte[])
- when it is read from an *owning node
capacity allocated for storing an
entry is ((1+N)*N)/2.
So for storing 100MB of data you'd end up with a file with size 5GB. On top of
that the memory consumption grows proportionally, as we keep in memory
information about all the allocated segments on disk.
Cheers,
--
Mircea Markus
this at a further point, one SFCS prove itself.
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
intend
to do for example as part of the upcoming undeprecation of the
cachestore API.
Tristan
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Narayana supports this setup as the application server does.
AFAIK a similar design was discussed in 2010 in the Transactions over
Hot Rod design meeting; how would this be fundamentally different, if
that's possible to explain to a non-expert ?
Cheers,
--
Mircea Markus
Infinispan lead
Sent from my iPhone
On 31 Jul 2013, at 17:01, Sanne Grinovero sa...@infinispan.org wrote:
On 31 July 2013 16:01, Mircea Markus mmar...@redhat.com wrote:
On 30 Jul 2013, at 23:12, Sanne Grinovero sa...@infinispan.org wrote:
My experience with transactions is limited, so I likely am
Adding infinispan dev and Martin.
I think it makes a lot of sense for QE to run the tests you suggested.
Sent from my iPhone
On 30 Jul 2013, at 17:56, Shane Johnson shjoh...@redhat.com wrote:
I was looking at the code for this cache store the other day.
I noticed that is neither a log
commit. If the commit fails, the user is given the
opportunity to re-apply transaction's changed and that includes both memory and
local storage.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev
Infinium it is! http://www.samueladams.com/craft-beers/infinium
On 18 Jul 2013, at 17:41, Mircea Markus mmar...@redhat.com wrote:
It slept under the radar, but not too late to choose the successor for the
tactical nuclear penguin (aka Infinispan 5.3):
https://community.jboss.org/polls
On 25 Jul 2013, at 09:52, Sanne Grinovero sa...@infinispan.org wrote:
On 24 July 2013 18:42, Mircea Markus mmar...@redhat.com wrote:
On 24 Jul 2013, at 17:16, Sanne Grinovero sa...@infinispan.org wrote:
Also:
- support to efficiently preload only the owned entries
We'd still need
On 25 Jul 2013, at 14:54, Adrian Nistor anis...@redhat.com wrote:
Ah, but that could easily be done with the Filter that was already
proposed.
+1
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
with this?
On 24 Jul 2013, at 11:55, Mircea Markus mmar...@redhat.com wrote:
Hi,
Starting from the original document Manik rolled out a while ago [1], here's
the list of requirements I'm currently aware of in the context of the new
CacheStore API:
- better integration with the fluent API
/jsr107spec/blob/v0.8/src/main/java/javax/cache/integration/CacheWriter.java#L59
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo
on not depending on it, but design it in such way that's easy to
write such adapter. IOW, make sure the functionality in the JSR-107 API is
covered easily, without having add boiler-plate code :)
+1
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
a reference to the
CacheManager in the CacheStore instance.
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
compare on deserialised index values?
This is potentially quite slow, and requires that matching Java classes are
provided on the server side even if the client is .NET
Rob
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
/blob/master/loader/src/main/java/com/seovic/loader/Source.java
[3]
https://github.com/aseovic/coherence-tools/blob/master/loader/src/main/java/com/seovic/loader/Target.java
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
the
potentially huge memory consumption and the complexity added.
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
believe the root cause
for #1 and #2 is the same.
On 7/17/13 12:46 PM, Mircea Markus wrote:
Thanks Ray!
I think the issue is: https://issues.jboss.org/browse/JGRP-1659
Bela the test is attached to the JIRA.
Ray, I think your harness can be pretty useful as a general purpose tool
dump pointing to
MFC as well.
Bela, could I trouble you to increase the payload size to max of 3mb?
E.g. Multiply randomSize * 60k
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev
.
MarshalledValueInterceptor.visitGetKeyValueCommand() invokes
MarshalledValueInterceptor.compact(mv). The *mv* parameter , at least for
values, is null.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev
-Dnode=1
mvn -e exec:exec -Dnode=2
mvn -e exec:exec -Dnode=3
...
It'll prompt you to press a key when ready. When you confirm cluster has
formed, press any key to continue on all the nodes.
Thanks,
replication-test.zip
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
discussing and I think it is related to the above use case.
After having some random-caffe-chats with Dan and Sanne, a possible solution
came up:
https://community.jboss.org/wiki/ControlledClusterShutdownWithDataRestoreFromPersistentStorage
Feedback appreciated!
Cheers,
--
Mircea Markus
___
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
201 - 300 of 986 matches
Mail list logo
