[Fwd: Re: [JBoss-dev] JMX service architecture: next gen++ [davidje ncks@directvinternet.com]]
[Forwarding to the list. %#¤% missing Reply-To: header] Original Message Subject: Re: [JBoss-dev] JMX service architecture: next gen++ [davidje [EMAIL PROTECTED]] Date: Wed, 03 Oct 2001 22:15:28 +0200 From: Ole Husgaard [EMAIL PROTECTED] Organization: Sparre Software To: David Jencks [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Hi, Having some VM-local centralized service that gives serial numbers to transactions would be possible. But how about routing MBean invocations to the right MBean version? For this to work we would need another layer for doing the invocation routing. With this layer we could get around the garbage collection problem, if it is notified of the termination of jmx transactions. The routing layer would have to remember old transactions to know which version to route the invocation to. If the transaction has not been seen by the routing layer, it just routes to the most recent version and remembers that this tx should use this version. When the routing layer is notified that a transaction has ended, it forgets its association between the mbean version and the transaction. If this means that no more transactions are associated to an old version mbean, it can garbage collect the old mbean. But still, a bit too hairy imho. Best Regards, Ole Husgaard. David Jencks wrote: The other reason I like the database approach (aside from liking its elegance) is that it provides a way to tell when you can throw out the old version of the mbeans: when all invocations [jmx transactions] numbered less than the transaction active when the change committed are complete. Without something like this I'm not sure how to tell when its ok to deregister the old set of mbeans: they're in the mbean server, so they won't just be garbage collected when all the references are gone. Maybe reference counting... but this may be hard to get right. david jencks On 2001.10.02 21:26:49 -0400 Jay Walters wrote: If you use copy on write of the MBeans (and on the list of MBeans - the stack) then you can probably do everything needed. Of course this raises questions about what is the impact of multiple versions of a specific MBean is, but these are supposed to be stateless interceptor-like MBeans right, so it's not like you're making a new connection pool. I would think a simple copy on write approach would be the quickest to write, but it needs to be wrapped up so the code adding the new MBean doesn't have to remember to do the copy - it just happens. I imagine this is why the model of a database that just does it, is appealing. Cheers -Original Message- From: David Jencks To: jboss-dev Sent: 10/2/01 6:38 PM Subject: Fwd: Re: [JBoss-dev] JMX service architecture: next gen++ [[EMAIL PROTECTED]] (Maybe this time I will get this to the list-third try is the charm?) On 2001.10.02 15:07:05 -0400 David Jencks wrote: (forwarding to list, hope this is ok with you) This is exactly what I was thinking, and what the firebird-style versioning does for you. I am not suggesting storing much of anything in a persistent db, I haven't thought about that yet: what I am talking about is how to make the configuration changes transactional/atomic and allow pre-completion invocations complete with the old versions, whereas post completion invocations use the new versions. I think this is not that hard to do with firebird as a model, maybe adding the version id into the mbean object name. Needs some more thought. Some of this can be taken care of by copy on write invocation lists, but I'm not sure all of it can. Thanks david jencks On 2001.10.02 14:45:05 -0400 Ole Husgaard wrote: Hi, I've been speculating about this in the context of bean redeployment. Just creating a new configuration (or deployment) and atomically switching over to it is not really enough: Old transactions that have used the old configuration (or deployment) should continue to use that, so the old configuration (or deployment) has to be kept until all transactions that have ever used it have terminated. But to avoid service disruption, calls in the context of new transactions that have not used the old configuration should be using the new configuration at the same time as some old transactions still use the old configuration. I agree that this can become very hairy. Best Regards, Ole Husgaard. David Jencks wrote: Don't panic marc, even I don't plan to implement this this week ;-) Here's the context I'm thinking about, and please note IANASA (I am not a system administrator)... but if I were running the jboss cluster at Megacorp Conglomerates, I expect my audit trail requirements would include knowing exactly what configuration was used to process each online b2b soap enabled etc purchase
Re: [JBoss-dev] JMX service architecture: next gen++
marc fleury wrote: the ejb behavior is implemented in the actual linked list of interceptors that we put there, exactly what we do today from the ContainerFactory but completely and **genericaly** at the JMX layer. Building the EJB will be nothing more than passing standardjboss.xml topology of stacks. Gotcha. |It should be doable as MBeans, i.e. no real need to change the bus. The |interceptor stack map fairly well to JMX Adaptors. I am surprised Andreas is not on your case yet, the JMX adaptors in his eyes have a very different meaning. You seem to suppose that adaptors=interceptors (as in invoke() stacks). Andreas explains in the book that adaptors are really just an adaptor from the semantic of the calls coming from the connectors to the semantics of the JMX bus. Different things. That would be one way of looking at it. In that sense they map fairly well to the Bridge design pattern, i.e. converting between two worlds of perspectives. I'll rephrase myself. Interceptors could be done as a series of JMX MBeans implementing DynamicMBean, i.e. they don't do anything with the call except delegate to other DynamicMBeans, with the last one actually doing something. This would work, and it would make it simple to configure each interceptor separately, since they're MBeans. The problem is that for each MBean requiring a specific set of interceptors there would be a bunch of additional MBeans (i.e. the interceptors themselves). You would hence get loads and loads of MBeans who play the interceptor game. Not sure if that's a good idea. However, if you put the interceptors in the bus you then have two ways of writing components: as MBeans and as JMX server interceptor plugins. Any thoughts on that? |There are a couple of important points to lessen the crazy aspect: |1) There will not be nxn connections where n is number of services. The |*worst* case will be sxs connections where s is the *number of servers*. |RMI connections can be shared by MBeans in the same server. right, and even in the rabbit hole picture that is not limited to RMI (I am not saying you are saying this ;-). Good point. Actually, there's no need to use RMI for the talking, only required for talking to the LUS. What you get from the LUS could be the connectors to the other servers, which can talk whatever lingo you want. In this sense you're only using the Jini/LUS as a way for the servers to find each other. After that you can do whatever you want. But I suspect that for many first iteration it will nxs at least with the current implementation of the proxies. If we do smart stuff (like I outlined to bill and you privately) then we can actually reuse the connection. It is the power of the detyped invocation and we don't know what is behind or need to. True. |But you do have a point in that it might be the case that configuring |the stacks can be done *more efficiently* if done inside the server. |Maybe, maybe not. It's more clear cut than that. Take the debugging for example. Say that we want to trace particular flows in the system. What we would do is start sending radioactive messages with a trace flag IN THE MESSAGE. And the one that stamps the messages like that can be some code flag in the connector sure but that would be inferior since we can't update that part so easily (well you can in rabbit hole due to the dynamic hot deploy of server parts but that is beyond the point). The point is that we can put ANY NEW FANCY tracer in there dynamically that would add any complex type to the payload of the MI going in so we can do fancy tracing. Then we can remove the interceptor ENTIRELY, not even fuck with flag settings in JMX and what not. It is a whole new level of JMX infrastructure as plugin management and dynamic scripting of flows... all due to the JMX bus presence with a fully detyped invocation. Interesting. And how is this configuration done? Also through JMX? What you'd want to avoid is two ways of doing the same thing (e.g. JMX + JMX/infra) To me these are squarely system issues that are better dealt at the system level. +1. The role separation is very easy to do in that invoke flow (like you did the interceptors in JBoss2 rickard) and it is very clear. It's your stuff in a new dimension, don't you see? Loud and clear. |That's important for the five nines, indeed. Or six or seven or how |many nines you want. ahw wtf, nine nines.. that'd be something :-) yes we are there :) read the microsoft research papers of 2 weeks ago.. we are flying so fucking high they can't even start to hear us... Read and giggled :-) They are way way behind. u 2 days to get the message through... glad its a Roger, you won't get many communications 8-) The other beautiful thing about this is it IS SO CORE that before a vendor can rip off our ideas (hello again) we will know for sure as there isn't a fucking other soul on
RE: [JBoss-dev] JMX service architecture: next gen++
|I'll rephrase myself. Interceptors could be done as a series of JMX |MBeans implementing DynamicMBean, i.e. they don't do anything with the |call except delegate to other DynamicMBeans, with the last one actually |doing something. This would work, and it would make it simple to |configure each interceptor separately, since they're MBeans. The problem Yes this would indeed be the prefered way to work on the interceptors at run time. |is that for each MBean requiring a specific set of interceptors there |would be a bunch of additional MBeans (i.e. the interceptors |themselves). You would hence get loads and loads of MBeans who play the |interceptor game. Not sure if that's a good idea. However, if you put Not necessarily. Take for example the transaction interceptor in JBoss. It is essentially a purely stateless component so that many threads can go through it at once. In clear even just ONE instance of the component (Tx interceptor EJB semantic) is probably enough to take the full load of the server. I don't know enough about compiler technology to know if this is true or not. If it is not I suspect we can MBean a set of them under the same MBean if we can use the JINI stuff to cluster them *inside* a node I would be interested in hearing how. You would have a call come in with the MI and whatever the type of bean at the end as long as you want Tx-EJB-style and you store a ref to the context in the message... you have created a brand new state machine in the Turin sense. Each interceptor is a state machine that works on stateless sequence of symbols (the MI coming through) and modify the symbols based on contextual information (tag declaration in tx for example). |the interceptors in the bus you then have two ways of writing |components: as MBeans and as JMX server interceptor plugins. | |Any thoughts on that? I didn't think about that before, but if you are right and we can indeed use the ONE dynamic MBean instead of custom stacks per bean, the we could very well have the mbean be the interceptors. The good news as you have been asking is that we don't need a special treatment for the JMX server. We need it to be UBER FAST which means IBM is out and SUN...well. Care to write one with Juha as add-on when you are done with the book ? I am sure people will pay a fair price for the speed. It would be very relevant to put the effort and time in a professional add-on here. No speed? IBM... want speed? we got it! |Good point. Actually, there's no need to use RMI for the talking, only |required for talking to the LUS. What you get from the LUS could be the |connectors to the other servers, which can talk whatever lingo you want. |In this sense you're only using the Jini/LUS as a way for the servers to | find each other. After that you can do whatever you want. ok... sure... |Interesting. And how is this configuration done? Also through JMX? What |you'd want to avoid is two ways of doing the same thing (e.g. JMX + |JMX/infra) in the case of MBeans that would be it. | The role separation is very easy to do in that invoke flow (like |you did the | interceptors in JBoss2 rickard) and it is very clear. It's your |stuff in a | new dimension, don't you see? | | |Loud and clear. good. Saw your emails to Juha, glad you are finally listening to the kid, the book will be great. | yes we are there :) read the microsoft research papers of 2 |weeks ago.. we | are flying so fucking high they can't even start to hear us... | | |Read and giggled :-) They are way way behind. yeah but they will reach our point by the time they reach 3.0. Remember, they don't care about time they have got money, we don't so we care about speed. time == money is no insight really | The other beautiful thing about this is it IS SO CORE that |before a vendor | can rip off our ideas (hello again) we will know for sure as |there isn't a | fucking other soul on earth that is using JMX EVEN TODAY as the base like | you did rickard. They all use it for management. | | |Good point. it is our radio-active trace. |We're all proffessional thieves, in some sense. :-) It's how good you |are at putting different things together in different dimensions that |makes it interesting or not. :-) | | man I feel better it has been on my mind for quite some time now. | Love, to the ones who deserve it. | | To the rest... | | we will bury you | -- Krutchev? -- | |You're a blanwhite kinda guy ;-) Glad I'm on the right side of the fence. Barely. It is important in these days of hunger to keep the message simple. You guys need to be spoon fed as you have been starving for so long. If B$W is clear then we can move on to technicolor (JBoss gets certified! in your dreams!) marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
|However, if you put |the interceptors in the bus you then have two ways of writing |components: as MBeans and as JMX server interceptor plugins. | |Any thoughts on that? The price you pay for the invocation on the bus on the bus isn't significant. Therefore the advantage of the MBean approach to interceptor you propose might just be the ticket from an administration standpoint. We would create the interceptors independently of each other. And then creating a stack is nothing more than instructing incoming gates (.net, rmi, whatever) that the messages requesting EJB-style fielding should go through this stack of ObjectName interceptors. standardjboss.xml needs to map one on one there. The stack of state machines, the movie seen by the MI, is a random access stack from the point of view of the admin. Then updating the flow means talking to that route mapper at the gates. We need a watchdog. Where is stacy when you need her. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
marc fleury wrote: We would create the interceptors independently of each other. And then creating a stack is nothing more than instructing incoming gates (.net, rmi, whatever) that the messages requesting EJB-style fielding should go through this stack of ObjectName interceptors. standardjboss.xml needs to map one on one there. Well, the only thing the incoming gates would have to know is to immediately delegate to the stack configuration MBean. After that it can take care of the stack config. *But this will only work if the interceptor/config interleaving is done as outlined in previous post*. Otherwise it will be an MBean explosion... The stack of state machines, the movie seen by the MI, is a random access stack from the point of view of the admin. Then updating the flow means talking to that route mapper at the gates. Which, as discussed, need to be hand-holding the MI as it travels along the stack. /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
|Well, the only thing the incoming gates would have to know is to |immediately delegate to the stack configuration MBean. After that it can |take care of the stack config. | |*But this will only work if the interceptor/config interleaving is done |as outlined in previous post*. Otherwise it will be an MBean explosion... 4 hours of sleep and I need coffee but no I think that you don't have explosion as we now know that you can use stateless interceptor which enables you to have ONE instance per node as well as at the beginning mapping that the MI sees coming in, no need to go through the config interceptor every call. Do you agree? |Which, as discussed, need to be hand-holding the MI as it travels along |the stack. no as it comes in... (imnho) marcf | | |/R | | |-- |Rickard Öberg |Software Development Specialist |xlurc - Xpedio Linköping Ubiquitous Research Center |Author of Mastering RMI |Email: [EMAIL PROTECTED] | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
marc fleury wrote: |Well, the only thing the incoming gates would have to know is to |immediately delegate to the stack configuration MBean. After that it can |take care of the stack config. | |*But this will only work if the interceptor/config interleaving is done |as outlined in previous post*. Otherwise it will be an MBean explosion... 4 hours of sleep and I need coffee but no I think that you don't have explosion as we now know that you can use stateless interceptor which enables you to have ONE instance per node as well as at the beginning mapping that the MI sees coming in, no need to go through the config interceptor every call. Do you agree? Let's see if I understand this right. Do you send the list of interceptors as part of the MI? I.e. the list contains the MI and an index, and each interceptor just increases the index and delegates to the next? Or how is the stack controlled? What is the driver of the interceptor delegation? /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
For logging purposes ;) need...early... coffee. marcf |-Original Message- |From: marc fleury [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, October 02, 2001 9:13 AM |To: Rickard Öberg |Subject: RE: [JBoss-dev] JMX service architecture: next gen++ | | ||It should be. So then you will instead have n number of Tx-EJB-style ||MBeans for each configuration of it that you want to be able to use. | |not necessarily, I wasn't probably very clear in my previous emails, |a lot of the configuration is in the metadata used by the |interceptor today and that data can be pegged with the MI. | ||There is a stacking problem here though. If each interceptor is supposed ||to know which interceptor comes next in the chain, then you will need | |Who said that it would work like jboss2? reread my email, I talk |about a stack of object names. | |That stack is essentially a map of the interceptors you are going |to go through as an MI. That stack is not harcoded in the |interceptors but in the gates where the MI is created. What type |of MI are you ? you are going to go through A-B-C-D. What type of |MI are you? you are going to go through C-D-Z. | |Can you hear me? Can you see me? | |Ok for work! | ||one instance per *chain configuration*. I.e. if you have two MBeans ||being served by the same chain, and then want to modify the chain for ||one of the MBeans, you'll have to duplicate the chain and make the ||modification. It would be messy. | |I don't think so. | ||The only way I can see to get around that is to have the interceptor ||chain interleaved with a configuration interceptor. | | || ||Example: ||MBean XYZ wants the interceptor chain A,B,C (where C handles the call). ||Somehow this config info is given. An interceptor stack management MBean ||(MGMT) knows this, and for each incoming call the actual runtime chain ||of invocations looks like this: ||1. Connector.invoke (incoming call) ||2. MGMT.invoke (MGMT is delegated to, and in turn delegates to first in ||chain) ||3. A.invoke (do the A stuff, delegate back to MGMT) ||4. MGMT.invoke (determine that the chain has progressed past A, delegate ||to B) ||5. B.invoke (similar as 3) ||6. MGMT.invoke (same as 4) ||7. C.invoke (similar as 3, delegate to XYZ through reflection) ||8. XYZ.invoke ||9. return through interceptors ||10. Connector.invoke return result | |That is a way, but is this better than giving the map at the |beginning? You save on a ton of calls and you still have the |dynamicity of the configuration (update maps == (LinkedList of |ObjectNames)) | ||This is the only way you can get away with having a finite amount of ||interceptor MBean instances. If each interceptor is aware of the next in ||the chain, as in JBoss2 EJB, then you will have the config explosion ||problem (i.e. each interceptor will have the state config+chain ||knowledge instead of just config). || ||See what I mean? | |Yes, right analysis on the wrong hypothesis. | ||To get this to work the interceptor chain needs the following meta-info ||in the MI: ||1. Final MBean to invoke (XYZ in above case. this identifies the chain ||to use) | |OBjectName as identifier. Map of maps to component where |essentially we store the metainformation we used to use in the |container of jboss2. | ||2. Point in chain (0,1,2,3 in above case. this identifies which ||interceptor in the chain to delegate to next) ||3. method ||4. arguments ||5. custom meta-data(?) | |On 4. I got this idea from Dresdner Bank in London with the |project open adaptor. You might want to check it. I think |their view of the system world is a bit soft but the logic is |there and is kind of relevant. They described random payloads as just |Object[] | |in their case I think they typed the payload as some silly object |DataObject[] or something like that, which I think is superflous. |Again we are doing that but on steroids and with a clearer system |head (they use properties to configure the stacks) but the |philosophy is known by the bank guys. | |On 5. custom meta-data might be interesting, at least in the |navigation structures of it, I don't know. | ||This way you can take maximum advantage of the fact that interceptors ||are largely stateless (and thread-safe), hence reusable for multiple ||concurrent calls. | |You got it. | ||Yes, true. As in above, the point-in-chain is very important though in ||order to externalize the actual chain from the interceptors. || ||Agree? | |almost see above, | ||It would require the above to work I think, but it's definitely doable. | |almost there rickard | |marcf | || ||/R || || ||-- ||Rickard Öberg ||Software Development Specialist ||xlurc - Xpedio Linköping Ubiquitous Research Center ||Author of Mastering RMI ||Email: [EMAIL PROTECTED] || ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc |fleury |Sent: Tuesday, October 02, 2001 9:15 AM |To: Rickard Öberg; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] JMX service architecture: next gen++ | | ||Well, the only thing the incoming gates would have to know is to ||immediately delegate to the stack configuration MBean. After that it can ||take care of the stack config. || ||*But this will only work if the interceptor/config interleaving is done ||as outlined in previous post*. Otherwise it will be an MBean explosion... | |4 hours of sleep and I need coffee but no I think that you don't have |explosion as we now know that you can use stateless interceptor which |enables you to have ONE instance per node as well as at the beginning |mapping that the MI sees coming in, no need to go through the config |interceptor every call. | |Do you agree? | ||Which, as discussed, need to be hand-holding the MI as it travels along ||the stack. | |no as it comes in... (imnho) what you describe is how the folks at OpenAdaptor are doing it... let me know what you think of it but when I saw it I went buark. I mean the functional part I don't know about, but the system implementation was truly primitive (and pompous). One of the interceptors was a message hospital... whatever that means. I mean what kind of stateless repair can you do in a message. Maybe a replay from a debugger standpoint but I still don't see the need for a centralized point to do that. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
|Let's see if I understand this right. Do you send the list of |interceptors as part of the MI? I.e. the list contains the MI and an |index, and each interceptor just increases the index and delegates to |the next? Or how is the stack controlled? What is the driver of the |interceptor delegation? whatever... a stack of ObjectNames and in each message interceptor mbean there is a ObjectName name = message.getNextInterceptorInStack(); server.invoke(name, mi) // equivalent dynamic invocation ... whatever there are tons of ways to do that (maybe self contained in MI) but the point is that the stack is assigned when the MI is created (a gate can reconstruct a MI for EJB and set that stack). The stack maintainer is clearly an MBean and either the gates (adaptor, but I am curious to see what Andreas calls adaptor here... andreas is an adaptor an interceptor? (In the sense of OpenAdaptor then) or is it just a translator into our bus) either the gates know the router or the reverse... I don't know at this point. marcf | |/Rickard | |-- |Rickard Öberg |Software Development Specialist |xlurc - Xpedio Linköping Ubiquitous Research Center |Author of Mastering RMI |Email: [EMAIL PROTECTED] | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
marc fleury wrote:
a stack of ObjectNames and in each message interceptor mbean there is a
ObjectName name = message.getNextInterceptorInStack();
server.invoke(name, mi) // equivalent dynamic invocation
...
whatever there are tons of ways to do that (maybe self contained in MI)
Good point. I had missed the send stack along in invoke option. That
is indeed superior. Very lightweight and simple.
The stack could indeed done as:
class InterceptorStack
{
List interceptors;
int idx = 0;
InterceptorStack(List aList)
{
interceptors=aList;
}
ObjectName getNextInterceptor()
{
return (ObjectName)interceptors.get(idx++);
}
}
---
So many MI's would be sharing the same list, but with different indices
into it.
Updating the list would be to simply replace it at the gates. MI's
already in progress using the old version get to finish with that old
version.
Nice.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of Mastering RMI
Email: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Fwd: Re: [JBoss-dev] JMX service architecture: next gen++ [davidjencks@directvinternet.com]
Grr, can someone set the reply to back to the list? I sent this originally just to Rickard. I'm reposting because of the comments about mbean config: lots of people suggested the iterator by now. On 2001.10.02 10:09:01 -0400 David Jencks wrote: I'm not sure if this is the same as what you guys are suggesting: The interceptor mbeans don't need to know who they are connected to in the invocation chain. The top of the stack (connector?) does - it has an (ordered) list of the interceptors it uses. A MI coming in gets an iterator on that list from the top of the stack (connector?) When an interceptor is done is asks the iterator in the MI where to go next. A slightly more concrete implementation of this has the list at the top be a linked list, and the iterator in the MI be a pointer into this linked list. So... in terms of configuration we have: each interceptor configured separately as mbean Each interceptor stack configured as an mbean with a list of the interceptor mbeans it uses. If we do this with xml configuration, I think we now have 3 kinds of mbean attributes: plain (like we have now) mbean reference/dependency (replaces depends) list (for interceptor stacks at least) david jencks On 2001.10.02 04:00:19 -0400 Rickard Öberg wrote: marc fleury wrote: We would create the interceptors independently of each other. And then creating a stack is nothing more than instructing incoming gates (.net, rmi, whatever) that the messages requesting EJB-style fielding should go through this stack of ObjectName interceptors. standardjboss.xml needs to map one on one there. Well, the only thing the incoming gates would have to know is to immediately delegate to the stack configuration MBean. After that it can take care of the stack config. *But this will only work if the interceptor/config interleaving is done as outlined in previous post*. Otherwise it will be an MBean explosion... The stack of state machines, the movie seen by the MI, is a random access stack from the point of view of the admin. Then updating the flow means talking to that route mapper at the gates. Which, as discussed, need to be hand-holding the MI as it travels along the stack. /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
|So many MI's would be sharing the same list, but with different indices |into it. right that is even better the only state that is in the MI is the index and a (static) reference to the type of flow he will see (ejb), pretty cool rickard. |Updating the list would be to simply replace it at the gates. MI's |already in progress using the old version get to finish with that old |version. yes, once you send something in it uses that stack. Do you foresee a problem with this? Like you could have messages going in with a reference to the MBean to come up and then you can't really update the mbean... we will deal with it when we need to. We do have a centralized intelligence, the distributed JMX bus (you indirect in JMX at every point) marcf |Nice. | |/Rickard | |-- |Rickard Öberg |Software Development Specialist |xlurc - Xpedio Linköping Ubiquitous Research Center |Author of Mastering RMI |Email: [EMAIL PROTECTED] | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re: [JBoss-dev] JMX service architecture: next gen++ [davidjencks@directvinternet.com]
then you are on top of it David? go ahead kid! marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Jencks |Sent: Tuesday, October 02, 2001 11:13 AM |To: jboss-dev |Subject: Fwd: Re: [JBoss-dev] JMX service architecture: next gen++ |[[EMAIL PROTECTED]] | | |Grr, can someone set the reply to back to the list? I sent this originally |just to Rickard. I'm reposting because of the comments about mbean config: |lots of people suggested the iterator by now. | | |On 2001.10.02 10:09:01 -0400 David Jencks wrote: |I'm not sure if this is the same as what you guys are suggesting: | |The interceptor mbeans don't need to know who they are connected to in the |invocation chain. | |The top of the stack (connector?) does - it has an (ordered) list of the |interceptors it uses. | |A MI coming in gets an iterator on that list from the top of the stack |(connector?) | |When an interceptor is done is asks the iterator in the MI where to go |next. | |A slightly more concrete implementation of this has the list at the top be |a linked list, and the iterator in the MI be a pointer into this linked |list. | | |So... in terms of configuration we have: | |each interceptor configured separately as mbean | |Each interceptor stack configured as an mbean with a list of the |interceptor mbeans it uses. | |If we do this with xml configuration, I think we now have 3 kinds of mbean |attributes: | |plain (like we have now) |mbean reference/dependency (replaces depends) |list (for interceptor stacks at least) | | |david jencks | |On 2001.10.02 04:00:19 -0400 Rickard Öberg wrote: | marc fleury wrote: | | We would create the interceptors independently of each other. And then | creating a stack is nothing more than instructing incoming gates | (.net, | rmi, whatever) that the messages requesting EJB-style fielding should | go | through this stack of ObjectName interceptors. standardjboss.xml needs | to | map one on one there. | | | Well, the only thing the incoming gates would have to know is to | immediately delegate to the stack configuration MBean. After that it can | take care of the stack config. | | *But this will only work if the interceptor/config interleaving is done | as outlined in previous post*. Otherwise it will be an MBean explosion... | | | The stack of state machines, the movie seen by the MI, is a random | access | stack from the point of view of the admin. | | Then updating the flow means talking to that route mapper at the | gates. | | | Which, as discussed, need to be hand-holding the MI as it travels along | the stack. | | | /R | | | -- | Rickard Öberg | Software Development Specialist | xlurc - Xpedio Linköping Ubiquitous Research Center | Author of Mastering RMI | Email: [EMAIL PROTECTED] | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
marc fleury wrote: |So many MI's would be sharing the same list, but with different indices |into it. right that is even better the only state that is in the MI is the index and a (static) reference to the type of flow he will see (ejb), pretty cool rickard. It is indeed (and I would not want to get credit for this idea. You already said it, you just didn't know it :-). |Updating the list would be to simply replace it at the gates. MI's |already in progress using the old version get to finish with that old |version. yes, once you send something in it uses that stack. Do you foresee a problem with this? Only if the change of the stack is due to MBeans in it becoming unavailable. Then the MI's that are in progress may try to use MBeans that are no longer running. You get around this by using dependencies. If the stack mgr declares itself as depending on the interceptor MBeans, then it should get STOPPING events before the interceptors have actually stopped, and can then a) wait until any current MI's using that MBean have finished b) hold any incoming MI's wanting to use stacks with that MBean Of course that won't work if the reason for stopping the interceptor is a fatal error (i.e. no way to halt the stop procedure, even temporarily). But then you're screwed anyway. We do have a centralized intelligence, the distributed JMX bus (you indirect in JMX at every point) Yup. It will be more of an interesting configuration problem, than a programming/design problem. How do you get this to work without getting config files the size of the planet? :-) /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
What if an interceptor in the stack has a call back to a previous
interceptor that was removed as a result of the update? Maintain multiple
version of the stack until all old references complete?
- Original Message -
From: Rickard Öberg [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, October 02, 2001 3:20 PM
Subject: Re: [JBoss-dev] JMX service architecture: next gen++
marc fleury wrote:
a stack of ObjectNames and in each message interceptor mbean there is
a
ObjectName name = message.getNextInterceptorInStack();
server.invoke(name, mi) // equivalent dynamic invocation
...
whatever there are tons of ways to do that (maybe self contained in MI)
Good point. I had missed the send stack along in invoke option. That
is indeed superior. Very lightweight and simple.
The stack could indeed done as:
class InterceptorStack
{
List interceptors;
int idx = 0;
InterceptorStack(List aList)
{
interceptors=aList;
}
ObjectName getNextInterceptor()
{
return (ObjectName)interceptors.get(idx++);
}
}
---
So many MI's would be sharing the same list, but with different indices
into it.
Updating the list would be to simply replace it at the gates. MI's
already in progress using the old version get to finish with that old
version.
Nice.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of Mastering RMI
Email: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
Vinay Menon wrote: What if an interceptor in the stack has a call back to a previous interceptor that was removed as a result of the update? Maintain multiple version of the stack until all old references complete? I think the point is that you never change a stack. Only replace them. So, if an MI has a particular stack it won't change, even if the config changes. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
|It is indeed (and I would not want to get credit for this idea. You Don't want to take credit for your own ideas? my god, you are ready for the space program kid, the man in black will be coming for you soon. |already said it, you just didn't know it :-). yeah... |You get around this by using dependencies. If the stack mgr declares ok |itself as depending on the interceptor MBeans, then it should get |STOPPING events before the interceptors have actually stopped, and can then |a) wait until any current MI's using that MBean have finished |b) hold any incoming MI's wanting to use stacks with that MBean | |Of course that won't work if the reason for stopping the interceptor is |a fatal error (i.e. no way to halt the stop procedure, even |temporarily). But then you're screwed anyway. | | | We do have a centralized intelligence, the distributed JMX bus (you | indirect in JMX at every point) | | |Yup. It will be more of an interesting configuration problem, than a |programming/design problem. How do you get this to work without getting |config files the size of the planet? :-) one thing at a time kiddo, one thing at a time. marcf | |/R | |-- |Rickard Öberg |Software Development Specialist |xlurc - Xpedio Linköping Ubiquitous Research Center |Author of Mastering RMI |Email: [EMAIL PROTECTED] | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMX service architecture: next gen++
On 2001.10.02 11:18:00 -0400 Rickard Öberg wrote: marc fleury wrote: |So many MI's would be sharing the same list, but with different indices |into it. right that is even better the only state that is in the MI is the index and a (static) reference to the type of flow he will see (ejb), pretty cool rickard. It is indeed (and I would not want to get credit for this idea. You already said it, you just didn't know it :-). |Updating the list would be to simply replace it at the gates. MI's |already in progress using the old version get to finish with that old |version. yes, once you send something in it uses that stack. Do you foresee a problem with this? Only if the change of the stack is due to MBeans in it becoming unavailable. Then the MI's that are in progress may try to use MBeans that are no longer running. You get around this by using dependencies. If the stack mgr declares itself as depending on the interceptor MBeans, then it should get STOPPING events before the interceptors have actually stopped, and can then a) wait until any current MI's using that MBean have finished b) hold any incoming MI's wanting to use stacks with that MBean Of course that won't work if the reason for stopping the interceptor is a fatal error (i.e. no way to halt the stop procedure, even temporarily). But then you're screwed anyway. I would like this best if the jmx server state were transactional with versioning optimistic concurrency control, like the firebird/interbase db. In this kind of scheme, an invocation to a mbean would get a jmx transactional view of all the mbeans in the jmx server as of the start of the invocation. The view of mbeans would be stable until the invocation finishes. Other concurrent changes to mbean state would use copy on write semantics and be visible (after they were committed) to jmx transactions started after the commit of the jmx modifications. After all uses of a replaced mbean were complete the (now inacessible) old version of the mbean can be garbage collected. Presumably one could also set up externally controlled jmx transactions so several configuration changes could occur atomically within one transaction. I guess I will have to read more of the mbean spec to see if this is consistent with it ;-) Optimistic/versioning or not, I think some kind of jmx transaction to make configuration invisible until it all completes will be necessary to make on the fly reconfiguration plausible and not too disruptive. We do have a centralized intelligence, the distributed JMX bus (you indirect in JMX at every point) Yup. It will be more of an interesting configuration problem, than a programming/design problem. How do you get this to work without getting config files the size of the planet? :-) How is this much worse than we have now? Now we have standardjboss.xml with a list of interceptors: then we will have this configuration in a endpoint mbean as a list of mbean references, and also mbean configuration for each interceptor individually. david jencks /R -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
|I would like this best if the jmx server state were transactional with |versioning optimistic concurrency control, like the firebird/interbase db. |In this kind of scheme, an invocation to a mbean would get a jmx |transactional view of all the mbeans in the jmx server as of the start of |the invocation. The view of mbeans would be stable until the invocation |finishes. Other concurrent changes to mbean state would use copy on |write semantics and be visible (after they were committed) to jmx |transactions started after the commit of the jmx modifications. After all |uses of a replaced mbean were complete the (now inacessible) old version of |the mbean can be garbage collected. Presumably one could also set up |externally controlled jmx transactions so several configuration changes |could occur atomically within one transaction. I guess I will have to read |more of the mbean spec to see if this is consistent with it ;-) | |Optimistic/versioning or not, I think some kind of jmx transaction to make |configuration invisible until it all completes will be necessary to make on |the fly reconfiguration plausible and not too disruptive. oh no... another one goes pop! kid, what are you talking about? please expand, does someone understand this? marcf | | | | We do have a centralized intelligence, the distributed JMX bus (you | indirect in JMX at every point) | | | Yup. It will be more of an interesting configuration problem, than a | programming/design problem. How do you get this to work without getting | config files the size of the planet? :-) | |How is this much worse than we have now? Now we have standardjboss.xml |with a list of interceptors: then we will have this configuration in a |endpoint mbean as a list of mbean references, and also mbean |configuration for each interceptor individually. | |david jencks | | /R | | -- | Rickard Öberg | Software Development Specialist | xlurc - Xpedio Linköping Ubiquitous Research Center | Author of Mastering RMI | Email: [EMAIL PROTECTED] | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
Definitely a much simpler idea to just build the new stack and replace the old one atomically than to try and build a database for the MBeans. Cheers -Original Message- From: Rickard Öberg To: [EMAIL PROTECTED] Sent: 10/2/01 12:33 PM Subject: Re: [JBoss-dev] JMX service architecture: next gen++ David Jencks wrote: I would like this best if the jmx server state were transactional with versioning optimistic concurrency control, like the firebird/interbase db. In this kind of scheme, an invocation to a mbean would get a jmx transactional view of all the mbeans in the jmx server as of the start of the invocation. The view of mbeans would be stable until the invocation finishes. Other concurrent changes to mbean state would use copy on write semantics and be visible (after they were committed) to jmx transactions started after the commit of the jmx modifications. After all uses of a replaced mbean were complete the (now inacessible) old version of the mbean can be garbage collected. Presumably one could also set up externally controlled jmx transactions so several configuration changes could occur atomically within one transaction. I guess I will have to read more of the mbean spec to see if this is consistent with it ;-) This is doable, but the overhead of it would be enormous... I think sticking with immutable interceptor stacks is good enough to start with :-) Optimistic/versioning or not, I think some kind of jmx transaction to make configuration invisible until it all completes will be necessary to make on the fly reconfiguration plausible and not too disruptive. Not necessarily. All you need to do is have duplicate MBeans and then switch from one set to the other in one atomic operation. Still, this is really tricky to get right. How is this much worse than we have now? Now we have standardjboss.xml with a list of interceptors: then we will have this configuration in a endpoint mbean as a list of mbean references, and also mbean configuration for each interceptor individually. You may be right. It could be ok. /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX service architecture: next gen++
|momentary service disruptions. Also, you don't want half-completed |configuration changes to start getting used - you want them to finish |first. I'm just saying this point of view on requirements (if they are Yes, the transactional nature of the distributed administration operation might be real.. I don't know. |indeed desirable, I don't really know) is satisfied really well by the |versioning transaction model of firebird/interbase: transactions get |numbered as they come in, so you can tell from the log what order they |happened in, and configuration changes are invisible to all transactions |(invocations) that start before the configuration change commits, whereas |those after the commit use the new configuration. Conceptually this seems What is the problem with numbering the result of the operation. I.e. there is a state that exists in the MBeans after the invocation and for making the store() backed by an EJB we will buy you the transactional XA registration of the database connection that stores that configuration. Building an history in the database based on the state is disconnected from the incoming invocations. Are you saying the incoming invocations should be recorded? Do you know how big this will get? will you always get the tools to replay this scenario? I would rather work with state in MBean and possibly both if we want to be rich (store the invocation with the modification ... p) clearly heavy and applicable to management operations only. |cleaner to me than the valves you were talking about to stop MIs during |reconfiguration. Only it doesn't really apply to the same stuff or does it? One is storing the state of the MBean in the database (it's configuration) with many other MBean nodes so you update your machine at once but what does it have to do with stopping the threads coming in? marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Fwd: Re: [JBoss-dev] JMX service architecture: next gen++ [davidjencks@directvinternet.com]
(Maybe this time I will get this to the list-third try is the charm?) On 2001.10.02 15:07:05 -0400 David Jencks wrote: (forwarding to list, hope this is ok with you) This is exactly what I was thinking, and what the firebird-style versioning does for you. I am not suggesting storing much of anything in a persistent db, I haven't thought about that yet: what I am talking about is how to make the configuration changes transactional/atomic and allow pre-completion invocations complete with the old versions, whereas post completion invocations use the new versions. I think this is not that hard to do with firebird as a model, maybe adding the version id into the mbean object name. Needs some more thought. Some of this can be taken care of by copy on write invocation lists, but I'm not sure all of it can. Thanks david jencks On 2001.10.02 14:45:05 -0400 Ole Husgaard wrote: Hi, I've been speculating about this in the context of bean redeployment. Just creating a new configuration (or deployment) and atomically switching over to it is not really enough: Old transactions that have used the old configuration (or deployment) should continue to use that, so the old configuration (or deployment) has to be kept until all transactions that have ever used it have terminated. But to avoid service disruption, calls in the context of new transactions that have not used the old configuration should be using the new configuration at the same time as some old transactions still use the old configuration. I agree that this can become very hairy. Best Regards, Ole Husgaard. David Jencks wrote: Don't panic marc, even I don't plan to implement this this week ;-) Here's the context I'm thinking about, and please note IANASA (I am not a system administrator)... but if I were running the jboss cluster at Megacorp Conglomerates, I expect my audit trail requirements would include knowing exactly what configuration was used to process each online b2b soap enabled etc purchase order, yet allow on the fly hot updates to avoid even momentary service disruptions. Also, you don't want half-completed configuration changes to start getting used - you want them to finish first. I'm just saying this point of view on requirements (if they are indeed desirable, I don't really know) is satisfied really well by the versioning transaction model of firebird/interbase: transactions get numbered as they come in, so you can tell from the log what order they happened in, and configuration changes are invisible to all transactions (invocations) that start before the configuration change commits, whereas those after the commit use the new configuration. Conceptually this seems cleaner to me than the valves you were talking about to stop MIs during reconfiguration. As Rickard says, this might have a lot of overhead, and at least some of the properties of this system will come from careful use of copy on write. [snip] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Re: [JBoss-dev] JMX service architecture: next gen++ [davidje ncks@directvinternet.com]
The other reason I like the database approach (aside from liking its elegance) is that it provides a way to tell when you can throw out the old version of the mbeans: when all invocations [jmx transactions] numbered less than the transaction active when the change committed are complete. Without something like this I'm not sure how to tell when its ok to deregister the old set of mbeans: they're in the mbean server, so they won't just be garbage collected when all the references are gone. Maybe reference counting... but this may be hard to get right. david jencks On 2001.10.02 21:26:49 -0400 Jay Walters wrote: If you use copy on write of the MBeans (and on the list of MBeans - the stack) then you can probably do everything needed. Of course this raises questions about what is the impact of multiple versions of a specific MBean is, but these are supposed to be stateless interceptor-like MBeans right, so it's not like you're making a new connection pool. I would think a simple copy on write approach would be the quickest to write, but it needs to be wrapped up so the code adding the new MBean doesn't have to remember to do the copy - it just happens. I imagine this is why the model of a database that just does it, is appealing. Cheers -Original Message- From: David Jencks To: jboss-dev Sent: 10/2/01 6:38 PM Subject: Fwd: Re: [JBoss-dev] JMX service architecture: next gen++ [[EMAIL PROTECTED]] (Maybe this time I will get this to the list-third try is the charm?) On 2001.10.02 15:07:05 -0400 David Jencks wrote: (forwarding to list, hope this is ok with you) This is exactly what I was thinking, and what the firebird-style versioning does for you. I am not suggesting storing much of anything in a persistent db, I haven't thought about that yet: what I am talking about is how to make the configuration changes transactional/atomic and allow pre-completion invocations complete with the old versions, whereas post completion invocations use the new versions. I think this is not that hard to do with firebird as a model, maybe adding the version id into the mbean object name. Needs some more thought. Some of this can be taken care of by copy on write invocation lists, but I'm not sure all of it can. Thanks david jencks On 2001.10.02 14:45:05 -0400 Ole Husgaard wrote: Hi, I've been speculating about this in the context of bean redeployment. Just creating a new configuration (or deployment) and atomically switching over to it is not really enough: Old transactions that have used the old configuration (or deployment) should continue to use that, so the old configuration (or deployment) has to be kept until all transactions that have ever used it have terminated. But to avoid service disruption, calls in the context of new transactions that have not used the old configuration should be using the new configuration at the same time as some old transactions still use the old configuration. I agree that this can become very hairy. Best Regards, Ole Husgaard. David Jencks wrote: Don't panic marc, even I don't plan to implement this this week ;-) Here's the context I'm thinking about, and please note IANASA (I am not a system administrator)... but if I were running the jboss cluster at Megacorp Conglomerates, I expect my audit trail requirements would include knowing exactly what configuration was used to process each online b2b soap enabled etc purchase order, yet allow on the fly hot updates to avoid even momentary service disruptions. Also, you don't want half-completed configuration changes to start getting used - you want them to finish first. I'm just saying this point of view on requirements (if they are indeed desirable, I don't really know) is satisfied really well by the versioning transaction model of firebird/interbase: transactions get numbered as they come in, so you can tell from the log what order they happened in, and configuration changes are invisible to all transactions (invocations) that start before the configuration change commits, whereas those after the commit use the new configuration. Conceptually this seems cleaner to me than the valves you were talking about to stop MIs during reconfiguration. As Rickard says, this might have a lot of overhead, and at least some of the properties of this system will come from careful use of copy on write. [snip] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL
Re: [JBoss-dev] JMX service architecture: next gen++
|Implementation model | |Let's start with the basics. The JMX MBeans in JBoss are all based upon |the Standard MBean model. This has worked well, and is especially a very |lightweight and simple way to make components manageable. The downside |is that you can't add very interesting metadata and custom call |interception (such as per component security checks) without going I agree with the first one not the second one... but that is a minor point. You just mean that invoke() is a more natural way to String together detyped services but you could argue that for the price of putting the Dynamic Proxies right behind the standard MBean interface you can generate the same invoke() call and thus string a stack behind it. You can only do that if you are in control over the MBean instantiation and registration. If you want to make generic MBeans that do not depend on the JBoss infrastructure this does not hold. It is not very standard-ish. |through hoops. I've decided to use a different model that uses all three |types of MBeans, but which makes use of the benefits of all while still |being easy to use. uh oh... sounds like an excercise de style hmmm let's see if I can use all of the beans of the specification It just means that all three models have pros and cons, and the cons of each model is being fixed by one or a combination of the other two. I didn't start out with let's see if I can use all three models, humdidum. So the DynamicMBean implements the invoke() interface and the invoke() interface is then delegated to an instance of RMM which has instances of a class provided by the programmer. Correct. The mapping of the invoke() to the POJO... is a bit obscure at this point. This is done by the Model MBean. That is one of the big points of Model MBeans. To map invoke()'s to POJO's. Read the spec please. |Note that the POJO case in this model does not have to know *anything* |about JMX. All of the JMX-ery can be dealt with by the ServiceSupport |subclass. Anyway, so this makes use of all three models and retains the Instrumenting without JMX knowledge is good but if that is the goal (which I doubt) One of the goals is indeed to make the MBeans, or services, as JMX-ignorant as possible in order to make them easy to write and also to make things about managing the MBean as reusable as possible. then there are other easier ways to achieve this (see upcoming Juha's Book ;-) by extending even the *binary* itself. What do you mean by extending the binary? |* The easy-to-use mapping between dynamic calls and reflection |invocations on the service object of ModelMBean's. That I don't see What is obscure? Mapping dynamic calls to reflective invokes is the most important task of the Model MBean model. |* The easy-to-implement style of Standard MBeans. sure. Listen kid, using all the features of the spec is pretty cool, but is it really necessary. No, nothing is necessary. But doing it makes it as easy to use as possible. |* Need to map dynamic invokes of Dynamic MBean to reflective calls - |solved by ModelMBean model I see so the MM calls his POJO by reflection and you build the adaptor in there. The MM *is* the adaptor. Do you know what ModelMBeans are about at all?? |* Need to implement dynamic invokes of Dynamic MBean - solved by |Standard MBeans in conjunction with ModelMBeans model dynamic invokes of Dynamic MBean ;-) huh you are going to have to explain that one Rickard it sounds kind of silly as I read it. If the MBean that is registered in the MBeanServer is a DynamicMBean you will be getting invoke() calls from the server. What do you do with that? Simple: delegate to a Model MBean instance that converts that invoke() to a reflective call on the Standard MBean that contains the actual implementation. It is really really basic stuff here Marc |Configuration |= |The way configuration works in this scheme is a little different from |how it works in JBoss. In JBoss the Configuration MBean is pretty much |dictatorial in that all MBeans must be configured through it. This is |not how the JMX spec intended it to work. The Persistent MBean interface |is there so that load() and store() can be called, and *if* the MBean Does that remind you of anything? come on... What are you referring to here? I've browsed through the new ServiceController/ServiceConfigurator stuff, and it still seems to be the way it used to be, i.e. it mandates that MBeans are configured through the XML mechanism. Am I missing something? Is JBoss indeed calling PersistentMBean.load/store somewhere? I couldn't see it anyway... |wants to it can ask a central Configuration MBean, but it can also do |whatever config reading it wants instead or additionally. The |configuration MBean in my implementation still reads services.xml files |and creates beans, but then it only calls load() which allow the MBean Not exactly. The load() store() is there to allow the component itself to
RE: [JBoss-dev] JMX service architecture: next gen++
|You just mean that invoke() is a more natural way to String together |detyped services but you could argue that for the price of putting the |Dynamic Proxies right behind the standard MBean interface you can generate |the same invoke() call and thus string a stack behind it. | |You can only do that if you are in control over the MBean instantiation and |registration. If you want to make generic MBeans that do not depend on the |JBoss infrastructure this does not hold. It is not very standard-ish. Either that or you control the JMX infrastructure, a JMX server that includes the externalization of stacks of JBoss would do just that. | then there are other easier ways to achieve this (see upcoming Juha's |Book ;-) by extending even the *binary* itself. | |What do you mean by extending the binary? read the book |Sure, that could work. Still, I don't see in current JBoss 3 code |where this |is left to the individual MBean to decide. It seems like JBoss mandates the |configuration to come through the SAR stuff. The stuff that does that is the XMBeans of Juha's upcoming book. |It seems like what I have done is very similar to what he has done |(based on |his descriptions anyway). Which makes it kind of interesting why you're |dizzing what I'm saying, since you're on the other hand praising the very |same approach. I never did understand you dude... well relax... I am not dizzying you. I am praising the load and store in both approaches. The important thing is the beans dealing with their configuration semantics. I was critizing the rest of the praise, in my mind the real pro here is the localized semantics. |If an MBean has unresolved dependencies it is not allowed to start. If it sure |wants to be able to start without a dependency having been resolved it can |mark it as not-required in the XML configuration. If an MBean is do you hold a bean until you get an event in case you don't have the bean yet? |started and a required dependency becomes unavailable it will stop, unless it can find |another MBean matching the same ObjectName-pattern (this is the poor mans |failover part). hmmm interesting is this during run-time? so how does this work you recieve an event and you stop the mbean and you control the reference inside the object (must be exposed) and you set it to the new MBean name... the reference of inter-bean is what? this is not clear. Do you call the bean directly do you call the server? You are talking about stateless stuff here obviously. |Remember that in RH we want to disconnect the invokers from the target |beans. |snip | |My proposal has absolutely nothing to do with EJB, if that's what you're |referring to with beans, so I fail to see why you discuss that here. What I describe has nothing to do with EJB. Reread it. |24x7 of the actual calls. If I understand correctly the way JINI |works, if |the service goes down we then remove the service from the invokable ones |and essentially you don't call us anymore. | |Correct, and this can be done on the client side so it can fail over to |another implementor of the required dependency. Yes but that is inferior to rerouting on the server. Reread my mail. |On the server side, yes, but that is worse because then the client is never |given the option of using another provider of the service. You are That is not correct. The client knows about different JMX node invokers. |Why do you have to rewrite the JMX server? Anything that makes use of more |than the JMX spec is essentially proprietary and pointless (IMHO anyway). |You're not doing JMX then anymore, but is more based on than compliant |with. think... we add interceptors in JBoss (EJB) with the JBoss infrastructure that takes the jboss.xml. The creation of the stack of interceptor is done by JBoss and we don't touch the EJB spec. In a likewise manner, adding interceptors to invoke() MBeans can be done by the JBoss infrastructure at the JMX server level (the JMX server would be JBoss in this case). Either you do it there or you do it in the bean, either way you need a way to describe the stack of interceptor to the bean (that would create it) or to the JBoss-like deployer. (of MBeans in this case rickard not ejb) |In that picture, JINI becomes a watchdog, something that keeps on |monitoring the state of the beans, whether up or down and |register/deregister in their behalf... that is nice plumbing and I wonder |is |that is not the real use of JINI in our framework. | |Only if you do it on the client side. As above, if you do this stuff on the |server side only it becomes kind of limited, at least for inter-server |MBean2MBean invocations, which is what I was aiming at. I am not following you. You keep talking about clients on the web with RMI references to JINI and a star of connections from n clients to n services... with RMI... on the web... you crazy? I believe that monitoring the state of the mbeans in the nodes (multi node even, but squarely server side) is
Re: [JBoss-dev] JMX service architecture: next gen++
|You just mean that invoke() is a more natural way to String together |detyped services but you could argue that for the price of putting the |Dynamic Proxies right behind the standard MBean interface you can generate |the same invoke() call and thus string a stack behind it. | |You can only do that if you are in control over the MBean instantiation and |registration. If you want to make generic MBeans that do not depend on the |JBoss infrastructure this does not hold. It is not very standard-ish. Either that or you control the JMX infrastructure, a JMX server that includes the externalization of stacks of JBoss would do just that. That's true. So, you want to replace the RI then? | then there are other easier ways to achieve this (see upcoming Juha's |Book ;-) by extending even the *binary* itself. | |What do you mean by extending the binary? read the book Ah, ok. Very informative answer. Does this mean there's no one-liner reply, that you don't think it's worth the effort to answer properly, or that you don't know? |Sure, that could work. Still, I don't see in current JBoss 3 code |where this |is left to the individual MBean to decide. It seems like JBoss mandates the |configuration to come through the SAR stuff. The stuff that does that is the XMBeans of Juha's upcoming book. .. which is similar to what I have described, right? |It seems like what I have done is very similar to what he has done |(based on |his descriptions anyway). Which makes it kind of interesting why you're |dizzing what I'm saying, since you're on the other hand praising the very |same approach. I never did understand you dude... well relax... I am not dizzying you. I am praising the load and store in both approaches. The important thing is the beans dealing with their configuration semantics. Which is not how JBoss 2/3 works today. I was critizing the rest of the praise, in my mind the real pro here is the localized semantics. Yes, that MBeans can deal with their own configuration semantics. Right? *Which is what I said*geeezz... |wants to be able to start without a dependency having been resolved it can |mark it as not-required in the XML configuration. If an MBean is do you hold a bean until you get an event in case you don't have the bean yet? Not quite sure what you're asking about. Example: MBean A has a not-required dependency on MBean B, which is coupled to the attribute b. A can start without B being available or started, i.e. calling getB on A can yield null. When B is started the dependency is resolved, and setB is called with a proxy to B as argument. A may then use B. This means that A has to check whether B is set or not before it tries to use it. This is the semantics of not-required dependencies. |started and a required dependency becomes unavailable it will stop, unless it can find |another MBean matching the same ObjectName-pattern (this is the poor mans |failover part). hmmm interesting is this during run-time? Of course. so how does this work you recieve an event e.g. MBean A receives the event MBean B state is now STOPPING, i.e. B is becoming unavailable for A to use. and you stop the mbean e.g. A is stopped due to a dependency to B is becoming unresolved. and you control the reference inside the object (must be exposed) and you set it to the new MBean name... the reference of inter-bean is what? this is not clear. Do you call the bean directly do you call the server? You are talking about stateless stuff here obviously. These sentences make no sense to me. I have no idea what you're asking about. Can you be more specific. An example perhaps? Yes but that is inferior to rerouting on the server. Reread my mail. In my case the client is another server, i.e. I'm referring to MBean2MBean communication where the MBeans can reside on different servers. How is it inferior? |On the server side, yes, but that is worse because then the client is never |given the option of using another provider of the service. You are That is not correct. The client knows about different JMX node invokers. But you are then assuming that the client has to know about the concept of invokers in the first place. In my scenario the client MBeans only sees other MBeans and does not have to know about the underlying stuff, which could indeed be based on what you describe. Either you do it there or you do it in the bean, either way you need a way to describe the stack of interceptor to the bean (that would create it) or to the JBoss-like deployer. Correct. And if you do it in the server the MBeans that makes use of it are tied to the JBoss server, i.e. they are not portable to other servers. By placing the logic in the MBeans instead, i.e. in between the invoke() and the actual call handling, the MBeans become more self-contained. I prefer self-contained, unless there is a big win with putting it in the server itself. I am not following you. You keep talking about clients on the web with RMI
RE: [JBoss-dev] JMX service architecture: next gen++
|Either that or you control the JMX infrastructure, a JMX server that |includes the externalization of stacks of JBoss would do just that. | |That's true. So, you want to replace the RI then? Well the more I think about what we are doing and the more I see the future of the webOS starting with the management of modules invocation stacks that are put in it. This is the magic of the detyped invocation chains it allows for arbitrary stacks of interceptors, even dynamically arbitrary. There is replication of them across nodes (with full URL as in RH (what reads it is the XMBean domain)) and clustering and distribution at that layer. Reading your stuff I realize we are talking about the same invoke() stuff that we plan on putting in the new RH invocation chain of beans. From the JMX standpoint the target beans are irrelevant, whether they be ejb or mdb or what have you as long as they all present an MBean invoke() face they are candidates for meta-programmation in stacks in front of them. Then the question of the stack of interceptors becomes interesting. Metaprogrammation is interesting in many aspects the simplest ones at this point being the transaction and security but really any interceptor that we can plug in there (monitoring perf is another that comes to mind). Where we manage these interceptors and how we do it is definitely at the JBoss infrastructure level and it could very well be at the JMX layer in between bus invocations. You talk about management invocations in your mails, I talk about ANY invocation in the target beans (including EJB) |that you don't think it's worth the effort to answer properly, or that you |don't know? Both, I think reading the book is the best, juha has made just amazing progress in his understanding of the JMX specs and its usage. As you saw in his email response I think he might even be one step ahead of you there, well he has been thinking and writing for 4 mo. |The stuff that does that is the XMBeans of Juha's upcoming book. | |.. which is similar to what I have described, right? yes, the XMBeans is similar to what you describe, take a look at the persistence and what we will plug in the persistence is interesting. |well relax... I am not dizzying you. I am praising the load and store in |both approaches. The important thing is the beans dealing with their |configuration semantics. | |Which is not how JBoss 2/3 works today. I know, the first place juha talked about it was in relation with the Jetty request for esoteric configuration and storing of it. We discussed (he presented) the XMBeans in London and his interesting idea was putting an EJB behind the load store semantic. The reason is that you have free clustering of the configuration, this is very powerful. |Yes, that MBeans can deal with their own configuration semantics. Right? |*Which is what I said*geeezz... Well I will be direct, you said a lot of things, including that it will eradicate war. The fact that they can deal with their configuration is the important thing at this point. |In my case the client is another server, i.e. I'm referring to MBean2MBean |communication where the MBeans can reside on different servers. How is it |inferior? ok client is another server, that is better, still not optimal if all the beans are individually talking about their state but at least not in the crazy category. |Either you do it there or you do it in the bean, either way you need a way |to describe the stack of interceptor to the bean (that would create it) or |to the JBoss-like deployer. | |Correct. And if you do it in the server the MBeans that makes use of it are |tied to the JBoss server, i.e. they are not portable to other servers. By That is correct, portability of the invoke() is lost, but doesn't preclude you using the inside bean version as well. You don't really lose something and you gain standard configuration of stacks. And in fact the interesting part is that you offer people a way to generically describe externalized stacks of interceptors. That is truly powerful. If you don't do that, the client has to come up with something that essentially DOES EXACTLY THE SAME THING. The thing that is even more JUICE in there is that you now have a way to manage the stacks through the server *and dynamically*. For example imagine you want to add a metadata interceptor to a given bean. The thing that is interesting is that you can for example add a valve interceptor that gets in the chain somewhere (say beginning) and freezes the invocations and then you can put a new interceptor that does advanced security and defreeze the invocation and *remove* the interceptor. All through the servers infrastructure. Dynamic scripting of invocation flows in 24.7 meshes is the key to it all (jboss.net) imho. Maybe one thing that is missing in the descriptions is that I view the invoke() of the beans not only as administration operations but really for ALL operations invoked in components residing
Re: [JBoss-dev] JMX service architecture: next gen++
marc fleury wrote: Well the more I think about what we are doing and the more I see the future of the webOS starting with the management of modules invocation stacks that are put in it. This is the magic of the detyped invocation chains it allows for arbitrary stacks of interceptors, even dynamically arbitrary. There is replication of them across nodes (with full URL as in RH (what reads it is the XMBean domain)) and clustering and distribution at that layer. True. Reading your stuff I realize we are talking about the same invoke() stuff that we plan on putting in the new RH invocation chain of beans. From the JMX standpoint the target beans are irrelevant, whether they be ejb or mdb or what have you as long as they all present an MBean invoke() face they are candidates for meta-programmation in stacks in front of them. Yes, if the EJB's are exposed as MBeans it is more of a special case than anything else. (And not so special anyway, which is the whole point) Then the question of the stack of interceptors becomes interesting. Metaprogrammation is interesting in many aspects the simplest ones at this point being the transaction and security but really any interceptor that we can plug in there (monitoring perf is another that comes to mind). Where we manage these interceptors and how we do it is definitely at the JBoss infrastructure level and it could very well be at the JMX layer in between bus invocations. It should be doable as MBeans, i.e. no real need to change the bus. The interceptor stack map fairly well to JMX Adaptors. You talk about management invocations in your mails, I talk about ANY invocation in the target beans (including EJB) Correct, there's no need to make a distinction if you put the EJB's on the JMX bus. |that you don't think it's worth the effort to answer properly, or that you |don't know? Both, I think reading the book is the best, juha has made just amazing progress in his understanding of the JMX specs and its usage. As you saw in his email response I think he might even be one step ahead of you there, well he has been thinking and writing for 4 mo. Yup, he's got it covered, that I gathered :-) If he's one step ahead of me, well that remains to be seen ;-) (who cares anyway..) |well relax... I am not dizzying you. I am praising the load and store in |both approaches. The important thing is the beans dealing with their |configuration semantics. | |Which is not how JBoss 2/3 works today. I know, the first place juha talked about it was in relation with the Jetty request for esoteric configuration and storing of it. We discussed (he presented) the XMBeans in London and his interesting idea was putting an EJB behind the load store semantic. The reason is that you have free clustering of the configuration, this is very powerful. Good point. |In my case the client is another server, i.e. I'm referring to MBean2MBean |communication where the MBeans can reside on different servers. How is it |inferior? ok client is another server, that is better, still not optimal if all the beans are individually talking about their state but at least not in the crazy category. There are a couple of important points to lessen the crazy aspect: 1) There will not be nxn connections where n is number of services. The *worst* case will be sxs connections where s is the *number of servers*. RMI connections can be shared by MBeans in the same server. 2) I seriously doubt that any given system will be a complete graph, i.e. that all servers will use all others. In practice there will probably be layers of servers, or clusters of servers where each server within a cluster will not use servers in the same cluster, only servers in other clusters. |Either you do it there or you do it in the bean, either way you need a way |to describe the stack of interceptor to the bean (that would create it) or |to the JBoss-like deployer. | |Correct. And if you do it in the server the MBeans that makes use of it are |tied to the JBoss server, i.e. they are not portable to other servers. By That is correct, portability of the invoke() is lost, but doesn't preclude you using the inside bean version as well. You don't really lose something and you gain standard configuration of stacks. And in fact the interesting part is that you offer people a way to generically describe externalized stacks of interceptors. That is truly powerful. If you don't do that, the client has to come up with something that essentially DOES EXACTLY THE SAME THING. No, all you need to do is place this configuration of stacks in an MBean, just like you do today (in what used to be ConfigurationMBean. Is it the ServiceConfigurator or ServiceDeployer now? anyway..). Think JMX Adaptors. But you do have a point in that it might be the case that configuring the stacks can be done *more efficiently* if done inside the server. Maybe, maybe not. The
