Issue with cache blocks for local read-only cache
by "Ståle W. Pedersen"
hi galder and manik, sorry for sending this mail to so many, but we've
ran into a issue that prevents us from further scaling of the
specjenterprise2010 benchmark.
so when doing specjenterprise2010 benchmark testing we've seen a lot of
blocks caused by the entity/query cache. we've been testing with only
caching a simple entity bean that's read-only and queries related to
this entity (selects).
here is a screenshot of the hotspot found:
https://dl.dropbox.com/u/30971563/specjent_block.png
here is the standalone.xml:
https://dl.dropbox.com/u/30971563/standalone-full.xml
here is the orm.xml: https://dl.dropbox.com/u/30971563/order_orm.xml
what we don't understand is why there are so many puts into the cache
for an object that is marked as read-only. when we're testing without
caching we do not see any blocks.
any help/ideas would be great. if anyone want a jprofiler snapshot of
the run, let me know.
regards, ståle
--
JBoss Performance Team Lead
JBoss by Red Hat
13 years
Unnecessary files in distribution zip file
by Manik Surtani
Guys
I just noticed a few unnecessary files being packaged in the zip file:
* in /etc, the *metadata.dat are unnecessary as they are packaged in the relevant jars
* what's with the hornetq files in /etc?!?
* what is /etc/help ?
* shouldn't the schemas in /etc/org/infinispan/spring/config be in /etc/schema ?
* /etc/hbase-cachestore-ispn.xml should be in /etc/config-samples - and possibly renamed to just hbase-cachestore.xml for consistency
* Why is infinispan-core.jar in the root as well as in /lib?
* Some module jars are repeated in /lib as well
- M
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
13 years
5.2.Alpha4 posponed to 19 Sept
by Mircea Markus
Hi,
I need some time to implement the suggestions from Bela, Erik and Galder(thanks!) re: xsite replication, so the release will be postponed to 19 Sept.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
13 years
Versioned Transactional Cache issues
by Pedro Ruivo
Hi all,
While I was working in Infinispan, I have found some issues with the
versioned transactional cache. I have created some tests cases (can be
found here [1]) to reproduce the issues and also I have fixed one of
them. The issues are the following:
1) testPutIfAbsent, testRemoveIfPresent, testReplaceWithOldVal (methods
the test cases)
In this tests, it was updating the cache entry with a null version. This
originates later a IllegalStateException when it tries to perform the
write skew check and the version is null.
I have fixed this problem in this way: if the command fails (PutCommand,
RemoveCommand, ReplaceCommand), I unset the flag CHANGED in the
MvccEntry to avoid to update the entry in the DataContainer.
2) testClear in distributed mode
I have no clear idea how to solve this problem but it looks like the
PrepareCommand (with the ClearCommand) is not sent to all the nodes in
the cluster. Then, when I do a get, a remote get is performed and the
key is still there. I think that it is not the desired behavior.
3) testRemoveUnexistingEntry
In this test, it tries to remove a key that does not exists but it does
not success due to a NullPointerException. I have looked deeper and I
check that the transaction's lookup entries map has an entry with [key
=> null] and when it tries to perform the write skew check in that key,
a NullPointerException is thrown in here [2] (line 80, WriteSkewHelper)
Should I open a JIRA with this 3 issues (or 3 JIRAs, one for each issue)?
If you want, I can issue a pull request too.
Cheers,
Pedro Ruivo
[1] https://github.com/pruivo/infinispan/tree/t_replace_fix
[2]
https://github.com/pruivo/infinispan/blob/t_replace_fix/core/src/main/jav...
13 years
Fast writes on one node with pessimistic locking
by Radim Vansa
Hi,
when I was looking on results of some tests targeted at explicit locking I've found strange non-uniformity in write (put) speed with pessimistic locking: One member of the cluster has always almost twice as many requests per second compared to the others. Is there some central point on one 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
13 years
Ideas for Hot Rod protocol improvements to support new hashing routing table
by Galder Zamarreño
Hey Dan,
Re: https://issues.jboss.org/browse/ISPN-2205
Sorry we couldn't have a proper chat but we can carry on via email. Extending to Infinispan Dev.
| > [11:03] <dberindei> this is what I had in mind for the hotrod update: https://gist.github.com/3664504
What is "1st owner's index"? Is that the position in the array of servers in topology above? I guess os, if so, I think https://gist.github.com/3664504 looks fine.
That's assuming the clients provide the normalized hash for the key (which they already do today), they should have all the info to locate in.
Do we still need hash space? I think we can assume this is fixed now to be all positive integers.
| > [11:04] <dberindei> but thinking about it some more, I think it might be a good idea to talk about having a CH per cache on the client as well
Supporting a CH per cache would not require any changes to the protocol, since all operations are per-cache, it would just need the client to cache the info accordingly.
| > [11:07] <dberindei> something else that came to mind: we allow the server to specify a hash function version, but the serialization of the CH is fixed based only on the client's version
| > [11:08] <dberindei> maybe we could specify in the protocol a different serialization for each function version?
| > [11:09] <dberindei> that way we could have a single client that can support any server CH via a very generic client CH like the new DCH
| > [11:10] <dberindei> and at the same time, if the server knows that the client supports a fancier CH, it can send the other CH instead
The Hash Function is there to define what 'hash function' the client uses. Whether that's MurmurHash3, MurmurHash2…etc. The serialization, or how we transmit the rest of hashing information should really be part of the protocol itself. I don't think we should change this.
Cheers,
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
13 years
EntityLoader as interface?
by Ales Justin
While thinking about EntityLoader as interface (imo, it should be an interface ...),
just stumbled upon this:
public List<Object> load(EntityInfo... entityInfos) {
int size = entityInfos.length;
ArrayList<Object> list = new ArrayList<Object>(size);
for (EntityInfo e : entityInfos) {
Object entity = load(e);
if (entity != null) {
list.add(entity);
}
}
return list;
}
We pass "size" into ArrayList.
What if some "entity" is the null, hence not added, will the "list" size still be ok?
I would say you need to call "trimToSize"?
@Sanne: how would we get just key to be used / loaded, not full entity;
e.g GAE has Query::setKeysOnly
... you mentioned some projections
-Ales
13 years
Fwd: PHP hotrod client (C library)
by Galder Zamarreño
Forgot to add the dev list in my reply…
@Manik, FYI
Begin forwarded message:
> From: Galder Zamarreño <galder(a)redhat.com>
> Subject: Re: PHP hotrod client (C library)
> Date: September 6, 2012 11:27:56 AM GMT+02:00
> To: Jared Sprague <jsprague(a)redhat.com>
> Cc: Travis McTighe <tmctighe(a)redhat.com>, Radoslav Husar <rhusar(a)redhat.com>, Chris Bredesen <cbredesen(a)redhat.com>
>
> Extending it to the dev list…
>
> The JIRA is: https://issues.jboss.org/browse/ISPN-470
>
> On Sep 5, 2012, at 3:57 PM, Jared Sprague wrote:
>
>> Hello Galder & Rado,
>> What we would like to do is write a Hotrod client PHP extension in C that could eventually be made part of PECL.
>>
>> So here are a few questions:
>> Rado, is the project that Galder mentioned similar?
>
> @Rado?
>
>> What is the current state of the project?
>
> No idea, I see no updates on https://issues.jboss.org/browse/ISPN-470
>
>> What are the benefits to using the Hotrod protocol vs. connecting to Infinispan in Memcache mode?
>
> https://docs.jboss.org/author/x/2AU5
>
>> How can we get involved?
>
> See what Rado's guy has done first and then we can see what needs doing.
>
>>
>> Any information you can provide would be much appreciated.
>>
>> Thank you!
>> - Jared Sprague
>> x44558
>>
>> ----- Original Message -----
>> From: "Galder Zamarreño" <galder(a)redhat.com>
>> To: "Chris Bredesen" <cbredesen(a)redhat.com>
>> Cc: "Jared Sprague" <jsprague(a)redhat.com>, "Travis McTighe" <tmctighe(a)redhat.com>, "Radoslav Husar" <rhusar(a)redhat.com>
>> Sent: Monday, September 3, 2012 12:19:38 PM
>> Subject: Re: PHP hotrod client (C library)
>>
>> Hey Chris,
>>
>> Yeah, all doing well here. Happy with F1 indeed though I'm yet to watch yesterday's Spa race (don't tell me what happened...)
>>
>> On Aug 30, 2012, at 5:51 PM, Chris Bredesen wrote:
>>
>>> Hey Galder!
>>>
>>> Hope all is well and you are pleased with the F1 results so far this season ;)
>>>
>>> Jared Sprague works for me on our Drupal kbase/groups webapp and is interested in contributing a Drupal cache connector for Infinispan. We can do this today using memcache mode but we are also keen to write a native C client that can be used as a PHP extension.
>>>
>>> Any idea if there is any C work out there today? I see the JRuby and C# projects, not sure of their status. Where would you recommend Jared start on something like this? Are you still maintaining the hotrod stuff in ISPN? It's not guaranteed that we'll do this right away but I mainly just wanted to get you two in touch so that you have some idea what might be coming.
>>
>> As far as I know, there's a student that's working on the C client that Rado (on cc) is mentoring or keeping an eye on him.
>>
>> Rado should be able to give us more info on where things stand.
>>
>> Cheers,
>>
>>>
>>> Jared-Galder; Galder-Jared ... happy hacking!
>>>
>>> -CB
>>>
>>> --
>>> Chris Bredesen
>>> Supervisor, Software Engineering
>>> Red Hat Global Support Services
>>
>>
>> --
>> Galder Zamarreño
>> galder(a)redhat.com
>> twitter.com/galderz
>>
>> Project Lead, Escalante
>> http://escalante.io
>>
>> Engineer, Infinispan
>> http://infinispan.org
>>
>
>
> --
> Galder Zamarreño
> galder(a)redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
13 years
