Configuration visitor - Re: [JBoss JIRA] Commented: (ISPN-145) No transport and singleton store enabled should not be allowed
by Vladimir Blagojevic
Hi,
Galder and I talked about this offline. Time to involve you guys!
I just completed visitor pattern for our configuration objects. Visitor
is passed from root of configuration - InfinispanConfiguration object.
InfinispanConfiguration class has a new method:
public void accept(ConfigurationBeanVisitor v)
How do we want to integrate this visitor into existing structure?
1) We add a new factory method to InfinispanConfiguration with
additional ConfigurationBeanVisitor parameter
2) We leave everything as is and if there is a need to pass some visitor
we pass it to InfinispanConfiguration instance directly (from
DefaultCacheManager)
DefaultCacheManager will pass ValidationVisitor to
InfinispanConfiguration that will verify configuration semantically.
Regards,
Vladimir
On 09-09-09 10:19 AM, Galder Zamarreno wrote:
> Good idea :)
>
> On 09/09/2009 04:13 PM, Vladimir Blagojevic wrote:
>> Yeah,
>>
>> I was thinking that we can make a visitor for configuration tree and
>> then you can do verification of any node and other things as well. Use
>> cases will come up in the future for sure.
>>
>> Cheers
>>
>>
>>
>> On 09-09-09 3:29 AM, Galder Zamarreno (JIRA) wrote:
>>> [
>>> https://jira.jboss.org/jira/browse/ISPN-145?page=com.atlassian.jira.plugi...
>>>
>>> ]
>>>
>>> Galder Zamarreno commented on ISPN-145:
>>> ---------------------------------------
>>>
>>> Not sure I understand what you mean by generic though. You mean any
>>> component to have a validation step of some sort?
>>>
>>> Thanks for taking this on :)
>>>
>>>> No transport and singleton store enabled should not be allowed
>>>> --------------------------------------------------------------
>>>>
>>>> Key: ISPN-145
>>>> URL: https://jira.jboss.org/jira/browse/ISPN-145
>>>> Project: Infinispan
>>>> Issue Type: Bug
>>>> Components: Loaders and Stores
>>>> Affects Versions: 4.0.0.ALPHA6
>>>> Reporter: Galder Zamarreno
>>>> Assignee: Vladimir Blagojevic
>>>> Priority: Minor
>>>> Fix For: 4.0.0.CR1
>>>>
>>>>
>>>> Throw configuration exception if singleton store configured without
>>>> transport having been configured.
>>>> It makes no sense to have singleton store enabled when there's no
>>>> transport.
>>
>
13 years, 2 months
Using Coverity scan?
by Sanne Grinovero
Hello,
Did you consider enabling Infinispan to be monitored by coverity's
code analysis services? They are free for OSS projects, I saw a demo
recently and was quite amazed. It's similar to FindBugs, but not only
about static code checks. They checkout your code from trunk and then
run several analysis on it periodically, one of them is about dynamic
thread behavior to predict deadlocks or missing fences instrumenting
the code, and produce nice public reports; AFAIK you don't need to
setup anything yourself, besides getting in touch to ask for it.
It's only available for C and Java code, and they have an impressive
list of OSS projects in the C world (linux kernel, httpd server,
samba, gnome, GCC, PostgreSQL, ...) but not much on Java.
http://scan.coverity.com/
No, I'm not affiliated :-) Just thinking that it might be useful to
have if it's not too hard to setup.
Cheers,
Sanne
14 years
Hot Rod - pt3
by Galder Zamarreno
Hi all,
Re: http://community.jboss.org/wiki/HotRodProtocol
First, I've made the corresponding changes based on the feedback I got
from pt2. This included reducing the response header since clients are
already aware of what they sent, addition of topology view id to to non
dumb requests and further specification in responses when topology
changes have happened...etc.
I've also added flags to the request header that allow sending
Infinispan flags like: skip cache store, zero lock acquisition
timeout...etc.
Note that I've noted this as being N * 1 byte where each byte represents
a flag. However, I think this could maybe be sent more efficiently by
using XOR, i.e.
0x00 -> no flag
0x01 (0000 0001) -> zero lock acquisition
0x02 (0000 0010) -> cache mode local
0x03 (0000 0011) -> zero lock acquisition + cache mode local
0x04 (0000 0100) -> skip locking
...etc.
With 2 bytes, we could implement 16 Flags, we currently 11. However, we
could use vint as well, making sure that the most significant bit does
not mean anything flag wise. Iow, with vint, in 1 byte we'd be able to
define 7 diff flags. Thoughts?
I've also added the quit command that disconnects clients.
Finally, as far as I'm concerned, the specification is complete. I'm
leaving the quiet commands out of this initial scope (see
http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol).
Remember that quiet commands could be used so that the server buffers
responses and only when you send a non-quiet command, the server replies
with all the pending answers.
As you can see at the bottom of the wiki, I've added a local only put
request/response example so that readers get an idea of what a full
command looks like. I had received some feedback from readers saying
that it was difficult to understand how it all fit together.
I'll probably add a couple more examples for non-so-dumb and clever
request/responses but I'll held them until we have a final round of
feedback and people can indicate whether they want any other examples
appearing in the wiki.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 10 months
Creating cache managers in your unit tests
by Manik Surtani
Guys,
as far as possible, please extend either SingleCacheManagerTest [1] or MultipleCacheManagersTest [2]. and use the corresponding helper methods there to create a new CacheManager. Alternatively, if you have a unit test that needs to create its own CacheManager directly, please use TestCacheManagerFactory [3]. Do *not* use "new DefaultCacheManager()" directly since this means the framework does not have a chance to alter config settings to work within the framework, including clustering settings to make sure the test does not interfere with other tests, threadpool settings to prevent unnecessary OOMs when running the entire suite with thousands of cache managers, etc.
I have just fixed a bunch of offending tests [4], and updated the wiki page [5] on writing tests accordingly. Please follow these guidelines.
Cheers & Happy X'mas!
Manik
[1] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/test/java/org/i...
[2] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/test/java/org/i...
[3] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/test/java/org/i...
[4] http://fisheye.jboss.org/changelog/Infinispan/trunk?cs=1327
[5] http://community.jboss.org/wiki/ParallelTestSuite
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
14 years, 11 months
Hot Rod - pt2
by Galder Zamarreno
Hi all,
Re: http://community.jboss.org/wiki/HotRodProtocol
I've updated the wiki with the following stuff:
- Renamed replaceIfEquals to replaceIfUnmodified
- Added remove and removeIfUnmodified.
- Added containsKey command.
- Added getWithCas command so that cas value can be returned. I decided
for a separate command rather than adding cas to get return because you
don't always want cas to be returned. Having a separate command makes
better use of network bandwith.
- Added stats command. JMX attributes are basically accessible through
this, including cache size.
- Added error handling section and updated status codes.
Note that Mircea added some interesting comments and I replied to them
directly in the wiki.
Still remaining to add:
- Commands: putForExternalRead evict, clear, version, name and quite
commands.
- Passing flags.
Regards,
p.s. Updating this has been quite a struggle due to F12 + FF 3.5.5
crashing at least 5 times, plus parts of the wiki dissapearing after
publishing them!
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 11 months
[patch] Unit test to highlight potential performance and cache eviction issues in distributed mode
by Juha Heljoranta
Hi,
I've had some problems with Infinispan and decided to write some unit test to
understand what might possibly go wrong.
First of all, I do admit that I try to use an individual Infinispan cache
instance as a grid client which might explain at least some of the issues.
However, I'd really like to understand why these issues are taking place.
I'd be happy to improve the patch if needed.
Regards,
Juha Heljoranta
15 years
problems with AS 5.1 and infinispan REST server
by Michael Neale
Thanks to Noel O'Connor, it seems (to be confirmed) this is to to the
marshalling (?) jar having a jboss-classloading.xml in its META-INF -
AS 5.1 took that and completely broke its classloading so much that it
couldn't even find HttpServlet (!).
So, if this is the case:
1) why is that file in the marshalling jar? (doesn't need to be there)
2) I need to raise a bug against 5.1 as this shouldn't happen (and
didn't in 4.x etc) ?
Anyone know better?
FYI seems ok in JBossWeb - in fact for an infinispan server node
(RESTful or otherwise), it would most likely want to use as much
resources as were available to it - so a whole app server is probably
overkill - so thinking that we could package it up (optionally) inside
jboss web type of thing (which starts up fast and easy and has all the
bits needed).
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
15 years
jprofile in offline mode
by Mircea Markus
Hi,
Anyone managed to record CPU data with jprofile in offline mode? I just can't get that info when running offline, so any clues would be very welcomed.
Thanks,
Mircea
15 years
using dependencyManagement in pom.xml
by Sanne Grinovero
Hi all,
some days ago I mentioned in IRC that some modules were using
inconsistent versions if dependencies,
I had then proposed to move some version properties from core to
parent pom, but these properties are not visible in child poms,
so went for another road.
The usual way to implement this in Maven is to use
<dependencyManagement> and define there the versions which have to be
pinned down
globally; This affects some poms. I'm not moving all versions to
parent, as many modules are depending on stuff
not relevant to other modules, but moved most common dependencies to
dependencyManagement tag in root pom.
Should I apply this, or anybody see problems? I don't know if there
was a specific reason to not use dependencyManagement.
patch is attached so you can see what I'm referring to.
Cheers,
Sanne
15 years
