Good idea. I'll do that.
On Jan 18, 2012, at 6:40 AM, Manik Surtani wrote:
Although I'd scan for the list of methods to be removed and advertise them on
this thread first. Just in case.
On 18 Jan 2012, at 06:40, Manik Surtani wrote:
Yes, +1.
On 17 Jan 2012, at 12:51, Galder
Hello,
I just got these figures using the Transactional test:
Done 2,592,102,434 transactional operations in 62.18 minutes using
5.1.0-SNAPSHOT
2,576,372,975 reads and 15,729,459 writes
Reads / second: 690,573
Writes/ second: 4,216
which are much better than what I had 24 hours ago with
Great !
Which version of JGroups did you use ? 3.0.2 or 3.0.3 ?
On 1/19/12 10:25 AM, Sanne Grinovero wrote:
Hello,
I just got these figures using the Transactional test:
Done 2,592,102,434 transactional operations in 62.18 minutes using
5.1.0-SNAPSHOT
2,576,372,975 reads and 15,729,459
On 19 January 2012 09:36, Bela Ban b...@redhat.com wrote:
Great !
Which version of JGroups did you use ? 3.0.2 or 3.0.3 ?
Right... sorry I forgot to revert experiments on JGroups!
So both numbers where running JGroups version 8115f27, which is
somewhere between the two:
8115f27 Made
On 19 January 2012 09:59, Bela Ban b...@redhat.com wrote:
It would be interesting to see the numbers with bbc128, which makes
sending a bit faster. I'd expect to see more writes and less reads,
compared to their relative numbers.
Ok, done. This is the same Infinispan build, but using JGroups
Haha! Why do you always refer to it as peculiar? :) Is it really that odd?
On 18 Jan 2012, at 21:56, Galder Zamarreño wrote:
Good points. I've just updated the article. Have a look.
On Jan 18, 2012, at 6:45 AM, Manik Surtani wrote:
Good start.
I'd also explain why fail-fast is
On 1/19/12 11:45 AM, Sanne Grinovero wrote:
On 19 January 2012 09:59, Bela Banb...@redhat.com wrote:
It would be interesting to see the numbers with bbc128, which makes
sending a bit faster. I'd expect to see more writes and less reads,
compared to their relative numbers.
Ok, done. This
Agreed. But lets do this scientifically. Sanne, have you got a list of the
Collections used and where, in order of their impact on overall performance?
On 19 Jan 2012, at 12:47, Bela Ban wrote:
This makes a lot of sense IMO, as I've done similar things in JGroups
(e.g. my own optimized
What is this for? Perhaps just mock up the client to use a mock socket?
On 19 Jan 2012, at 12:57, Bela Ban wrote:
If this is done in Java code, you could use byteman to change the behavior.
Intercepting and changing the data flow in the TCP/IP stack itself gets
more tricky; you have to
All looking very good, people. Bela, feel like putting Table into NAKACK and
3.0.3? ;)
On 19 Jan 2012, at 16:29, Bela Ban wrote:
On 1/19/12 11:45 AM, Sanne Grinovero wrote:
On 19 January 2012 09:59, Bela Banb...@redhat.com wrote:
It would be interesting to see the numbers with bbc128,
On 1/19/12 12:03 PM, Manik Surtani wrote:
All looking very good, people. Bela, feel like putting Table into NAKACK and
3.0.3? ;)
Definitely not in NAKACK, it will be in NAKACK2 in 3.1. Once this has
been running in production for a year or so, we can rename it to NAKACK.
Remember,
On 19 January 2012 10:59, Manik Surtani ma...@jboss.org wrote:
Agreed. But lets do this scientifically. Sanne, have you got a list of the
Collections used and where, in order of their impact on overall performance?
A list of changes is in the patch [1]: every changed line matches an
affected
Guys
We've had these two tests fail quite consistently for a while now:
https://infinispan.ci.cloudbees.com/job/Infinispan-master-JDK6-tcp/org.infinispan$infinispan-spring/480/testReport/
Anyone care to take a look? It is related to configuring Infinispan via Spring
and I suspect the failure
On 19 January 2012 11:48, Manik Surtani ma...@jboss.org wrote:
Yes, I understand your reasons for not wanting to push this patch in now. I
agree that this isn't the time for such large-scale, if simple, refactoring.
I was suggesting more for 5.2.0.
Ok, that would be nice. Hopefully I won't
LOL, ignoring failures is not something you do often. Feel free to reword it :)
On Jan 19, 2012, at 10:56 AM, Manik Surtani wrote:
Haha! Why do you always refer to it as peculiar? :) Is it really that
odd?
On 18 Jan 2012, at 21:56, Galder Zamarreño wrote:
Good points. I've just
I wanted to test my theory that the hot rod client connection timeout we
added as part of
https://issues.jboss.org/browse/ISPN-1565
is being ignored
(taking into account https://issues.jboss.org/browse/ISPN-1755)
I configured both socket timeout and connect timeout for 2 min but in
certain tests
This may not give you any performance increase:
#1 In my experience, serialization is way faster than de-serialization.
Unless you're doing something fancy in your serializer
#2 Assuming that the serialization thread pool has a bounded queue/size,
by pushing the serialization further down the
On 19 Jan 2012, at 16:35, Galder Zamarreño wrote:
On Jan 19, 2012, at 4:24 PM, Pete Muir wrote:
On 19 Jan 2012, at 16:14, Galder Zamarreño wrote:
Hi all,
Re: https://issues.jboss.org/browse/ISPN-1745
The following deprecated methods belonging to the new configuration are
going
On Jan 19, 2012, at 4:37 PM, Pete Muir wrote:
On 19 Jan 2012, at 16:35, Galder Zamarreño wrote:
On Jan 19, 2012, at 4:24 PM, Pete Muir wrote:
On 19 Jan 2012, at 16:14, Galder Zamarreño wrote:
Hi all,
Re: https://issues.jboss.org/browse/ISPN-1745
The following deprecated
On Jan 19, 2012, at 3:43 PM, Bela Ban wrote:
This may not give you any performance increase:
#1 In my experience, serialization is way faster than de-serialization.
Unless you're doing something fancy in your serializer
No. I think Mircea didn't explain this very well. What really
On 19 Jan 2012, at 17:36, Galder Zamarreño wrote:
On Jan 19, 2012, at 3:43 PM, Bela Ban wrote:
This may not give you any performance increase:
#1 In my experience, serialization is way faster than de-serialization.
Unless you're doing something fancy in your serializer
No. I
I just noticed that org.infinispan.transaction.LocalTransaction is
keeping track of Addresses on which locks where acquired.
That's surprising me .. why should it ever be interested in the
specific Address? I'd expect it to be able to figure that out when
needed, especially since the Address
On 1/19/12 6:36 PM, Galder Zamarreño wrote:
On Jan 19, 2012, at 3:43 PM, Bela Ban wrote:
This may not give you any performance increase:
#1 In my experience, serialization is way faster than de-serialization.
Unless you're doing something fancy in your serializer
No. I think Mircea
On 20 Jan 2012, at 01:12, Bela Ban wrote:
On 1/19/12 6:36 PM, Galder Zamarreño wrote:
On Jan 19, 2012, at 3:43 PM, Bela Ban wrote:
This may not give you any performance increase:
#1 In my experience, serialization is way faster than de-serialization.
Unless you're doing
On 19 Jan 2012, at 19:42, Bela Ban wrote:
On 1/19/12 6:36 PM, Galder Zamarreño wrote:
On Jan 19, 2012, at 3:43 PM, Bela Ban wrote:
This may not give you any performance increase:
#1 In my experience, serialization is way faster than de-serialization.
Unless you're doing something
On Thu, Jan 19, 2012 at 7:46 PM, Mircea Markus mircea.mar...@jboss.com wrote:
On 19 Jan 2012, at 17:36, Galder Zamarreño wrote:
On Jan 19, 2012, at 3:43 PM, Bela Ban wrote:
This may not give you any performance increase:
#1 In my experience, serialization is way faster than
Are you sure about this Mircea? AFAIK the message is always sent by
JGroups from our thread (either the user thread or the async transport
thread). The only difference between sync (GET_ALL) and async calls
(GET_NONE) at the JGroups level is that with GET_NONE that thread
doesn't wait for the
Hi,
I just noticed this warning in my build logs; I don't read them often
so it might have been there for a while:
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @
infinispan-spring ---
[INFO] Compiling 22 source files to
Well, a view change may not mean that the nodes prepared on have changed. But
still, there would almost certainly be a better way to do this than a
collection of addresses. So the goal is to determine whether the set of nodes
the prepare has been sent to and the current set of affected nodes
I have no idea, I've never seen this before. Does it stop the build?
On 20 Jan 2012, at 04:55, Sanne Grinovero wrote:
Hi,
I just noticed this warning in my build logs; I don't read them often
so it might have been there for a while:
[INFO] --- maven-compiler-plugin:2.3.2:compile
30 matches
Mail list logo
