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.
>>
>
15 years, 1 month
FIFO ordering...
by Bryan Grunow
I posted JIRA issue https://jira.jboss.org/jira/browse/ISPN-132 a while ago and I'm wondering if it's on the roadmap anywhere?
I've worked on this internally and have a working solution but I'd like to know it's coming soon or not. If not I will continue working on it but I need some guidance on the design to make sure it fits properly into Infifispan.
Thanks,
Bryan
17 years
Update on the DSL
by Navin Surtani
Hello all,
Just to let you know that I'm focusing on writing up the DSL asap. I
realise that since I've switched over to part-time due to university
term it's tough to keep in touch with everyone constantly. So I
thought I'd just drop the list a quick spam email.
Emmanuel, you had mentioned that you want this done fairly quick (from
other emails on the list) so I'm gonna push to do this as quick as I
can. The next couple of weeks are likely to be slightly busy but I
should have one or two Mondays off in the run-in to Devoxx so fingers
crossed over those I can sit down and hack through some coding. Also
since I'll be around for a full day it will be easier to communicate
via Skype etc etc.
I'll generally try and keep people updated as much as I can via
emailing the devlists so I can get some feedback/input/strokes of
genius from the various crews.
Thanks,
Navin Surtani
Intern Infinispan
Intern JBoss Cache Searchable
17 years
Cache entry not invalidated callback?
by Galder Zamarreno
Hi,
Re: Porting over
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818 to
Infinispan 2nd level cache.
For HHH-3818, Brian used the cache as a bus to notify that the cache
contents where invalid. To do so, he implemented cache entry modified
and invalidated callbacks that react to cache modifications or
invalidations where the FQN is an internal fqn which contains the local
address.
Now, the trick he uses for the invalidation is that on startup or
whenever there's a view change, he establishes these internal FQNs in
each node for each of the members in the cluster, i.e.
fqn=/test/com/foo/test/ENTITY/NODE/127.0.0.1:39104
So, in an invalidation scenario, if you a node puts something on
/test/com/foo/test/ENTITY/NODE/127.0.0.1:39104, the other nodes have at
least /test/com/foo/test/ENTITY/NODE/127.0.0.1:39104 created on their
caches which means that the invalidation callback works fine cos the FQN
exists in other nodes.
Now, in Infinispan's case, bearing in mind that there're no FQNs, I
could set up such keys when there's a view change too. However, I was
thinking of another alternative.
Currently, cache invalidation callback fails on Infinispan because when
you do a put on key=127.0.0.1:39104, the other nodes do not contain the
key=127.0.0.1:39104, so no invalidation callback is received. So, my
suggestion is the following:
Why not have a callback saying: "I attempted to do an invalidation on
k=x but k=x did not exist". Maybe something like
CacheEntryNotInvalidated callback? It looks to me that it'd be
relatively simply to implement such notification and would simplify the
code on the Infinispan 2nd level cache provider.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
17 years
Making confusion between different remove() APIs
by Sanne Grinovero
Hello,
I was writing this code:
boolean cleared = cache.remove(key);
and then I'd thought "let's add a Flag", resulting in:
boolean cleared = cache.remove(key, Flag.SKIP_CACHE_STORE);
Considering that CacheDelegate contains the following 3 overloaded
"remove" methods:
====== CacheDelegate<K,V> ======
public final boolean remove(Object key, Object value) {
return remove(key, value, (Flag[]) null);
}
public final boolean remove(Object key, Object oldValue, Flag... flags) {
...
}
public final V remove(Object key, Flag... flags) {
...
}
====== end code snippet ======
Guess which one is called?
The first one, interpreting my Flag as a value, and obviously my code
was broken.
It's fixed by using:
cache.remove(keyOfLock, new Flag[]{Flag.SKIP_CACHE_STORE});
IMHO it's quite bad already that the CHM has different remove
variants, one returning the previous object and one returning a
boolean "removed or not removed", but this API in Infinispan is making
it even harder.
It would be safer to mandate the array form for Flags, even if I don't
like that; do you have a better idea?
Regards,
Sanne
17 years
ISPN-185: Injecting a running JGroups channel into Infinispan
by Manik Surtani
Regarding ISPN-185 [1] (Need to provide a mechanism in which a JGroups
channel can be passed in), I'd like to discuss a few solutions. I
believe this directly affects the way JBoss AS will use Infinispan, so
it would be good to hear from JBoss AS folk on this subject. :)
Transport [2] is an interface that wraps up the JGroups Channel (among
other things), and the default (only?) implementation so far is the
JGroupsTransport [3]. Now one thing we can do to support channel
injection is to actually support Transport injection. This way a
Transport can be constructed (simple constructor), the JGroups channel
set, and the transport passed in to a GlobalConfiguration instance
(setter TBD), which is then in turn passed to a DefaultCacheManager
constructor [4].
The problem with this approach though, is that it will only work for
programmatic configurations. To support declarative configurations as
well, we'd need to override the relevant DefaultCacheManager
constructors [5] [6] [7] [8] to accept a Transport as well. But this
pollutes the CacheManager API, in my opinion.
So, how important is it that a running channel is used to override
something defined in XML?
Cheers
Manik
[1] https://jira.jboss.org/jira/browse/ISPN-185
[2] http://docs.jboss.org/infinispan/4.0/apidocs/org/infinispan/remoting/tran...
[3] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i...
[4] http://bit.ly/3roPkl
[5] http://bit.ly/vDtwa
[6] http://bit.ly/2FhsUn
[7] http://bit.ly/7YC8d
[8] http://bit.ly/2rgtyP
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
17 years
StressTest: Can JGroups provide a callback to do marshalling after real_dests have been calculated?
by Galder Zamarreno
Hi Bela & co,
While investigating your stress test, I've found a few interesting
things. I'm gonna split in 2 emails:
1.- First of all, a week ago filled
https://jira.jboss.org/jira/browse/ISPN-237 jira in order for dist
commands that should only affect the local machine not to go remove.
While investigating your stress test, I've found out that JGroups'
MessageDispatcher.castMessage already does that!
if(tmp != null &&
tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) {
if(local_addr == null) {
local_addr=tmp.getAddress();
}
if(local_addr != null) {
real_dests.removeElement(local_addr);
}
}
That code empties the real_dests if the target is the local address. So,
you're probably wondering why I filled
https://jira.jboss.org/jira/browse/ISPN-237? It's because marshalling
happens before the code above gets executed. In fact, it happens at the
beginning of ReplicationTask.call() and the JGroups optimization happens
when castMessage() is called from ReplicationTask.call().
So, I think my fix for https://jira.jboss.org/jira/browse/ISPN-237 is
not optimal. JGroups already knows when the call should stay local, so
ISPN should need to do this calculation again, it's wasteful code. The
real fix would be to somehow be able to do marshalling only if the code
in MessageDispatcher.castMessage() said that real_dests was not empty.
Bela, do you think JGroups could be enhanced to have a callback after
the code shown above where we can invoke marshalling?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
17 years
Leak of impl detail? Listener callbacks receiving MarshalledValues if lazy deserialization is on
by Galder Zamarreno
Hi,
I've noticed that when lazy deserialization is on and you use a user
defined key, notification callbacks receive MarshalledValue instances
within event.getKey() rather than instances of the user defined class.
This forces listener code to be aware whether lazy deserialization is
enabled or not, hence we're leaking an implementation detail to the
client code.
I think these callbacks should provide user defined class instances
regardless of whether lazy deserialization is on or not.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
17 years
Dependency on JGroups
by Vladimir Blagojevic
Guys,
Did anyone recently change dependencies in the poms? All of a sudden mvn
eclipse:eclipse target generates eclipse .projects files where
non-existing JGroups project is declared a dependency.....
Vladimir
17 years
