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.
>>
>
12 years, 6 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
12 years, 10 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
12 years, 10 months
Hibernate OGM documentation
by Emmanuel Bernard
Hi all
I've been working on Hibernate OGM documentation. I am still very unhappy with what I have but that's a start.
You can read it at http://docs.jboss.org/hibernate/ogm/3.0/reference/en-US/html_single/
You can contribute to it by forking on github https://github.com/hibernate/hibernate-ogm
To build the documentation,
- go to hibernate-ogm-doucumentation/manual
- run mvn install -DbuildDocs=true
You will get the result in target/docbook/publish/en-US
I'm interested in all kind of feedback:
- general feel
- what part is confusing
- what you think is missing (besides the TODOs)
And of course if you can contribute some part, that would be awesome.
Emmanuel
12 years, 11 months
[ISPN-78] RFC: Finalizing API
by Olaf Bergner
Continuing to work on large object support I'm now at a point where I
would like to finalize the API so that I'm free to move forward with
some confidence. This is its current incarnation
public interface StreamingHandler<K> {
void writeToKey(K key, InputStream largeObject);
OutputStream writeToKey(K key);
InputStream readFromKey(K key);
boolean removeKey(K key);
StreamingHandler<K> withFlags(Flag... flags);
}
where a user obtains a StreamingHandler through calling
Cache.getStreamingHandler(). The StreamingHandler manages large objects
on behalf of the backing cache. This doesn't look too bad to me, but
there's always room for improvement.
First a fundamental question with potentially disruptive implications:
what aspires Large Object Support to become in the long run? A
comfortable means for users to store and retrieve large objects in
Infinspan (as it seems today)? Or rather a fully fledged distributed
file system? I favor the former, without precluding the possibility that
one day Infinispan will also implement a file system interface.
Now a question regarding the implementation the answer to which might
affect the API: does it make sense to strictly separate "regular" caches
from those dealing with large objects? I think so, since I presume that
most applications will treat large objects differently from the more
comfortably sized ones. At least that is my personal experience.
Furthermore it might prove difficult to tune a cache that contains both
regular and large objects. Plus by introducing large object caches we
might be able to find a nice set of default settings for those.
If we chose to introduce dedicated large object caches I would opt for
introducing StreamingCache<K> or even LargeObjectCache<K> instead of
StreamingHandler<K> since then a StreamingHandler wouldn't handle large
objects on behalf of some backing cache. Rather it would act as *the*
interface to a cache exclusively reserved for large objects. It follows
that a user would directly access a StreamingCache, not indirectly via
Cache.getStreamingHandler().
And finally there is that eternal question of how to properly name those
interface methods. Trustin has expressed his concern that
writeToKey(...), removeKey() and readFromKey(...) might fail to convey
their semantics. And indeed there's nothing in their names to tell a
user that they deal with large objects. What about alternatives á là
- void storeLargeObject(K key, InputStream largeObject) or
putLargeObject(K key, InputStream largeObject)
- OutputStream newLargeObject(K key) or simply OutputStream
largeObject(K key)
- InputStream getLargeObject(K key)
- boolean removeLargeObject(K key)
? Rack your brains and keep those splendid ideas coming.
Cheers,
Olaf
12 years, 11 months
Questions on AtomicMap and improvement proposals
by Emmanuel Bernard
In exchange for answers, I will improve at least the JavaDoc and maybe create a wiki from this info.
(note that this has nothing to do with the ongoing discussion on key-levle locks for a sister of AtomicMap)
I've tried to search the wiki but found nothing on AtomicMap (only forum posts) and I've read the AtomicMap JavaDoc but I am still a bit unsure of what's going on.
When I need to create an AtomicMap, I must use
AtomicMap<String, Object> resultset = AtomicMapLookup.getAtomicMap(cache, "my_atomic_map_key");
Questions
Here are a few questions for you
1. How can I apply advanced flags to get or create the AtomicMap?
cache.withFlag(SKIP_CACHE_STORE,FORCE_ASYNCHRONOUS).get("my_atomic_map_key");
3. Is that legal to use other cache methods like replace on an AtomicMap value, what are the consequences?
3. When I expect a map to be present in the key, can I use cache.get("my_atomic_map_key") and still benefit from my properly proxied AtomicMap? Or am I forced to use AtomicMapLookup.getAtomicMap?
4. Using AtomicMapLookup.getAtomicMap, how can I differentiate an empty key where a new map has been created from a retrieval of an empty map stored in the key?
5. Must I use AtomicMapLookup.remove method to remove an atomic map?
6. Can I clone an AtomicMap?
For using methods like replace(), it seems one would need to clone the atomicmap to compare it to the initial value. When I tried briefly Iw as unsure I could do that.
Proposed improvements
I'm asking all the questions because these can potentially make AtomicMap users life quite hard and abstracting Infinispan from OGM will make a damn ugly interface / contract
1. Would it be possible to let people get their proxied AtomicMap from cache.get() and other get methods?
It seems that either the marshaller or the get operations (probably the get ops as local cache should work as well) should be able to intercept an AtomicMap and essentually do what AtomicMapLookup is doing (and make sure it is properly wrapped).
If that's possible that would be already a big benefit for the user as it would only be limited to AtomicMap creation or cloning
2. Would it be possible to let people create standalone AtomicMaps and associate them to the cache lasily and in a transparent fashion.
AtomicMap<String, Object> resultSet = AtomicMapLookup.createAtomicMap();
cache.put(key, resultSet); //lazily set cache, deltaMapKey, batchContainer and icc for new AtomicMaps
3. Could we guarantee some equality between Map and AtomicMap?
if I do Map
map = new HashMap(atomicMap);
atomicMap.put("key", "value");
cache.replace(key, map, atomicMap);
Am I guaranteed that it can work (if no one has pushed a change behind my back)?
Emmanuel
12 years, 11 months
cache name in logs
by Mircea Markus
Hi,
I'm looking into some logs for the a JBW demo : it has 4 caches deployed on each node and lots of topology changes happen. It's close to impossible to tell which log pertains to which cache, especially around the DistributionInterceptorImpl.
Wouldn't it make sense that, for certain components, to include the name of the cache in the logs? IThis might be achieved with minimal changes by adding an additional param to the LogFactory.getLog(Class) method and let the logger itself do the heavy lifting.
e.g.
Log l = LogFactory.getLog(DistributionManagerImpl.class, "cacheName");
and on each call l.trace("A message") the logger might output, besides underlying log's format, the string "[cacheName] A message".
Wdyt?
Cheers,
Mircea
12 years, 11 months
Infinispan Query entity discovery (Was: Re: new Infinispan Query API - ISPN-194)
by Sanne Grinovero
Hello,
I'm forking off this thread, as we never resolved how to cope with the
main issue:
how is Infinispan Query going to be aware of which entities are to be
considered as default targets for a Query?
the realistic ideas so far:
A) class scanning: seems nobody liked this idea, but I'll still
mention it as the other options aren't looking great either.
B) scan known indexes (need to define what the "known indexes" are as
we usually infer that from the classes)
-- could enforce a single index
C) have to list all fully qualified class names in the configuration
D) don't care: consider it a good practice to specify all targeted
types when performing a Query.
E) please suggest :)
The currently implemented solution is D, as it requires no coding at all :)
considering the simplicity of it I'm liking it more the more I think
about it; I could even polish the approach by adding a single line to
log a warning when the user doesn't respect the best practice, or to
mandate it.
Considering that when a Query is invoked specifying the target types
there is no doubt we know the classes, I could add a warning in case
the Query is performed without specifying the type: in that case it
usually implies the query targets all known types, which is always
fine when using Hibernate Search, but could be inconsistent with
Infinispan Query as it might not have discovered all types yet (1), so
a very simple solution is to mandate the type parameter.
[1] - when the Cache interceptor hits an event adding a new type, the
Search engine is reconfigured.
thoughts?
Sanne
2011/4/5 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>
> On 5 avr. 2011, at 13:38, Sanne Grinovero wrote:
>
>> 2011/4/5 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>>>
>>> On 5 avr. 2011, at 12:20, Galder Zamarreño wrote:
>>>
>>>>
>>>> On Apr 4, 2011, at 6:23 PM, Sanne Grinovero wrote:
>>>>
>>>>> </snip>
>>>>>
>>>>> there's one catch:
>>>>> when searching for a class type, it will only include results from
>>>>> known subtypes. The targeted type is automatically added to the known
>>>>> classes, but eventually existing subtypes are not discovered.
>>>>>
>>>>> Bringing this issue to an extreme, if the query is not targeting any
>>>>> type, and no indexed types where added to the grid (even if some exist
>>>>> already as they might have been inserted by other JVMs or previous
>>>>> runs), all queries will return no results.
>>>>> How to solve this?
>>>>> - class scanning?
>>>>
>>>> Nope, too expensive.
>>>>
>>>>> - explicitly list indexed entities in Infinispan configuration?
>>>>
>>>> No
>>>>
>>>>> - a metadata cache maintaining a distributed&stored copy of known types
>>>>
>>>> That sounds more appealing. It could be a good middle ground until Search can search for types.
>>>
>>> Do you have any specific idea in mind?
>>>
>>> To magically find types:
>>> - we scan every file system, databases, caches available to the app and look for Lucene metadata => unrealistic
>>> - there is some kind of convention on where the indexes are and we do index scanning at startup => scanning are very likely to be slower that class scanning (potential remote access, bigger dataset etc)
>>> - we enforce one or a fixed number of Lucene indexes for all data in Infinispan => not sure that's a good idea but this can be explored
>>> - we somehow ask the framework using HSearch to fill up classes
>>>
>>> other approaches?
>>
>> why was class scanning discarded in the first answer? as H. Search can
>> auto-discover classes by working on top of JPA entity autodiscovery, I
>> guess that each application node could look into it's own known
>> classpath.
>> After all if some type is not visible to him as it was added from
>> another node from a different app, he won't be able to return
>> instances of it either.
>> We could face the opposite problem of building metadata of classes
>> people doesn't mean to index in this cache.
>
> Right. scanning (class or index) will be a bit aggressive and could build unneeded metadata (or even worse, return unexpected classes).
12 years, 11 months
Describing infinispan
by Paolo Romano
Hi guys,
we're preparing a paper describing the self-tuning replication mechanism
(Primary backup vs the 2PC-based replication mechanism currently used by
Infinispan), and we'd like to stress how relevant Infinispan is for the
J2EE community, and (I was thinking) in particular for the JBoss AS.
Is it correct if we say that Infinispan is the reference in-memory NoSQL
data grid for the JBoss Application Server, which is the most popular
open source J2EE AS ?
Do you have access to any public statistics on the number of users of
Infinispan/JBoss AS?
Of course, feel free to suggest any other cool phrase to highlight the
relevance of Infinispan in the NoSQL data grid domain!
Cheers,
Paolo
--
Paolo Romano, PhD
Coordinator of the Cloud-TM ICT FP7 Project (www.cloudtm.eu)
Senior Researcher
INESC-ID
Rua Alves Redol, 9
1000-059, Lisbon Portugal
Tel. + 351 21 3100300
Fax + 351 21 3145843
Webpage http://www.gsd.inesc-id.pt/~romanop
12 years, 11 months
