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.
>>
>
14 years
Adaptive marshaller buffer sizes - ISPN-1102
by Galder Zamarreño
Hi all,
Re: https://issues.jboss.org/browse/ISPN-1102
First of all thanks to Dan for his suggestion on reservoir sampling+percentiles, very good suggestion:). So, I'm looking into this and Trustin's http://docs.jboss.org/netty/3.2/api/org/jboss/netty/channel/AdaptiveRecei... but in this email I wanted to discuss the reservoir sampling mechanism (http://en.wikipedia.org/wiki/Reservoir_sampling).
So, the way I look at it, to implement this you'd keep track of N buffer sizes used so far, and out of those chose K samples based on reservoir sampling, and then of those K samples left, take the 90th percentile.
Calculating the percentile is easy with those K samples stored in an ordered collection. Now, my problem with this is that reservoir sampling is an O(n) operation and you would not want to be doing that per each request for a buffer that comes in.
One option I can think of that instead of ever letting a user thread calculate this, the user thread could just feed the buffer size collection (a concurrent collection) and we could have a thread in the background that periodically or based on some threshold calculates the reservoir sample + percentile and this is what's used as next buffer size. My biggest problem here is the concurrent collection in the middle. You could have a priority queue ordered by buffer sizes but it's unbounded. The concurrent collection does not require to be ordered though, the reservoir sampling could do that, but you want it the collection bounded. But if bounded and the limit is hit, you would not want it to block but instead override values remove the last element and insert again. You only care about the last N relevant buffer sizes...
Another option that would avoid the use of a concurrent collection would be if this was calculated per thread and stored in a thread local. The calculation could be done every X requests still in the client thread, or could be sent to a separate thread wrapping it around a callable and keeping the future as thread local, you could query it next time the thread wants to marshall something.
I feel a bit more inclined towards the latter option although it limits the calculation to be per-thread for several reasons:
- We already have org.jboss.marshalling.Marshaller and org.jboss.marshalling.Unmarshaller instances as thread local which have proven to perform well.
- So we could tap into this set up to maintain not only the marshaller, but the size of the buffer too.
- It could offer the possibility of being extended further to avoid creating buffers all the time and instead reuse them as long as the size is constant. After a size recalculation we'd ditch it and create a new one.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 3 months
Infinispan Shell Console
by Michal Linhard
Hi all!
Announcing my little project Infinispan Console:
https://github.com/mlinhard/ispncon
I wanted to wait with publishing of this until I do some more testing,
but I don't know when I'll get to that, and it already helps me with
some testing and I thought that it might be useful to some of you too,
so I don't wanna keep it to myself any longer...
it basically enables you to do stuff like
ispncon put key value
ispncon get key
from your bash, using client access (hotrod, memcached, rest) - I.e. you
have to have these server modules running/deployed in a container.
feedback is appreciated.
m.
--
Michal Linhard
Quality Assurance Engineer
Red Hat Czech s.r.o.
Purkynova 99 612 45 Brno, Czech Republic
phone: +420 532 294 320 ext. 62320
mobile: +420 728 626 363
14 years, 3 months
Ideas for locking improvements
by Sanne Grinovero
Hello all,
as some of us met recently at events, we've been discussing some
details about the current locking implementations and possible
improvements.
Some interesting ideas came out and we've been writing them down on
the wiki so that everyone can be involved:
http://community.jboss.org/wiki/PossibleLockingImprovements
as always, more feedback, comments and more suggestions are welcome.
Please bear with us if something is not very clear as they are drafts
of unimplemented ideas, so if you see something that you like to know
more about please start a discussion or comment about it and we'll try
to polish the explanation, refining the ideas.
Cheers,
Sanne
14 years, 4 months
Defining new commands in modules
by Manik Surtani
So this is an extension to the discussion around a GenericCommand that has been going around. IMO a GenericCommand is a big -1 from me for various reasons - the whole purpose of the command pattern is so we have strongly typed and unit testable commands. This will help the ongoing work by Mircea, Sanne and Israel on various modules that need to define custom commands.
I proposed the following solution to Mircea earlier today, I'll repeat here for you guys to discuss. Note that this is a *half baked* solution and needs more thought! :-)
* If a module needs to define custom commands, it should define its own ReplicableCommand implementations in its' own module.
* It should define a sub-interface to Visitor (MyModuleVisitor) with additional methods to handle the new commands
* Interceptors defined in this module should extend CommandInterceptor AND implement MyModuleVisitor
* These new commands can be created directly, or via a new CommandFactory specially for these commands.
Now for the un-finished bits. :)
* How does RemoteCommandFactory instantiate these new commands? The module should have a way of registering additional command IDs with RemoteCommandFactory.fromStream(). See
http://fisheye.jboss.org/browse/Infinispan/branches/4.2.x/core/src/main/j...
Perhaps RemoteCommandFactory.fromStream() should look up the ID in a map of command creator instances, and each module can register more of these with the RemoteCommandFactory?
* How do interceptors defined in the core module handle commands it isn't aware of? handleDefault()? Or should we define a new handleUnknown() method in Visitor for this case, which would default to a no-op in AbstractVisitor? E.g., in a module-specific command such as MyModuleCommand, I would implement:
class MyModuleCommand implements ReplicableCommand {
public Object acceptVisitor(InvocationContext ctx, Visitor visitor) throws Throwable {
if (Visitor instanceof MyModuleVisitor) {
return ((MyModuleVisitor) visitor).visitMyModuleCommand(ctx, this);
} else {
return visitor.handleUnknown(ctx, this);
}
}
}
Cheers
Manik
PS: There is no JIRA for this. If we like this approach and it works, I suggest we create a JIRA and implement it for 4.2. The impl should be simple once we resolve the outstanding bits.
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
14 years, 4 months
[Pull Request] Modular Classloading Compatibility
by Jason T. Greene
Available here:
https://github.com/infinispan/infinispan/pull/278
The problem is basically that infinispan currently is using TCCL for all
class loading and resource loading. This has a lot of problems in
modular containers (OSGi, AS7, etc), where you dont have framework
implementation classes on the same classloader as user classes (that is
how they achieve true isolation)
You can read about this in more detail here:
http://community.jboss.org/wiki/ModuleCompatibleClassloadingGuide
The patch in the pull request is a first step, and should fix many
issues, but it does not address all (there is still a lot of TCCL usage
spread out among cacheloaders and so on), and ultimately it's just a
work around. It should, however, be compatible in any other non-modular
environment.
Really the ultimate solution is to setup a proper demarcation between
what the user is supposed to provide, and what is expected to be bundled
with infinispan. Whenever there is something the user can provide a
class, then the API should accept a classloader to load that class from.
If it's a class that is just internal wiring of infinispan, then
Infinispan's defining classloader should always be used.
The one case I can think of in infnispan where TCCL really makes sense
is in the case of lazy deserialization from an EE application. However
that is only guaranteed to work when you are executing in a context that
has that style of contract (like in an EE component). There are many
other cases though where someone would expect it to work from a non-EE
context (e.g. from a thread pool). What you really want is the caller's
classloader, but that is not cheap to get at, so it's something that
should be supplied as part of the API interaction (in the case where
there is no EE context). Alternatively you can just just require that
folks push/pop TCCL, but users often get this wrong.
Thanks!
--
Jason T. Greene
JBoss, a division of Red Hat
14 years, 4 months
