Making sure JBC bugs get fixed in ISPN too WAS Re: You pinged me?
by Galder Zamarreno
cc'ing ISPN dev
Takayoshi Kimura wrote:
> Hi Galder,
>
> I wanted to know how we fix ISPN bugs originally found in
> JBCACHE project. I've created separate JIRA issue on ISPN
> project, is this preferred way?
I believe it is. I saw the bug you entered and linked the ISPN one with
the JBC one.
> My concern is some bugs
> could fall thru the cracks because issue reporters might
> open tickets in only JBCACHE and not in ISPN.
That's certainly a valid concern, we need to keep an eye on the JBC bugs
and verify whether they're relevant for ISPN or not.
>
> Takayoshi
>
> At Tue, 23 Jun 2009 11:40:18 +0200,
> Galder Zamarreno <galder.zamarreno(a)redhat.com> wrote:
>> Hey,
>>
>> You pinged me earlier but I was away in French lessons.
>>
>> What's up?
>>
>> Cheers,
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
17 years
Document all configuration options available in XML
by Vladimir Blagojevic
Hi,
I finished up https://jira.jboss.org/jira/browse/ISPN-89 today. I
decorated only a few bean configuration classes. I want to get a nod
from Manik first before proceeding further on this front. I also
committed a ConfigDoclet in tools project. ConfigDoclet is supposed to
create configuration documentation in html. However, I could not figure
out how to include ConfigDoclet invocation into maven. ConfigDoclet
requires -classpath flag to include all jars from dependent projects. If
you are maven proficient and have a lot of hair please be my guest :)
For testing purposes I was invoking ConfigDoclet as a simple java class
with main method. We can invoke this doclet as a simple java program. No
need for this doclet nonsense.
Regards,
Vladimir
17 years
ManagedAttributes in DefautlCacheManager
by Heiko W.Rupp
Hi,
why are those strings?
@ManagedAttribute(description = "number of running caches")
public String getCreatedCacheCount() {
return String.valueOf(this.caches.keySet().size());
}
@ManagedAttribute(description = "the total number of defined caches")
public String getDefinedCacheCount() {
return String.valueOf(this.configurationOverrides.keySet().size());
}
I think something numerical would be better - can I change that?
Heiko
-- Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei
München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham,
Charles Cachera
17 years
JOPR plugin - display names
by Manik Surtani
Heiko,
Your JOPR plugin has an RHQ xml file that maps managed attributes to
"friendly names". Can this be generated? Each managed attribute/
operation is annotated using a @ManagedAttribute/@ManagedOperation
annotation, which has a "description". This is the description that
should be used in any GUI console.
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
17 years
wiki on config import tools
by Mircea Markus
Hi,
I've added this document describing talking about existing migration tools.
Here it is: http://www.jboss.org/community/wiki/ConfigurationImportTools
Any feedback is welcomed!
I will also add a blog entry soon.
I cannot link it from here, though, as I don't seem to have the rights
:( :http://www.jboss.org/community/wiki/Infinispan . Manik, can you
please assist me on this one?
Cheers,
Mircea
17 years
Parsing configuration XML files
by Vladimir Blagojevic
Just a quick update that I am making a good progress with
https://jira.jboss.org/jira/browse/ISPN-96
I am trying to handle all the cases with the most generic algorithms I
can come up with. Should be a very compact and elegant solution. If this
goes through then I would definitely proceed to decorate all ours beans
with configuration elements we talked about!
17 years
Re: [infinispan-dev] [ISPN-116] Async cache store: aggregation of multiple changes on a single key
by Galder Zamarreno
On 07/04/2009 08:12 AM, Amin Abbaspour wrote:
> Hi,
>
> It would be great if both of these are present and developer decides
> which one to use. In many cases, the custom logic of the application
> can perform better then a general purpose data structure to aggregate
> changes to a single value.
Please try to keep the infinispan developer list cc'd so that we can
discuss the different options among every one.
Hmmm, on one side, I'm not sure of the need of implementing the two
methods. I think we need simply one that performs best.
Also, I'm not sure I understand the need for the application to apply
any logic here. The application has likely made several put operations
on a key and so the most likely outcome is the latter one should be
applied, unless there has been some kind of cluster partition but this
is a separate concern.
> If every change and its coalition process is running inside a
> transactional block, then this custom logic is quite feasible and
> safe.
Again, this seems to be separate concern that addresses how to deal with
merging of cache state when there has been some kind of network
partition. This won't be resolved at the cache loader level though.
>
> IMHO both 1st and 2nd options require similar changes to code in
> persistence mechanism, I think we'd better implement simple 2nd option
> first and then switch to enhanced version with 1st option.
>
> Regards
> Amin
>
> On 6/30/09, Galder Zamarreno<galder.zamarreno(a)redhat.com> wrote:
>> Hi,
>>
>> Re: https://jira.jboss.org/jira/browse/ISPN-116
>>
>> I can see two ways of providing such feature:
>>
>> 1. Rather than using a queue, using a data structure similar to the one
>> used in the data container so that when a newer value for a key already
>> present in the queue is present, the value can be swapped (map like
>> lookup required on the key so that O(1) is maintained) while maintaining
>> queue-like FIFO operations required to empty it.
>>
>> 2. Based on suggestion coming amin59 in
>> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240980#4240980,
>> make
>> the current queue only store keys and make the draining process query
>> the cache for the latest value. Because from the time the data was put
>> to the cache to the time it's stored, the data could have expired or had
>> been removed all together, such query would need to make sure it doesn't
>> go to the cache loader again. Also, if the data had been removed, how
>> would the Async store know that from cache.get()? The queue would need
>> to record somehow that a key was actually removed.
>>
>> The benefit of the 1st option is that we can take advantage of fast
>> drainTo() like operations when draining it, and also the fact that no
>> contention is added to the cache itself. The downside would be the need
>> for a more complex data structure.
>>
>> The benefit of the 2nd option is the keeping a simple queue, less
>> complex data structure, but requires that each time a key is to be
>> drained, we have to query the cache. This could slow down the draining
>> process.
>>
>> My preference is with 1. but for to use it, I'd need the data container
>> collection to be made more generic.
>>
>> Thoughts?
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
17 years
