RE: [JBoss-dev] Why is new ObjectName() so slow?
2 solutions. 1- I build a mapper that takes String and returns ObjectName 2- you build a ObjectName implementation that caches the ObjectName and returns the right Object if you pass me exactly the same String. OK, but it must be a requirement that this mapping be deterministic i.e. when you bind a bean (= container = mbean) in a JBoss instance, we will use your cache MBEAN with a key that is a simple string. But this key must be identical for all deployments of the same bean because our clustered proxy will use the same key while making invocation on any nodes. Just to be sure you don't use some kind of counter as the key you give back to the proxy. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why is new ObjectName() so slow?
because an object name contains a set of properties that need to be parsed and may also be a pattern which needs to be determined the current implementation does this eagerly at object name creation time -- Juha On Sun, 28 Apr 2002, marc fleury wrote: ok, I know I asked already and I can't remember the reason why creating an ObjectName should be S slow. Can one of the JMX gurus enlighten me and explain the reason. (yes again sorry) last I remembered the new ObjectName would take half the time of the invocation (!). If that is still the case then it is going to invalidate a lot of the thinking around the ObjectName MBean client proxy stuff which is quite powerful. But it is software and software is fixable so I can't imagine that there is a real life reason for this to be so slow. marcf x Marc Fleury, Ph.D President JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Juha Lindfors Author of JMX: Managing J2EE with Java Management Extensions Senior Developer, JBoss Group LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
|because an object name contains a set of properties that need to be |parsed and may also be a pattern which needs to be determined right the value=name pairs |the current implementation does this eagerly at object name creation |time can we do this lazily? can't we build equality and hash on the FULL string? it strikes that the eager parsing is silly (eats up 50% of the time !!!) and only really useful in querying? Can you think of optimizations? It would really be appreciated as it would enable Bill's dream of the CORBA world really working in our JBoss implementation, the fast ON lookup and bla bla bla . Let me know if you can optimize it, please spend at least 10min thinking about it. Otherwise it sort of makes the invokers sort of useless at the JMX level. Any optimization DEEPLY appreciated, this is deep. And you are the man. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why is new ObjectName() so slow?
Juha, Using a set of properties to identify an object just seems werid to me. WHY did the JMX spec do this??? Why not just use a unique string to identify an object??? Yes, I see one reasone, so you can do querys and lookup objects based on properties, buy you could still do that without making the properties part of the identifier. Do you know what I mean?? Regards, Hiram From: Juha-P Lindfors [EMAIL PROTECTED] To: marc fleury [EMAIL PROTECTED] CC: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Why is new ObjectName() so slow? Date: Sun, 28 Apr 2002 21:39:26 +0300 (EET DST) because an object name contains a set of properties that need to be parsed and may also be a pattern which needs to be determined the current implementation does this eagerly at object name creation time -- Juha On Sun, 28 Apr 2002, marc fleury wrote: ok, I know I asked already and I can't remember the reason why creating an ObjectName should be S slow. Can one of the JMX gurus enlighten me and explain the reason. (yes again sorry) last I remembered the new ObjectName would take half the time of the invocation (!). If that is still the case then it is going to invalidate a lot of the thinking around the ObjectName MBean client proxy stuff which is quite powerful. But it is software and software is fixable so I can't imagine that there is a real life reason for this to be so slow. marcf x Marc Fleury, Ph.D President JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Juha Lindfors Author of JMX: Managing J2EE with Java Management Extensions Senior Developer, JBoss Group LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
On Sun, 28 Apr 2002, marc fleury wrote: |because an object name contains a set of properties that need to be |parsed and may also be a pattern which needs to be determined right the value=name pairs Which in a string passed to a constructor are not guaranteed to be canonical or well formed. |the current implementation does this eagerly at object name creation |time can we do this lazily? can't we build equality and hash on the FULL string? No. ObjectNames are immutable - the only time you have an opportunity to throw malformed exceptions is at construction time. it strikes that the eager parsing is silly (eats up 50% of the time !!!) and only really useful in querying? Can you think of optimizations? 50% of *what* time exactly? How many times are you creating the ObjectName instance? Is it (de)serialisation that's causing you the problem? If so, see below. It would really be appreciated as it would enable Bill's dream of the CORBA world really working in our JBoss implementation, the fast ON lookup and bla bla bla . Let me know if you can optimize it, please spend at least 10min thinking about it. Otherwise it sort of makes the invokers sort of useless at the JMX level. Any optimization DEEPLY appreciated, this is deep. And you are the man. Ok, the only laziness that we can insert while still being compliant is on deserialization. Beyond that, consider not using ObjectNames in your invocation layer - they are great big pigs designed to do too much. Trevor ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
From: marc fleury [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Why is new ObjectName() so slow? Date: Sun, 28 Apr 2002 11:49:46 -0700 |because an object name contains a set of properties that need to be |parsed and may also be a pattern which needs to be determined right the value=name pairs |the current implementation does this eagerly at object name creation |time can we do this lazily? can't we build equality and hash on the FULL string? it strikes that the eager parsing is silly (eats up 50% of the time !!!) and only really useful in querying? Can you think of optimizations? I've go a feeling that the order of the properties does not matter, so DefaultDomain:service=XADataSource,name=DefaultDS would be the same object as DefaultDomain:name=DefaultDS,service=XADataSource. I think that's whey he has to parse it early. Regards, Hiram _ Chat with friends online, try MSN Messenger: http://messenger.msn.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
On Sun, 28 Apr 2002, marc fleury wrote: |because an object name contains a set of properties that need to be |parsed and may also be a pattern which needs to be determined right the value=name pairs |the current implementation does this eagerly at object name creation |time can we do this lazily? can't we build equality and hash on the FULL string? no, we need a canonical presentation for equality check (because the name is a set of properties, not just an array of characters.. we need to sort the properties before we can check for equality) it strikes that the eager parsing is silly (eats up 50% of the time !!!) and only really useful in querying? Can you think of optimizations? the optimizations that we can do inside ObjectName would only include possibly optimizations to Java's string handling, maybe replacing generic collections with type specific ones, and avoiding Collections.sort() (I don't know how it is implemented or how well it performs). However, the problem with even these optimizations is that Sun plans to push JMX as part of JDK from the next 1.5 version on. They however have no plans to publish an SPI which means whatever is inside javax.management packages will from the next version on be Sun's implementation. And as you and I well know, Sun's implementation isn't exactly performing or industrial strength. The question at the moment is, why do you need to create an object name per invocation? Is it possible to cache the object names by mapping them to *real* identifies as opposed to this property nonsense? (how many MBean's do you imagine having in your server, could you create the object names for them on the server side and lookup the same instances from a cache -- I know it sounds ass backwards but given then future plans on JMX it would be best to avoid too much reliance on the JMX classes themselves. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
|Using a set of properties to identify an object just seems werid |to me. WHY |did the JMX spec do this??? Why not just use a unique string to |identify an |object??? Yes, I see one reasone, so you can do querys and lookup objects |based on properties, buy you could still do that without making the |properties part of the identifier. I agree. But the work is actually good. Classifying a name through properties means you can have a set based representation of the naming structure (as opposed to trees). Maybe it is just me but from my work on a datamining depth the tree based classifications (JNDI directories for example) are just WEAK. This is much more powerful. Also you can have a out of order string of pairs that make it easy to find stuff, the navigation is much much simpler, trust been there, already reached that conclusion. I don't have a problem with the theory, I believe it is the future. I have a problem with the implementation. There could be a default implementation that hashes on the string itself. You lose the out of order I was talking about just a second ago, but it is such an optimization that I don't know why it shouldn't be done. it is not a theoretical discusssion from my point of view. I do believe it is a superior naming structure (sets trees, the bibles got that wrong) but I am curious as to what Juha thoughts are on a possible optimization of the creation (actually that would be enough, hash and equals are fast enough). Just DON'T parse at creation time ??? Juha for example. By spec must we have Domain1:name1=value1;name2=value2 == Domain1:name2=value2;name1=value1 ??? I would imagine so, marcf | |Do you know what I mean?? | |Regards, |Hiram | |From: Juha-P Lindfors [EMAIL PROTECTED] |To: marc fleury [EMAIL PROTECTED] |CC: Jboss-Development@Lists. Sourceforge. Net |[EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Why is new ObjectName() so slow? |Date: Sun, 28 Apr 2002 21:39:26 +0300 (EET DST) | | |because an object name contains a set of properties that need to be |parsed and may also be a pattern which needs to be determined | |the current implementation does this eagerly at object name creation |time | |-- Juha | | |On Sun, 28 Apr 2002, marc fleury wrote: | | ok, | | I know I asked already and I can't remember the reason why creating an | ObjectName should be S slow. Can one of the JMX gurus |enlighten me |and | explain the reason. | | (yes again sorry) | | last I remembered the new ObjectName would take half the time of the | invocation (!). | | If that is still the case then it is going to invalidate a lot of the | thinking around the ObjectName MBean client proxy stuff which is quite | powerful. But it is software and software is fixable so I |can't imagine | that there is a real life reason for this to be so slow. | | marcf | | x | Marc Fleury, Ph.D | President | JBoss Group, LLC | x | | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | |-- |Juha Lindfors |Author of JMX: Managing J2EE with Java Management Extensions |Senior Developer, JBoss Group LLC | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development | | |_ |Send and receive Hotmail on your mobile device: http://mobile.msn.com | | |___ |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] Why is new ObjectName() so slow?
wrong answer trevor, marcf |-Original Message- |From: Trevor Squires [mailto:[EMAIL PROTECTED]] |Sent: Sunday, April 28, 2002 11:23 AM |To: marc fleury |Cc: [EMAIL PROTECTED]; Jboss-Development@Lists. Sourceforge. Net |Subject: RE: [JBoss-dev] Why is new ObjectName() so slow? | | |On Sun, 28 Apr 2002, marc fleury wrote: | | |because an object name contains a set of properties that need to be | |parsed and may also be a pattern which needs to be determined | | right the value=name pairs | |Which in a string passed to a constructor are not guaranteed to be |canonical or well formed. | | | |the current implementation does this eagerly at object name creation | |time | | can we do this lazily? can't we build equality and hash on the |FULL string? | |No. ObjectNames are immutable - the only time you have an opportunity to |throw malformed exceptions is at construction time. | | it strikes that the eager parsing is silly (eats up 50% of the |time !!!) and | only really useful in querying? Can you think of optimizations? | |50% of *what* time exactly? How many times are you creating the |ObjectName instance? | |Is it (de)serialisation that's causing you the problem? If so, see below. | | | It would really be appreciated as it would enable Bill's dream |of the CORBA | world really working in our JBoss implementation, the fast ON |lookup and bla | bla bla . | | Let me know if you can optimize it, please spend at least 10min thinking | about it. | Otherwise it sort of makes the invokers sort of useless at the JMX level. | | Any optimization DEEPLY appreciated, this is deep. And you are the man. | |Ok, the only laziness that we can insert while still being compliant is |on deserialization. | |Beyond that, consider not using ObjectNames in your invocation layer - |they are great big pigs designed to do too much. | |Trevor ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why is new ObjectName() so slow?
On Sun, 28 Apr 2002, Hiram Chirino wrote: Using a set of properties to identify an object just seems werid to me. yes. it's not just wierd, its clearly a poor design choice in this case. the object name is used as an identifier and therefore needed for lookup. overloading the identifier to become something other than just an array of chars we can compare is a problem. WHY did the JMX spec do this??? Why not just use a unique string to identify an object??? I do not know. Yes, I see one reasone, so you can do querys and lookup objects based on properties, buy you could still do that without making the properties part of the identifier. Do you know what I mean?? totally. see my other post. yes the object name should be just an identifier -- none of this property/pattern business. just a key for lookups. should probably spend some time trying to figure out how to bypass the object name use completely (leave it as internal to the server only) and see if we can replace it with a real identifier. I don't know if it would work or possible... need to think about it -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
|I've go a feeling that the order of the properties does not matter, so |DefaultDomain:service=XADataSource,name=DefaultDS would be the |same object |as DefaultDomain:name=DefaultDS,service=XADataSource. |I think that's whey he has to parse it early. right, I ask this as well, I don't remember if it is the case. We could have a simple OBJECTNAME implementation but that is fast enough. The exceptions (malformed bla bla bla) must remain exceptions. I believe we can do a default implementation that doesn't fully respect these but is fast enough, today this string manipulation is useless and a pig. It goes against the view of JMX as the fundamental construct for our super-server. And it is the reason for a lot of ugly hacks by me in the invoker layer. I need to simplify this and the spec won't get in the way. marcf | |Regards, |Hiram | | |_ |Chat with friends online, try MSN Messenger: http://messenger.msn.com | | |___ |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] Why is new ObjectName() so slow?
On Sun, 28 Apr 2002, marc fleury wrote: Juha for example. By spec must we have Domain1:name1=value1;name2=value2 == Domain1:name2=value2;name1=value1 ??? I would imagine so, yes and this is the problem for performance -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
|The question at the moment is, why do you need to create an object name |per invocation? Is it possible to cache the object names by mapping them |to *real* identifies as opposed to this property nonsense? (how many That is what I do today, with the EJB layer. This means however that we pass the hashcode back and forth from the proxy. The future of your JMX juha/trevor/adrian is the bill idea for dynamic clients. And as you know Juha under discussion in the spec. I want you to see how powerful this is. Give me an MBean, give me a client stack, a JNDI name and you have a client. BETTER YET, the Bill dynamic invocation client, where the client builds the invocation and passes that to the Invoker() and HE MUST PUT THE OBjectName in it. Do you see that? he can't guess the name hashing and the mapping we do. Your implementation being a pig precludes that. And I am sorry but having the superserver real in a year's time in all of the worlds infrastructure will supercede spec sillyness, even when that spec comes from France (are you there?). So one solution is to expose, as we do today but generalized to MBeans, a scheme by which you pass us a identifier that maps to the right ObjectName on the server. The only construct that makes sense is the String itself, and then there is no order bullshit and if you fuck up the name tough for you my friend, I am not going to care. 2 solutions. 1- I build a mapper that takes String and returns ObjectName 2- you build a ObjectName implementation that caches the ObjectName and returns the right Object if you pass me exactly the same String. Come to think of it we probably need the first one. Can you expose it at the JMX level? I believe the registry idea must be present at the JMX level, then you would put the objectname mapped to the String name and that is fast enough for me to use and STANDARDIZE on inside the server. Bar that, the spirit dies for a spec quirk |MBean's do you imagine having in your server, could you create the object |names for them on the server side and lookup the same instances from a |cache -- I know it sounds ass backwards but given then future plans on |JMX it would be best to avoid too much reliance on the JMX classes |themselves. correct that is what I understand we need that cache. It is the Registry idea with more generic mappings. It is a system level Registry juha. In a invoker I want to pass the String and use that to map to the ObjectName on the server or maybe expose an invoke that doesn't work with ObjectNames? something that makes sense. Keep exceptions out of the design. marcf I will not watch my people die while you discuss this invasion in a commitee -- some silly queen in a SF movie-- ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
On Sun, 28 Apr 2002, marc fleury wrote: 2 solutions. 1- I build a mapper that takes String and returns ObjectName 2- you build a ObjectName implementation that caches the ObjectName and returns the right Object if you pass me exactly the same String. Come to think of it we probably need the first one. Can you expose it at the JMX level? I have an idea for it but (obviously) haven't looked at the details yet. Might be a deliverable. Right now I need to take a time out on this. Need to finish the inforIT, explain our interceptors to EG and then do that finetuning for training slides. -- Juha I believe the registry idea must be present at the JMX level, then you would put the objectname mapped to the String name and that is fast enough for me to use and STANDARDIZE on inside the server. Bar that, the spirit dies for a spec quirk |MBean's do you imagine having in your server, could you create the object |names for them on the server side and lookup the same instances from a |cache -- I know it sounds ass backwards but given then future plans on |JMX it would be best to avoid too much reliance on the JMX classes |themselves. correct that is what I understand we need that cache. It is the Registry idea with more generic mappings. It is a system level Registry juha. In a invoker I want to pass the String and use that to map to the ObjectName on the server or maybe expose an invoke that doesn't work with ObjectNames? something that makes sense. Keep exceptions out of the design. marcf I will not watch my people die while you discuss this invasion in a commitee -- some silly queen in a SF movie-- -- Juha Lindfors Author of JMX: Managing J2EE with Java Management Extensions Senior Developer, JBoss Group LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
|Right now I need to take a time out on this. Need to finish the inforIT, |explain our interceptors to EG and then do that finetuning for training |slides. You are a young man with his priorities straight, I like that. Definitely write that informIT article, I bust my ass to give you exposure, take advantage. Let's see if you can explain to the EG what we are doing :) It works for EJB already but I want it to work on the generic MBean. The generic with client interceptors, proxy stack, tx,security, lookup (powerful in EJB due to cache) and persistence is well... an EJB... and the way we do it today, done right. Your potential, since we understand how to do EJBs right is to bring forth the real super-server, EJB is but an applied case that can be in fact tweaked to your needs. Dont' miss this opportunity to make JMX the future of component software, it will be for 3.1 and standard view in 4.0. Discovery and configuration are what we need to specify above and beyond the EJB spec. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why is new ObjectName() so slow?
Sorry if I'm just adding noise, but... It sounds like the biggest problem is that you keep parsing the same string into it's canonical form. Can't the jmx server cache the canonical names of the given ObjectNames? Then, for each new ObjectName(), check the cache, and if it doesn't exist, parse and cache the result. Am I missing something? -Larry - Original Message - From: Juha-P Lindfors [EMAIL PROTECTED] To: marc fleury [EMAIL PROTECTED] Cc: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Sunday, April 28, 2002 12:36 PM Subject: RE: [JBoss-dev] Why is new ObjectName() so slow? On Sun, 28 Apr 2002, marc fleury wrote: |because an object name contains a set of properties that need to be |parsed and may also be a pattern which needs to be determined right the value=name pairs |the current implementation does this eagerly at object name creation |time can we do this lazily? can't we build equality and hash on the FULL string? no, we need a canonical presentation for equality check (because the name is a set of properties, not just an array of characters.. we need to sort the properties before we can check for equality) it strikes that the eager parsing is silly (eats up 50% of the time !!!) and only really useful in querying? Can you think of optimizations? the optimizations that we can do inside ObjectName would only include possibly optimizations to Java's string handling, maybe replacing generic collections with type specific ones, and avoiding Collections.sort() (I don't know how it is implemented or how well it performs). However, the problem with even these optimizations is that Sun plans to push JMX as part of JDK from the next 1.5 version on. They however have no plans to publish an SPI which means whatever is inside javax.management packages will from the next version on be Sun's implementation. And as you and I well know, Sun's implementation isn't exactly performing or industrial strength. The question at the moment is, why do you need to create an object name per invocation? Is it possible to cache the object names by mapping them to *real* identifies as opposed to this property nonsense? (how many MBean's do you imagine having in your server, could you create the object names for them on the server side and lookup the same instances from a cache -- I know it sounds ass backwards but given then future plans on JMX it would be best to avoid too much reliance on the JMX classes themselves. -- Juha ___ 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] Why is new ObjectName() so slow?
|Sorry if I'm just adding noise, but... | |It sounds like the biggest problem is that you keep parsing the same string |into it's canonical form. Can't the jmx server cache the |canonical names of |the given ObjectNames? Then, for each new ObjectName(), check the cache, |and if it doesn't exist, parse and cache the result. Am I missing |something? that is what juha and I are discussing in the latest on the thread marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
Oh by the way if someone feels heroic today here is the code from
JRMPInvoker
I believe the line that is commented out on the new ObjectName should either
be the one (with cache at the JMX level solution 2 discussed) or should do a
look up on the Registry but with the String as opposed to a int like below
(solution 1 discussed)
(BTW I believe that with the advent of UCL the first line on cl is
useless...)
org.jboss.invocation.jrmp.server.JRMPInvoker
public Object invoke(Invocation invocation) throws Exception {
ClassLoader oldCl = Thread.currentThread().getContextClassLoader();
try
{
// Deserialize the transaction if it is there
invocation.setTransaction(importTPC(((MarshalledInvocation)
invocation).getTransactionPropagationContext()));
// Extract the ObjectName, the rest is still marshalled
// ObjectName mbean = new ObjectName((String)
invocation.getContainer());
// This is bad it should at least be using a sub set of the
Registry
// store a map of these names under a specific entry
(lookup(ObjecNames)) and look on
// that subset FIXME it will speed up lookup times
ObjectName mbean = (ObjectName) Registry.lookup((Integer)
invocation.getObjectName());
// The cl on the thread should be set in another interceptor
Object obj = server.invoke(mbean,
,
new Object[] {invocation},
Invocation.INVOKE_SIGNATURE);
return new MarshalledObject(obj);
}
catch (Exception e)
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
On Sun, 28 Apr 2002, marc fleury wrote: Oh by the way if someone feels heroic today here is the code from JRMPInvoker Ok, let me try a different answer then: I'm not familiar with the invokers and I've not seen the whole chain for JRMP so I'll ask a stupid question: Is there *any* way you can get the ObjectName instance to be serialised/deserialised in the call? If so then I can eliminate all the overhead of constructing an objectname (in the code you supplied) from the string args and still be compliant. Trevor ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
|Is there *any* way you can get the ObjectName instance to be |serialised/deserialised in the call? I serialize a int hash from the ObjectName. I used to serialize the string that creates the Objectname, the line that is commented out, all it does is get the string from a deserialized invocation and create a new. The solution from lindfors is to create a map that takes a String and gives you a cached instance on the server. The larry solution is to do that inside the new i.e. if I give you a string you know about just retrieve the parsed data and possibly just the ObjectName inside JMX. The reason I don't serialize the instance itself is that the client needs to know about the ObjectName class then and I don't want to ship all of JMX to a client. are we in sync? marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
Just to close the circle ( I am documenting this in the training slides). The reason for this is that the invokers today are tied to the EJB view of the world or at least the subset of the client interceptors that embed their ObjectName and then we have full control over the way the Object is represented. In short the client proxy cache the hashcode of the objectName. You understand that the calling code HAS NO KNOWLEDGE OF THE OBJECTNAME HASHCODE, at a maximum he will know the ObjectName String and that way we can bring the dream of Bill burke alive by making these invokers aware of the name as a string and capable of looking up these name as we lookup the map from the Registry today. Ping me for the classes to change if you really want to take this on. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc |fleury |Sent: Sunday, April 28, 2002 3:18 PM |To: Trevor Squires |Cc: Larry Sanderson; Jboss-Development@Lists. Sourceforge. Net |Subject: RE: [JBoss-dev] Why is new ObjectName() so slow? | | ||Is there *any* way you can get the ObjectName instance to be ||serialised/deserialised in the call? | |I serialize a int hash from the ObjectName. I used to serialize the |string that creates the Objectname, the line that is commented out, all it |does is get the string from a deserialized invocation and create a new. | |The solution from lindfors is to create a map that takes a String and gives |you a cached instance on the server. |The larry solution is to do that inside the new i.e. if I give you a |string you know about just retrieve the parsed data and possibly just the |ObjectName inside JMX. | |The reason I don't serialize the instance itself is that the |client needs to |know about the ObjectName class then and I don't want to ship all of JMX to |a client. | |are we in sync? | |marcf | | |___ |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] Why is new ObjectName() so slow?
On Sun, 28 Apr 2002, marc fleury wrote: The reason I don't serialize the instance itself is that the client needs to know about the ObjectName class then and I don't want to ship all of JMX to a client. are we in sync? marcf Understood now. IMO Juha's solution seems better insulated from changes to JMX spec (or implementation for that matter). Just to be a complete pain - the client would only need ObjectName, MalformedObjectNameException, OperationsException and JMRuntimeException - not the hole JMX impl. Cleaning up the serialized form of ObjectName is something I have to do anyhow and it would just make this problem go away... Trev ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why is new ObjectName() so slow?
Juha-P Lindfors wrote: On Sun, 28 Apr 2002, marc fleury wrote: Juha for example. By spec must we have Domain1:name1=value1;name2=value2 == Domain1:name2=value2;name1=value1 ??? I would imagine so, yes and this is the problem for performance -- Juha I've been following this discussion and I'd like to throw in my $.02: Can the implementation override its hashCode() method and compute it in a different way; and use the hashCode() as an initial part of the equals() method? I'm thinking doing something simple like scanning the input string and resetting the hash computation counter ever time a ';' is seen. IOW, compute a unique hashcode for each name=value pair and simply XOR them together to get the final hashcode for the ObjectName. This way, a hash comparison can be done without sorting anything. It will at least reduce time when the two objects are not equal. The scanning can be done lazily: only when the equals() or hashCode() methods are called. Disadvantages: * Breaks spec since only the constuctor is supposed to check syntax. This can be fixed by doing the hashcode computation in the constructor. * Still O(n) where n is the length of the initial string. * Can't use this to search for a specific name=value pair. Advantages: * Should be faster than parsing the input into a hash table and then sorting in order to do a comparison. However, the sort comparison should still be done once a hashCode() match is found, unfortunately! * Reduces memory requirements by delaying the creation of a hashtable until it is actually required. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Why is new ObjectName() so slow?
|Understood now. IMO Juha's solution seems better insulated from changes |to JMX spec (or implementation for that matter). I agree, it would also be JDK1.5 poopoo code from SUN immune :) So this solution has a clear edge. |Just to be a complete pain - the client would only need ObjectName, |MalformedObjectNameException, OperationsException and JMRuntimeException - |not the hole JMX impl. Yeah you are partially right until 1.5 and the ObjectName. If you want to go ahead and adapt the EJB layers, it is going to take some work in the proxy, the JRMPInvoker and the ProxyFactory that binds the name under the Registry. I believe it is a worthy addition. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
