10:36 a.m.
Hi all,
Sebastian recently added BCHMV8 resizing and I'm now hooking it up to
configuratiombean jmx and server. I wanted your opinion on some details.
- configuration: easy, register a listener with the attribute so that invoking
configuration.eviction().size (newSize) does a resize of the data container
- server already exposes the size in the management model, we just need to change its
behaviour so that the change is "live". In this context the change is also
persisted to the xml configuration
- Jmx: do we want a writable "capacity" attribute or a resize operation? And do
we want it on the cache mbean or on a new data container mbean? And should the change
affect the configuration object too, i.e. invoking configuration.eviction().size () should
return the new value? For symmetry with server we should.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss a division of Red Hat
1:13 p.m.
Hey Tristan!
See comments inlined.
Thanks
Sebastian
On Mon, Oct 5, 2015 at 10:36 AM, Tristan Tarrant <ttarrant(a)redhat.com>
wrote:
- configuration: easy, register a listener with the attribute so
that
invoking configuration.eviction().size (newSize) does a resize of the data
container
+1, looks like a simple solution that might do the job.
- server already exposes the size in the management model, we just
need
to change its behaviour so that the change is "live". In this context the
change is also persisted to the xml configuration
+1, I like this approach however it may confuse our users a little bit.
Maybe we should have a flag in configuration (disabled by default) which
would enable persisting changes back into xml?
- Jmx: do we want a writable "capacity" attribute or a
resize operation?
And do we want it on the cache mbean or on a new data container mbean? And
should the change affect the configuration object too, i.e. invoking
configuration.eviction().size () should return the new value? For symmetry
with server we should.
+1 for writable attribute. This would fix nicely into configuration
listeners. How about exposing new Configuration MBean with all writable
configuration attributes?
+1 for staying symmetric with our solution.
1:51 p.m.
On 06/10/2015 13:13, Sebastian Laskawiec wrote:
+1, I like this approach however it may confuse our users a little
bit.
Maybe we should have a flag in configuration (disabled by default) which
would enable persisting changes back into xml?
No, this would go against the WildFly model of doing things. What can be
done is to create a special attribute set to RUNTIME_ONLY, but I'm not
sure I like this.
- Jmx: do we want a writable "capacity" attribute or a resize
operation? And do we want it on the cache mbean or on a new data
container mbean? And should the change affect the configuration
object too, i.e. invoking configuration.eviction().size () should
return the new value? For symmetry with server we should.
+1 for writable attribute. This would fix nicely into configuration
listeners. How about exposing new Configuration MBean with all writable
configuration attributes?
Ideally it would be nice to replicate the same tree structure of the
server configuration model (which also mimics the programmatic API), so
that each cache trait has its own MBean. This would mean for example
having an Eviction MBean as a child of the Cache MBean.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
12:49 p.m.
--
Galder Zamarreño
Infinispan, Red Hat
On 5 Oct 2015, at 09:36, Tristan Tarrant <ttarrant(a)redhat.com>
wrote:
Hi all,
Sebastian recently added BCHMV8 resizing and I'm now hooking it up to
configuratiombean jmx and server. I wanted your opinion on some details.
- configuration: easy, register a listener with the attribute so that invoking
configuration.eviction().size (newSize) does a resize of the data container
- server already exposes the size in the management model, we just need to change its
behaviour so that the change is "live". In this context the change is also
persisted to the xml configuration
- Jmx: do we want a writable "capacity" attribute or a resize operation? And do
we want it on the cache mbean or on a new data container mbean? And should the change
affect the configuration object too, i.e. invoking configuration.eviction().size () should
return the new value? For symmetry with server we should.
I'd add it to the cache mbean.
My first impression is that the configured value should change too.
Cheers,
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss a division of Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
3187
days inactive
3190
days old
infinispan-dev@lists.jboss.org
3 comments
3 participants
participants (3)
-
Galder Zamarreño -
Sebastian Laskawiec -
Tristan Tarrant