of the nodes
(coordinator?) which would explain this?
I am attaching the configuration file.
Radim Vansa
Quality Assurance Engineer
JBoss Datagrid
tel. +420532294559 ext. 62559
Red Hat Czech, s.r.o.
Brno, Purkyňova 99/71, PSČ 612 45
Czech Republic
repl-sync-tx.xml
Description: XML document
: Tuesday, September 11, 2012 9:44:20 AM
| Subject: Re: [infinispan-dev] Fast writes on one node with pessimistic
locking
|
|
| Consistently reproducible?
|
|
|
| On 11 Sep 2012, at 08:26, Radim Vansa rva...@redhat.com wrote:
|
|
| Hi,
|
| when I was looking on results of some tests
Hi,
yes, we did this kind of tests for ispn 5.1 releases. There was pretty easy to
analyze the join time parsing the logs for debug messages from
CacheViewsManagerImpl, one such example is
wouldn't
want to investigate why such deadlock happened :)
Btw., in OLE.visitPrepareCommand the log.tracef(Using lock reordering, order
is: %s, orderedKeys); does not work, only the first key is printed out.
Radim
---
Radim Vansa
Quality
|
| 3# Since get operations are always local (site), they are as you say
| not meaningful for the benchmark; now since put operations are also
| not meaningful as it's async .. what is the benchmark measuring?
|
That's an assumption and the test is there also to confirm it. For example in
my
and it's
preferable to have the configurations as close as possible. The only settings
we need to keep different are thread pool sizes and addresses and ports.
Radim
---
Radim Vansa
Quality Assurance Engineer
JBoss Datagrid
tel. +420532294559
.
|
| Cheers
| Dan
|
|
|
|
|
| On Mon, Dec 17, 2012 at 4:55 PM, Radim Vansa rva...@redhat.com
| wrote:
|
|
| Sorry I haven't specified the amount, I am a stupido... my tests are
| working with 500k credits.
|
| UUPerf (JGroups 3.2.4.Final-redhat-1) from one computer in perflab to
| another, 2
PM, Bela Ban b...@redhat.com wrote:
|
|
| Let's make sure though that we have a meaningful default that's not
| optimized for an edge case. Also, if we use TCP, we can remove UFC
| from
| the config, as TCP already performs point-to-point flow control.
|
|
|
| On 1/3/13 11:29 AM, Radim Vansa
not
| | optimized for an edge case. Also, if we use TCP, we can remove UFC
| | from
| | the config, as TCP already performs point-to-point flow control.
| |
| |
| |
| | On 1/3/13 11:29 AM, Radim Vansa wrote:
| | 20k credits seems to be the best choice for this test:
| |
| | 10k: bad performance
| | 20k
and that no-tx case works intuitively (no deadlocks) and really
fast :)
Radim
---
Radim Vansa
Quality Assurance Engineer
JBoss Datagrid
tel. +420532294559 ext. 62559
Red Hat Czech, s.r.o.
Brno, Purkyňova 99/71, PSČ 612 45
Czech Republic
such
high-level thingie as ispn?).
Radim
| On 4 Jan 2013, at 09:23, Radim Vansa rva...@redhat.com wrote:
|
| Hi,
|
| I have created a comparison how JDG (library mode) behaves
| depending on the contention on keys. The test runs standard (20%
| puts, 80% gets) stress test on different amount
which ones without using the above mentioned tools ;-)
|
| thanks a lot,
| Sanne
|
| On 4 January 2013 15:26, Radim Vansa rva...@redhat.com wrote:
| |
| | As for the low contention cases, I think they're all about the
| | same
| | as the probability for contention is all very low given
is the same; namely to avoid having an incoming thread block
| on
| a sync RPC.
|
| Thoughts ?
|
|
|
|
| On 2/1/13 9:04 AM, Radim Vansa wrote:
| Hi guys,
|
| after dealing with the large cluster for a while I find the way how
| we use OOB threads in synchronous configuration non-robust
It's not a potential, I can confirm that you cannot run anything with TRACE
logging, with log4j logging to NFS the traces can block the whole node and
break things.
Even ISPN works, listing through StateResponseCommand in the logs can sometimes
block less viewer. Nevertheless, the TRACE info
:15 PM, Radim Vansa rva...@redhat.com
| wrote:
|
|
| Hi Manik,
|
| so I have tried to compile this branch and issued a 20 minute stress
| test (preceded by 10 minute warmup) on 128 nodes, where each node
| has 10 stressor threads.
| While in 5.2.0.CR3 the maximum OOB threadpool size was 553
but without exception set (the objectFuture.get() is
interrupted, I am not sure why this happens, but it happens) the thread blocks
infinitely. I have patched it and hope I'll get results soon.
Radim
- Original Message -
| From: Manik Surtani msurt...@redhat.com
| To: Radim Vansa rva
(mainly the OOB maximum size distribution) in attachment.
Config: library mode, non-transactional distributed cache with 2 owners and 512
segments, sync replication.
Test: 10m warmup, 20m test, 10 stressing threads per node.
Radim
- Original Message -
| From: Radim Vansa rva...@redhat.com
Blocking OOB threads is the thing we want to avoid, remember?
I am used do synchronous replication, there we could hold a semaphore on
requests to each node. Going down before each RPC and up after that would be
pretty simple and having this mechanism in RPC layer it would block only
request,
- Original Message -
| From: Dan Berindei dan.berin...@gmail.com
| To: infinispan -Dev List infinispan-dev@lists.jboss.org
| Sent: Thursday, March 14, 2013 10:03:10 AM
| Subject: Re: [infinispan-dev] DefaultExecutorFactory and rejection policy
|
| On Thu, Mar 14, 2013 at 9:32 AM, Radim
And will conditional operations on byte[] work as well within this fix? I have
just noticed that in library mode I can't use remove with byte[] value (should
I file a feature request JIRA for that?)
Radim
- Original Message -
| From: Tristan Tarrant ttarr...@redhat.com
| To: infinispan
And the nice behaviour is that if we have partitions P1 and P2 with latest
common topology 20 , when P2 increased it's topology to, say 40, while P1 only
to 30, when a new coordinator from P1 will be elected it will try to compare
these topology ids directly (assuming which one is newer or
Do you have the numbers for JDK 7 as well?
Radim
- Original Message -
| From: Manik Surtani msurt...@redhat.com
| To: infinispan -Dev List infinispan-dev@lists.jboss.org
| Sent: Friday, April 19, 2013 4:35:53 AM
| Subject: [infinispan-dev] CHM or CHMv8?
|
| Guys,
|
| Based on some
Hi, I've checked it on 4 nodes, stress test 15 minutes with 80% writes. Both
reads and writes have improved in 5.2
READS/sec 247k - 263k
WRITES/sec 4547 - 4771 (note: this is average, coordinator has about 2x more
writes as it is the lock owner for all locks in replicated mode)
that makes
- Original Message -
| From: Galder Zamarreño gal...@redhat.com
| To: Radim Vansa rva...@redhat.com
| Cc: infinispan-internal Internal infinispan-inter...@redhat.com
| Sent: Thursday, May 2, 2013 7:49:53 PM
| Subject: Re: [infinispan-internal] Message flow tracer/analyzer
|
| Did you
, this framework is cerainly already useful ! Do you
| have a more detailed docu on what the numbers mean ?
More detailed than
https://github.com/rvansa/message-flow-tracer/blob/master/README.txt ? If you
miss anything there, just remind me.
Radim
|
| On 5/3/13 10:36 AM, Radim Vansa wrote
:
| Chronicle?
|
|
http://binarybuffer.com/2013/04/java-chronicle-library-tutorial-1-basic-examples
| https://github.com/peter-lawrey/Java-Chronicle
|
|
|
| On 7 May 2013, at 16:43, Radim Vansa rva...@redhat.com wrote:
|
| OK, I'll post more info after I add some more analyses.
|
| Btw., could you
request). But OK, it could be affected in
some complicated fashion, let's focus on the writes.
Radim
|
| Cheers,
| Pedro Ruivo
|
| On 06/12/2013 09:54 AM, Radim Vansa wrote:
| Hi,
|
| I was going through the commits (running tests on each of them) to seek the
| performance regression we've
- Original Message -
| From: Bela Ban b...@redhat.com
| To: infinispan-dev@lists.jboss.org
| Sent: Wednesday, June 12, 2013 3:16:58 PM
| Subject: Re: [infinispan-dev] New bundler performance
|
|
|
| On 06/12/2013 04:54 AM, Radim Vansa wrote:
| Hi,
|
| I was going through
Seems that it's somewhat better (6050 writes/s) but not at the previous level.
I am trying to cherry-pick it directly on the commit that failed it and see
where is the difference, then maybe I'll have to generate alternative branch
with ISPN-3221 commit after ISPN-2848
| Seems that it's somewhat better (6050 writes/s) but not at the previous
| level.
| what about the reads?
After Pedro's question I have tried to run ISPN-3221 fix with both old an new
bundler (in configuration), and the result pretty surprises me as there should
not be much of a difference
- Original Message -
| From: Galder Zamarreño gal...@redhat.com
| To: Radim Vansa rva...@redhat.com
| Cc: infinispan -Dev List infinispan-dev@lists.jboss.org
| Sent: Monday, June 24, 2013 12:46:52 PM
| Subject: Re: [infinispan-internal] LevelDB performance testing
|
| Putting Infinispan
/radargun/tree/t_keygen
---
Radim Vansa
Quality Assurance Engineer
JBoss Datagrid
tel. +420532294559 ext. 62559
Red Hat Czech, s.r.o.
Brno, Purkyňova 99/71, PSČ 612 45
Czech Republic
___
infinispan
Message-
| From: infinispan-dev-boun...@lists.jboss.org
| [mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Radim Vansa
| Sent: Wednesday, June 26, 2013 11:24 AM
| To: infinispan -Dev List
| Subject: [infinispan-dev] Cachestores performance
|
| Hi all,
|
| according to [1] I've created
I have added FileChannel.force(false) flushes after all write operations in the
cache store, and now the comparison is also updated with these values.
Radim
- Original Message -
| From: Radim Vansa rva...@redhat.com
| To: infinispan -Dev List infinispan-dev@lists.jboss.org
| Sent
Oops, by the cache store I mean the previously-superfast KarstenFileCacheStore
implementation.
- Original Message -
| From: Radim Vansa rva...@redhat.com
| To: infinispan -Dev List infinispan-dev@lists.jboss.org
| Sent: Thursday, June 27, 2013 11:30:53 AM
| Subject: Re: [infinispan-dev
be worth sparing a few
disk look-ups.
Radim
|
| On 27 Jun 2013, at 10:33, Radim Vansa rva...@redhat.com wrote:
|
| Oops, by the cache store I mean the previously-superfast
| KarstenFileCacheStore implementation.
|
| - Original Message -
| | From: Radim Vansa rva...@redhat.com
|
| My worry about Karsten's impl is writing actually. If you look at the
| last performance numbers in [2], where we see the performance difference
| of force=true and force=false in Karsten's cache store compared with
| LevelDB JNI, you see that force=false is fastest, then JNI LevelDB,
Hi,
I've written down this proposal for the implementation of new cache store.
https://community.jboss.org/wiki/BrnoCacheStoreDesignProposal
WDYT?
Radim
- Original Message -
| From: Radim Vansa rva...@redhat.com
| To: infinispan -Dev List infinispan-dev@lists.jboss.org
| Sent
bad.
|
| Cheers,
| Sanne
|
|
|
| On 2 July 2013 10:09, Radim Vansa rva...@redhat.com wrote:
| Hi,
|
| I've written down this proposal for the implementation of new cache store.
|
| https://community.jboss.org/wiki/BrnoCacheStoreDesignProposal
|
| WDYT?
|
| Radim
|
| - Original
|
| I've used three implementations: one simply synchronizing the access and
| calling force(false) after each write (by default 1kB). Second with
| threads cooperating - every thread puts its data into queue and waits for
| a short period of time - if then its data are still in the queue,
- Original Message -
| From: Galder Zamarreño gal...@redhat.com
| To: infinispan -Dev List infinispan-dev@lists.jboss.org
| Sent: Friday, July 5, 2013 7:46:03 AM
| Subject: Re: [infinispan-dev] Appending to file
|
|
| On Jul 3, 2013, at 10:20 AM, Radim Vansa rva...@redhat.com wrote
- Original Message -
| From: Galder Zamarreño gal...@redhat.com
| To: infinispan -Dev List infinispan-dev@lists.jboss.org
| Sent: Tuesday, July 9, 2013 10:32:52 AM
| Subject: [infinispan-dev] Integrating Karsten's FCS
|
| Hi,
|
| I think we all agree that Karsten's file cache store is
- Original Message -
| From: Randall Hauch rha...@redhat.com
| To: infinispan -Dev List infinispan-dev@lists.jboss.org
| Sent: Tuesday, July 9, 2013 3:37:36 PM
| Subject: Re: [infinispan-dev] Integrating Karsten's FCS
|
|
| On Jul 9, 2013, at 4:07 AM, Radim Vansa rva...@redhat.com wrote
On 07/30/2013 07:18 PM, Mircea Markus wrote:
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
On 07/31/2013 10:31 AM, Mircea Markus wrote:
On 30 Jul 2013, at 20:03, Shane Johnson shjoh...@redhat.com wrote:
One option might be to use a fix key set size and simply increment the value
for each key by X every time it is written. Sort of like an object with a
collection and every time a
...@lists.jboss.org
[mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Radim Vansa
Sent: Monday, August 12, 2013 6:13 PM
To: infinispan-dev@lists.jboss.org
Subject: Re: [infinispan-dev] Recommended Cluster Size for Replication Mode
Hi,
which version exactly do you use, 5.2.x, 5.3.x or 6.0.x
Of Radim Vansa
Sent: Tuesday, August 13, 2013 2:08 PM
To: infinispan-dev@lists.jboss.org
Subject: Re: [infinispan-dev] Recommended Cluster Size for Replication Mode
Yes, with 5.2.3 it makes sense - in replication mode there were less messages
used for the write but key may have different value
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 gal...@redhat.com wrote:
My preference is for #1.
The main
It seems to me that these attributes may not be common to all cache
stores. For some stores, the purging can be executed as part of other
process anyway and it is not desired to purge the store on-demand. Some
stores may not be able to purge in parallel at all (for example some
single-file
On 08/14/2013 08:58 PM, Mircea Markus wrote:
On 14 Aug 2013, at 18:48, Dennis Reed der...@redhat.com wrote:
I've written such parser on Friday, basically just copying and rewriting
the SingleFileCacheStore stuff (adding my own properties instead). It
took me about an hour and I don't hate
On 08/15/2013 03:57 PM, Ray Tsang wrote:
On Thu, Aug 15, 2013 at 9:48 AM, Galder Zamarreño gal...@redhat.com
mailto:gal...@redhat.com wrote:
On Aug 14, 2013, at 11:14 PM, Ray Tsang saturn...@gmail.com
mailto:saturn...@gmail.com wrote:
I actually did not enjoy writing parsers
: infinispan-dev-boun...@lists.jboss.org
[mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Radim Vansa
Sent: Tuesday, August 13, 2013 5:34 PM
To: infinispan-dev@lists.jboss.org
Subject: Re: [infinispan-dev] Recommended Cluster Size for Replication Mode
On 08/13/2013 11:58 AM, Faseela K
hotrod client will have a release cycle different than ISPN, hence
keeping it in its own separate project.
Cheers,
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org
not be
required if we find that Read Committed itself is flawed beyond
saving.
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
September 2013 09:06, Radim Vansa rva...@redhat.com wrote:
~ I think that Read Committed isolation level is not obliged to present
~ you with up-to-date committed data - the only fact is that it can, but
~ application must not rely on that. It's lower isolation level.
~ Nevertheless, I think
of us.
Radim
[1] https://issues.jboss.org/browse/JGRP-1675
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
I remember seeing that mostly on UDP, but I've had an issue with this
over TCP as well on the cross-site link with multiple site masters
(synchronous 1pc xs replication).
Radim
On 10/11/2013 02:51 PM, Ray Tsang wrote:
Udp or tcp?
On Oct 11, 2013, at 8:41, Radim Vansa rva...@redhat.com wrote
-dev-boun...@lists.jboss.org
[mailto:infinispan-dev-boun...@lists.jboss.org
mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of
Radim Vansa
Sent: Friday, October 11, 2013 8:41 AM
To: infinispan-dev@lists.jboss.org
mailto:infinispan-dev
.
Erik
-Original Message-
From: infinispan-dev-boun...@lists.jboss.org
[mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Radim Vansa
Sent: Friday, October 11, 2013 8:41 AM
To: infinispan-dev@lists.jboss.org
Subject: [infinispan-dev] Is anyone else experiencing JGRP-1675
Hi
like to know value of A - getting A = 1 will break the constraint.
And there's no way to get A's value besides reading it directly from cache.
Radim
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev mailing list
infinispan-dev
with expected value to compare *
class abstract AdvancedWriteCommand extends WriteCommand
Object expectedValue
match(Object currentValue) {return currentValue.equals(expectedValue)}
I'd call that rather ConditionalWriteCommand - AdvancedWC sounds too
general to me.
My 2c.
Radim
--
Radim Vansa rva
Hi,
Pedro suggested moving the following idea to separate thread (from the
'Improve WriteCommand processing code...'). Re:
I've been wondering for a while why the fetch part is a separate message
in the write flow. Is the return value of much use when it does not
return really the replaced
(www.infinispan.org)
Cheers,
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
be additional ones
anytime soon.
- Will
[1]
https://github.com/infinispan/infinispan/wiki/Handling-cluster-partitions
Cheers,
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev mailing list
infinispan
in this scenario.
Sanne
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev
/JGRP-1737
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
://infinispan.org
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev mailing
http://infinispan.org
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
On 11/12/2013 02:46 PM, Mircea Markus wrote:
On Nov 12, 2013, at 1:26 PM, Radim Vansa rva...@redhat.com wrote:
Mircea, besides mentioning of removed stuff, would it be possible to
compile some list of supported transactional modes and *expected
behaviour*? (using short code snippets: in one
pretty surprised that with default settings my
transaction was rolled back but the app code did not get any failure.
Radim
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
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 DataGrid QA
___
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
/listinfo/infinispan-dev
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
-dev
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
On 11/26/2013 04:10 PM, Galder Zamarreño wrote:
Hi Radim,
Thanks for the excellent feedback, comments below:
On Nov 13, 2013, at 11:33 AM, Radim Vansa rva...@redhat.com wrote:
Hi, my couple of questions remarks:
1. Why there is no RemoteCacheEntryCreated? I guess you had good reason
could be branched out to next
iterations.
Cheers,
--
Galder Zamarreño
gal...@redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
(not to delay the release) we can add them, otherwise just add them in future
iterations?
Cheers,
--
Galder Zamarreño
gal...@redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
Cheers,
--
Radim Vansa rva...@redhat.com
JBoss
to admit that I would eviscerate some
of your interfaces like these KeyFilters into more prominent packages so we
can all use the same interfaces. Also I would see if we can genericize some
of your interfaces and implementations.
Will keep you updated.
Vladimir
Cheers,
--
Radim Vansa rva
On 12/09/2013 05:33 PM, Radim Vansa wrote:
On 12/09/2013 04:21 PM, Vladimir Blagojevic wrote:
Radim, these are some very good ideas. And I think we should put them on
the roadmap.
Do you have any JIRA where this could be marked down?
Also, I like your ExecutorAllCompletionService, however, I
://issues.jboss.org/browse/ISPN-3800
On 12/9/2013, 3:09 AM, Radim Vansa wrote:
There is one thing I really don't like about the current implementation:
DefaultCollector. And any other collection that keeps one (or more)
object per entry.
We can't assume that if you double the number of objects in memory
suboptimal for writes, isn't it?
Cheers
Radim
PS: for every line of code you write in Scala, God kills a kitten
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org
, 2013 at 8:17 PM, Radim Vansa rva...@redhat.com
mailto:rva...@redhat.com wrote:
Hi Galder,
as I am trying to debug some problem in C++ client, I was looking into
the server code. And I am not sure whether I understand the code
correctly, but it seems to me that the server
On Wed, Dec 11, 2013 at 10:38 AM, Radim Vansa rva...@redhat.com
mailto:rva...@redhat.com wrote:
Hi Dan
I am not speaking about changing something for the C++ client, I
understand that the client code cannot be changed in order to keep
the backward compatibility.
Sure, I
On 12/13/2013 02:44 PM, Galder Zamarreño wrote:
On Dec 6, 2013, at 10:45 AM, Radim Vansa rva...@redhat.com wrote:
Hi,
1) IMO, filtering for specific key is a very important use case. Registering
a filterId is a very powerful feature, but as long as you don't provide
runtime parameter
that there
is more work required on the document). Also, situations related to such
changes (such as reliability guarantees in case of node crash/join)
should be specified.
Thanks
Radim
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev
On 12/13/2013 03:49 PM, Galder Zamarreño wrote:
On Dec 6, 2013, at 4:17 PM, Radim Vansa rva...@redhat.com wrote:
Btw., when Hot Rod fails to hit the primary owner, should the non-owner
propagate the SourceID to primary owner somehow? Or is in this case
acceptable notifying the listener
-radargun-perf-store-as-binary/1/artifact/report/All_report.html
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
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 DataGrid QA
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org
20 % writes, 80 % reads
Radim
On 01/29/2014 03:20 PM, Paul Ferraro wrote:
What was the read/write ratio used for this test?
On Fri, 2014-01-17 at 14:06 +0100, Radim Vansa wrote:
Hi Mircea,
I've ran a simple stress test [1] in dist mode with store as binary (not
enabled, enabled keys only
?
My guess is b) (without renaming) as the main idea should be that we can
store JPA objects into relational DB
Radim
[1] https://issues.jboss.org/browse/ISPN-3953
[2] https://issues.jboss.org/browse/ISPN-3954
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
On 01/30/2014 08:51 PM, Mircea Markus wrote:
On Jan 30, 2014, at 9:42 AM, Galder Zamarreño gal...@redhat.com wrote:
On Jan 21, 2014, at 11:52 PM, Mircea Markus mmar...@redhat.com wrote:
On Jan 15, 2014, at 1:42 PM, Emmanuel Bernard emman...@hibernate.org
wrote:
By the way, people looking
See below...
On Fri, Jan 31, 2014 at 7:35 AM, Radim Vansa rva...@redhat.com wrote:
Worth to note that Infinispan does not have true async operation -
executing synchronous request in another threadpool is rather simplistic
solution that has serious drawbacks (I can imagine a situation where
transport neither, it's about async executors.
(okay, the thread was about dropping async transport, I have hijacked it)
Radim
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https
for different caches,
can we avoid the need to store the cache name in each document?
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
don’t see how we can avoid intermediate storage altogether.
Thanks,
Etienne (leads project — as Evangelos who initiated the thread)
On 17 Feb 2014, at 08:48, Radim Vansa rva...@redhat.com wrote:
I think that the intermediate cache is not required at all. The M/R
algorithm itself can
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https
of expressions, property
replacement executed on slaves
I hope you will like it! And enjoy 1.1.0.Final release now.
Radim
--
Radim Vansa rva...@redhat.com JBoss DataGrid QA
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa rva...@redhat.com
JBoss DataGrid QA
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https
1 - 100 of 361 matches
Mail list logo
