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 …
[View More]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.
>>
>
[View Less]
13 years, 5 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 *…
[View More]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
[View Less]
13 years, 9 months
Re: [infinispan-dev] @Externalize in conjunction with Infinispan?
by Galder Zamarreño
On Mar 28, 2011, at 3:50 PM, David M. Lloyd wrote:
> On 03/28/2011 03:53 AM, Galder Zamarreño wrote:
>> Hey David,
>>
>> I'm gonna start looking into @Externalize this week and I was
>> wondering whether we'll be able to use it as is with Infinispan?
>>
>> I mean, we have our own Externalizer interface which then maps to a
>> JBMAR Writer class via an adapter. This adapter is what makes a
>> Writer use our own Externalizer.writeObject(). The …
[View More]reading part is
>> done via an implementation of ObjectTable.readObject() where we map
>> an Id that's written by each of our Externalizer implementations to
>> the corresponding Externalizer so that it can read the object.
>>
>> I get the feeling that the way we use JBMAR might not suit the way
>> you can ship externalizer classes around to unmarshall stuff?
>
> The Externalizer interface and the @Externalize annotation rely on a different mechanism than object tables. You set up the AnnotationClassExternalizerFactory as your class externalizer factory in the configuration and the annotation will be recognized.
>
>> Also, in JBMAR, how does the marshaller side know that it does not
>> need to send the externalizer class again? I ask this cos you'd only
>> want the Externalizer class to be sent once to the receiving end, and
>> only if it's not aware of it? Or does it do it for all nodes in the
>> first request?
>
> It always sends the externalizer instance once for each externalizer. If you send the same externalizer twice, it will of course use a very compact backreference. The size of this initial message is dominated by the length of the class name, unless for some reason you use a complex externalizer.
>
>> Finally, if we can't take advantage of JBMAR to do this for us, how
>> much work do you think it would take to implement something similar
>> at the Infinispan level?
>
> Well ultimately the problem boils down to, how will you communicate which externalizer to use between sender and recipient. Using JBMAR Externalizers is the most simple and flexible option, however writing the class name can consume substantially more space than, say, an integer or a short. That said, the cost disappears into larger messages. The downside of using an integer or short however is that you have to preallocate and/or coordinate the identifier space.
>
> So I guess I don't really have an easy answer. Externalizers are simple but use a little more space. Using numeric IDs are somewhat more difficult (especially for end-users) but use less space.
Thanks David, your reply made me see it clearly.
In fact, I think we'll end up using the two methods. For internal and framework developers, the current set up works nicely. No annotations, so they can abstract Infinispan externalizers easily and we have very small payloads which is very efficient. Remember that I originally tried your Externalizer interface but the end result were payloads that were a bit big for our liking. That's how I ended up with the current set up.
However, for the end user, or average Joe, your Externalizer might be more useful because it uses annotations and needs no pre-registration. So, much easier to use at first glance though some bigger payloads.
CC'ing the infinispan-dev list.
>
> --
> - DML
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
[View Less]
13 years, 11 months
TxRecovery design update
by Mircea Markus
Hi,
I've updated tx recovery design document[1] after feedback received from Manik: the most relevant changed is that all recovery information is now stored in a local cache (user can configure it). This way the user is in control of the memory consumed by recovery, being able to passivate to disk this information when/if needed. And all this out-of-the box.
Cheers,
Mircea
[1] http://community.jboss.org/wiki/Transactionrecoverydesign
13 years, 11 months
Spring Infinispan finished for now
by Olaf Bergner
Hello,
I've decided that Spring Infinispan is where it ought to be right now,
feature-wise and documentation-wise. There's obviously a lot that could
be done to improve it. Yet I don't deem it prudent to go any further as
long as the fine folks over in Spring land are pondering whether and in
what way to accept our offer. If you wish, you may have a look at what
I've done so far at
https://github.com/obergner/spring-infinispan
So, time permitting, I'm willing to tackle the next …
[View More]challenge and
thought about turning my attention to either
https://issues.jboss.org/browse/ISPN-78 - Large Object Support
or
https://issues.jboss.org/browse/ISPN-984 - Add ability to retrieve cache
names remotely in Hot Rod,
depending on which of the two you consider to be more pressing at the
moment. Of course, I'm willing to take on other tasks in case there's
something that needs to be done more urgently. What do you think?
Cheers,
Olaf
[View Less]
13 years, 11 months
[ISPN-78] Alternative interface for writing large objects
by Olaf Bergner
I've started working on ISPN-78 - Large Object Support - closely
following Manik's design document
http://community.jboss.org/wiki/LargeObjectSupport. As a starting point
I'm currently trying to implement
OutputStream writeToKey(K key),
which, for the time being, I chose to declare on AdvancedCache rather
that on Cache proper.
While thinking about the implications, I stumbled upon a few questions
which may well be owing to my lack of knowledge about Infinispan's inner
workings.
1. …
[View More]OutputStream writeToKey(K key) implies that the interaction between
user code and Infinispan happens in the OutputStream returned. Contrary
to existing methods, there would be no well defined *single* point where
control passes from user code to Infinispan. Instead, a user would write
a few bytes, passing control to Infinispan. Infinispan would buffer
those bytes and return control to the user until a preconfigured chunk
size is reached, whereupon Infinispan would probably issue a more or
less standard request to store that chunk on some node. Rinse and repeat.
This is certainly doable but leaves me wondering where that proposed
ChunkingInterceptor might come into play. It is my current understanding
that interceptors, well, intercept commands, and in this scenario there
could not be such a PutLargeObjectCommand as, as I said, there is no
single point where control passes from user code to Infinispan. Instead,
chunking would have to be done directly within the CacheOutputStream
returned, and the only commands involved would be the more or less
standard PutKeyValueCommands mentioned above. In this scenario there
wouldn't be any PutLargeObjectCommand to encapsulate the whole process.
Does this make sense? If so, I'd prefer to have
void writeToKey(K key, InputStream largeObject)
instead. Thus, after calling this method control would be handed over to
Infinispan until that LargeObject is stored, and we could have indeed
have some PutLargeObject command to encapsulate the whole process.
2. For the mapping Key -> LargeObjectMetadata I would intuitively choose
to use a dedicated "system" cache. Is this the Infinispan way of doing
things? If so, where can I find some code to use as a template? If not,
what would be an alternative approach that is in keeping with
Infinispan's architecture?
3. The design suggests to use a fresh UUID as the key for each new
chunk. While this in all likelihood gives us a unique new key for each
chunk I currently fail to see how that guarantees that this key maps to
a node that is different from all the nodes already used to store chunks
of the same Large Object. But then again I know next to nothing about
Infinispan's constant hashing algorithm.
4. Finally, the problem regarding eager locking and transactions
mentioned in Manik's comment seems rather ... hairy. If we indeed forego
transactions readers of a key just being written shouldn't be affected
provided we write the LargeObjectMetadata object only after all chunks
have been written. But what about writers?
I hope this makes sense. Otherwise, don't hesitate to point out where I
went wrong and I will happily retreat to the drawing board.
Cheers,
Olaf
[View Less]
13 years, 11 months
@Marshallable as an option for end user externalizers?
by Galder Zamarreño
Hi,
Some feedback has come saying that it'd be nice to be able to configure externalizers using annotations. Now, in a previous discussion (http://lists.jboss.org/pipermail/infinispan-dev/2010-December/007047.html) it was agreed that for framework developers this is not nice since it makes it hard to abstract the Infinispan layer, but end users might be interested in using annotations rather than having to implement getId(), getTypeClasses() in Externalizer interface - see http://community.…
[View More]jboss.org/docs/DOC-16198
To be able to support this, @Marshallable annotation that would be used wth externalizer implementations would have to be brought back with id and typeClasses attributes. That'd make it a 3rd way to define ids, after XML and getId() implementations.
Clearly, getId() and getTypeClasses() would be moved to a different interface, so that people that chose to use @Marshallable could just provide read/writeObject method implementations.
The gain from having end users use @Marshallable is not that great IMO cos we don't do annotation scanning, so there would still be a need to register externalizers.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
[View Less]
13 years, 11 months
5.0.0.BETA1
by Galder Zamarreño
Hi all,
We're targetting to have a 5.0.0.BETA1 release by the mid-end of next week (week ending on 25th March).
Mircea/Vladimir/Pete/Manik, how's things looking on your side for such release?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years
