Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
On Fri, Apr 26, 2002 at 05:52:54AM -0700, marc fleury wrote: I totally agree with the article, I believe we should merge our configuration files today, and get rid of the unreadable XML, You keep saying unreadable XML. XML is now the lingua franca of human-readable structured data. XHTML, JSTL, Ant configs, SOAP, etc., mean that any serious designer of web applications must be proficient in reading and writing XML. Saying unreadable XML in the 21st century is like saying unreadable French in the 18th century. It's a statement of one's illiteracy, not an indictment of the method of representation. You can have bad XML (or, more to the point, bad DTDs), in just the way that you can have bad French; in both cases the burden of clarity is on the author. -Michael Robinson P.S. And, in fact, that's more or less the point of the cited article. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
XML is now the lingua franca of human-readable structured data. XHTML, JSTL, Ant configs, SOAP, etc., mean that any serious designer of web applications must be proficient in reading and writing XML. Saying unreadable XML in the 21st century is like saying unreadable French in the 18th century. It's a statement of one's illiteracy, not an indictment of the method of representation. And here I was thinking the point of XML was to make it easier for the *machine* to parse structured data. -- Juha, the illiterate jns:java jns:comment![CDATA[Hello, World]]/jns:comment jns:package name=my.stuff/ jns:import name=java.lang.System/ jns:class name=Main extends=java.lang.Object/ jns:implements name=MyInterface/ jns:implements name=ThatOtherInterface/ /jns:class jns:method name=main PUBLIC STATIC jns:comment![CDATA[Print the message]]/jns:comment jns:return-typevoid/jns:return-type jns:signature jns:arg name=args/ jns:type name=java.lang.String ARRAY/ /jns:signature jns:body jns:invokestatic name=java.lang.System reference=out jns:method name=println jns:value![CDATA[Hello, World]]/jns:value /jns:method /jns:invokestatic /jns:body /jns:method /jns:java ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
On Sun, Apr 28, 2002 at 10:54:43AM +0300, Juha-P Lindfors wrote: And here I was thinking the point of XML was to make it easier for the *machine* to parse structured data. In which case, it would all be ASN.1. jns:implements name=MyInterface/ jns:implements name=ThatOtherInterface/ Yeah, I'll bet it does. Your example is actually the exception that proves the rule. Someone who was literate in XML, but with no prior exposure to the syntax and semantics of Java, could get more meaning out of the XML version than the Java version. And here's a good example of bad DTD: jns:invokestatic name=java.lang.System reference=out jns:method name=println jns:value![CDATA[Hello, World]]/jns:value /jns:method /jns:invokestatic Yes, if you have the resources to design and implement a specific language for a specific application, that language will be more concise, and if the users of the application have the time to study and practice that language, to them it will be more readable. XML allows one to minimise the number of data representation languages in the world that must be designed, implemented, studied and practiced. Which is the whole point of a lingua franca. In the 18th century, nobody particularly enjoyed communicating in French; it was simply a preferable alternative to having to learn all the other languages. -Michael Robinson ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
On Sun, 28 Apr 2002, Michael Robinson wrote: Someone who was literate in XML, but with no prior exposure to the syntax and semantics of Java, could get more meaning out of the XML version than the Java version. Really? To me both would look like nonsense. that language will be more concise which I believe is what was requested. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Optimizations, packaging and the servlet 2.3 class loading model
Comments are inline. Our default optimization of ejb calls through the remote interface is not working with the servlet 2.3 container class loading model [...] We can deal with this by either 1. ignore the servlet 2.3 class loading model, which is what Jetty does by default Sounds good, nice and simple and clear. Unfortunately, I believe it is relatively common thing for webapp designers to want to use the 2.3 feature to allow them to, for example, use their favourite xml parser instead of the container provided one. 2. transform an ear deployment into a canonical representation where the war classes are promoted to an ear level class loader We could force the web container to always delegate class loading to the ear class loader, with the provisio that the ear class loader would have to implement 2.3 behaviour (ie allow ear classes to take precedence) to satisfy existing applications requiring 2.3 compliance. 3. advocate our own packaging model and claim that the vagaries of the specs allow for this as an aspect of deployment I think this will just muddy the waters even further. 4. revert back to trying to perform marshalling of incompatible classes at runtime based on the caller/callee views Sounds a lot more complex than option 2. Jan ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-547128 ] sessioncontext not set when calling
Bugs item #547128, was opened at 2002-04-22 15:33
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=547128group_id=22866
Category: CatalinaBundle
Group: v2.4 (stable)
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Erik Konijnenburg (konijnenburg)
Assigned to: Scott M Stark (starksm)
Summary: sessioncontext not set when calling
Initial Comment:
I have written a simple session bean which echos a
string. I access this bean via the web.
I can secure this bean using when i access it from a
servlet.
When I access it from a JSP the session context is not
set. I tried this with the JBOSS catalina bundle:
JBoss-2.4.4_Tomcat-4.0.1
JSP file
html
head
title
echo
/title
/head
jsp:useBean id=bean1 scope=session
class=echo.EchoBean /
jsp:setProperty name=bean1 property=echo value
= Hello Erik /
body
h1
JBuilder Generated JSP
/h1
/body
%= bean1.getEcho() %
/html
Bean
package echo;
import java.rmi.*;
import javax.ejb.*;
/**
* pTitle: /p
* pDescription: /p
* pCopyright: Copyright (c) 2002/p
* pCompany: /p
* @author unascribed
* @version 1.0
*/
public class EchoBean implements SessionBean {
private SessionContext sessionContext;
String echo;
public void ejbCreate() {
}
public void ejbRemove() {
}
public void ejbActivate() {
}
public void ejbPassivate() {
}
public void setSessionContext(SessionContext
sessionContext) {
System.out.println(Setting Session context);
this.sessionContext = sessionContext;
}
public void setEcho(String echo) {
this.echo = echo;
System.out.println(setEcho(String echo););
}
public String getEcho() {
System.out.println(getEcho(););
return echo + +
sessionContext.getCallerPrincipal().getName();
}
}
web.xml
---
?xml version=1.0 encoding=UTF-8?
!DOCTYPE web-app PUBLIC -//Sun Microsystems,
Inc.//DTD Web Application
2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd;
web-app
servlet
servlet-nameechoit/servlet-name
jsp-file/echo.jsp/jsp-file
/servlet
servlet-mapping
servlet-nameechoit/servlet-name
url-pattern/restricted/echoit/url-pattern
/servlet-mapping
security-constraint
display-nameCustomer/display-name
web-resource-collection
web-resource-nameCollection1/web-resource-
name
url-pattern/restricted/*/url-pattern
url-pattern/echo.jsp/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
http-methodPUT/http-method
/web-resource-collection
auth-constraint
role-nameCustomer/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/logon.jsp/form-login-page
form-error-page/logon_failed.jsp/form-error-
page
/form-login-config
/login-config
security-role
role-nameCustomer/role-name
/security-role
ejb-ref
ejb-ref-nameEJB/Echo/ejb-ref-name
ejb-ref-typeSession/ejb-ref-type
homeecho.EchoHome/home
remoteecho.Echo/remote
/ejb-ref
/web-app
ejb-jar.xml
---
?xml version=1.0 encoding=UTF-8?
!DOCTYPE ejb-jar PUBLIC -//Sun Microsystems,
Inc.//DTD Enterprise JavaBeans
1.1//EN http://java.sun.com/j2ee/dtds/ejb-
jar_1_1.dtd
ejb-jar
enterprise-beans
session
ejb-nameEcho/ejb-name
homeecho.EchoHome/home
remoteecho.Echo/remote
ejb-classecho.EchoBean/ejb-class
session-typeStateful/session-type
transaction-typeContainer/transaction-
type
/session
/enterprise-beans
assembly-descriptor
security-role
role-nameCustomer/role-name
/security-role
method-permission
role-nameCustomer/role-name
method
description /
ejb-nameEcho/ejb-name
method-name*/method-name
/method
/method-permission
/assembly-descriptor
/ejb-jar
jboss.xml
-
?xml version=1.0 encoding=UTF-8?
!DOCTYPE jboss PUBLIC '-//JBoss//DTD JBOSS
2.4//EN' 'http://www.jboss.org/j2ee/dtd/jboss_2_4.dtd'
jboss
security-domainjava:/jaas/default/security-
domain
enterprise-beans
session
ejb-nameEcho/ejb-name
jndi-nameEcho/jndi-name
/session
/enterprise-beans
/jboss
jboss-web.xml
-
?xml version=1.0 encoding=UTF-8?
jboss-web
security-domainjava:/jaas/default/security-
domain
ejb-ref
ejb-ref-nameEJB/Echo/ejb-ref-name
jndi-nameEcho/jndi-name
/ejb-ref
/jboss-web
--
Comment By: Erik Konijnenburg (konijnenburg)
Date: 2002-04-28 11:37
Message:
Logged In: YES
user_id=522939
I added the following to web.xml:
context-param
param-namecookies/param-name
param-valuetrue/param-value
/context-param
[JBoss-dev] [ jboss-Bugs-549775 ] Running testsuite twice has many errors
Bugs item #549775, was opened at 2002-04-28 22:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=549775group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Stephen Coy (scoy) Assigned to: Nobody/Anonymous (nobody) Summary: Running testsuite twice has many errors Initial Comment: Running the full JBoss test suite twice in a row without restarting anything results in many test failures and/or errors on the second pass. The problem seems to be security related, as you will see a swathe of exceptions reported to the console like: 13:58:01,405 ERROR [MainDeployer] Couldn't deploy URL file:/Users/steve/EnterpriseJava/ jboss-all/testsuite/output/lib/idgen.jar 13:58:01,406 ERROR [STDERR] java.sql.SQLException: ResourceException javax.resource.ResourceException: No matching credentials in Subject! 13:58:01,408 ERROR [STDERR] at org.jboss.resource.adapter.jdbc.local.LocalDataS ource.getConnection(LocalDataSource.java:105) 13:58:01,410 ERROR [STDERR] at org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.g etConnection(JDBCCommand.java:694) 13:58:01,411 ERROR [STDERR] at org.jboss.ejb.plugins.jaws.jdbc.JDBCInitComman d.execute(JDBCInitCommand.java:120) 13:58:01,413 ERROR [STDERR] at org.jboss.ejb.plugins.jaws.JAWSPersistenceMana ger.create(JAWSPersistenceManager.java:130) 13:58:01,415 ERROR [STDERR] at org.jboss.ejb.plugins.CMPPersistenceManager.cr eate(CMPPersistenceManager.java:155) 13:58:01,417 ERROR [STDERR] at org.jboss.ejb.EntityContainer.create(EntityContain er.java:337) 13:58:01,418 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:790 ) 13:58:01,420 ERROR [STDERR] at org.jboss.ejb.EntityContainer.invoke(EntityContain er.java:1055) 13:58:01,425 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBe anServerImpl.java:491) 13:58:01,427 ERROR [STDERR] at org.jboss.system.ServiceController$ServiceProxy.i nvoke(ServiceController.java:867) 13:58:01,428 ERROR [STDERR] at $Proxy19.create(Unknown Source) 13:58:01,430 ERROR [STDERR] at org.jboss.system.ServiceController.create(Service Controller.java:271) 13:58:01,432 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 13:58:01,459 ERROR [STDERR] at org.jboss.mx.capability.ReflectedMBeanDispatche r.invoke(ReflectedMBeanDispatcher.java:284) 13:58:01,460 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBe anServerImpl.java:491) 13:58:01,464 ERROR [STDERR] at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy. java:174) 13:58:01,464 ERROR [STDERR] at $Proxy860.create(Unknown Source) 13:58:01,464 ERROR [STDERR] at org.jboss.ejb.EjbModule.createService(EjbModule. java:392) 13:58:01,465 ERROR [STDERR] at org.jboss.system.ServiceMBeanSupport.create(Se rviceMBeanSupport.java:134) 13:58:01,465 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 13:58:01,465 ERROR [STDERR] at org.jboss.mx.capability.ReflectedMBeanDispatche r.invoke(ReflectedMBeanDispatcher.java:284) 13:58:01,466 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBe anServerImpl.java:491) 13:58:01,466 ERROR [STDERR] at org.jboss.system.ServiceController$ServiceProxy.i nvoke(ServiceController.java:867) 13:58:01,467 ERROR [STDERR] at $Proxy19.create(Unknown Source) 13:58:01,467 ERROR [STDERR] at org.jboss.system.ServiceController.create(Service Controller.java:271) 13:58:01,474 ERROR [STDERR] at org.jboss.system.ServiceController.create(Service Controller.java:211) 13:58:01,474 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 13:58:01,475 ERROR [STDERR] at org.jboss.mx.capability.ReflectedMBeanDispatche r.invoke(ReflectedMBeanDispatcher.java:284) 13:58:01,476 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBe anServerImpl.java:491) 13:58:01,476 ERROR [STDERR] at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy. java:174) 13:58:01,476 ERROR [STDERR] at $Proxy5.create(Unknown Source) 13:58:01,477 ERROR [STDERR] at org.jboss.ejb.EJBDeployer.create(EJBDeployer.jav a:376) 13:58:01,477 ERROR [STDERR] at org.jboss.deployment.MainDeployer.create(MainD eployer.java:651) 13:58:01,477 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainD eployer.java:526) 13:58:01,478 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainD eployer.java:490) 13:58:01,478 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainD eployer.java:472) 13:58:01,508 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 13:58:01,509 ERROR [STDERR] at org.jboss.mx.capability.ReflectedMBeanDispatche r.invoke(ReflectedMBeanDispatcher.java:284) 13:58:01,510 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBe anServerImpl.java:491) 13:58:01,510 ERROR [STDERR] at
[JBoss-dev] [ jboss-Bugs-547128 ] sessioncontext not set when calling
Bugs item #547128, was opened at 2002-04-22 08:33
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=547128group_id=22866
Category: CatalinaBundle
Group: v2.4 (stable)
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Erik Konijnenburg (konijnenburg)
Assigned to: Scott M Stark (starksm)
Summary: sessioncontext not set when calling
Initial Comment:
I have written a simple session bean which echos a
string. I access this bean via the web.
I can secure this bean using when i access it from a
servlet.
When I access it from a JSP the session context is not
set. I tried this with the JBOSS catalina bundle:
JBoss-2.4.4_Tomcat-4.0.1
JSP file
html
head
title
echo
/title
/head
jsp:useBean id=bean1 scope=session
class=echo.EchoBean /
jsp:setProperty name=bean1 property=echo value
= Hello Erik /
body
h1
JBuilder Generated JSP
/h1
/body
%= bean1.getEcho() %
/html
Bean
package echo;
import java.rmi.*;
import javax.ejb.*;
/**
* pTitle: /p
* pDescription: /p
* pCopyright: Copyright (c) 2002/p
* pCompany: /p
* @author unascribed
* @version 1.0
*/
public class EchoBean implements SessionBean {
private SessionContext sessionContext;
String echo;
public void ejbCreate() {
}
public void ejbRemove() {
}
public void ejbActivate() {
}
public void ejbPassivate() {
}
public void setSessionContext(SessionContext
sessionContext) {
System.out.println(Setting Session context);
this.sessionContext = sessionContext;
}
public void setEcho(String echo) {
this.echo = echo;
System.out.println(setEcho(String echo););
}
public String getEcho() {
System.out.println(getEcho(););
return echo + +
sessionContext.getCallerPrincipal().getName();
}
}
web.xml
---
?xml version=1.0 encoding=UTF-8?
!DOCTYPE web-app PUBLIC -//Sun Microsystems,
Inc.//DTD Web Application
2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd;
web-app
servlet
servlet-nameechoit/servlet-name
jsp-file/echo.jsp/jsp-file
/servlet
servlet-mapping
servlet-nameechoit/servlet-name
url-pattern/restricted/echoit/url-pattern
/servlet-mapping
security-constraint
display-nameCustomer/display-name
web-resource-collection
web-resource-nameCollection1/web-resource-
name
url-pattern/restricted/*/url-pattern
url-pattern/echo.jsp/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
http-methodPUT/http-method
/web-resource-collection
auth-constraint
role-nameCustomer/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/logon.jsp/form-login-page
form-error-page/logon_failed.jsp/form-error-
page
/form-login-config
/login-config
security-role
role-nameCustomer/role-name
/security-role
ejb-ref
ejb-ref-nameEJB/Echo/ejb-ref-name
ejb-ref-typeSession/ejb-ref-type
homeecho.EchoHome/home
remoteecho.Echo/remote
/ejb-ref
/web-app
ejb-jar.xml
---
?xml version=1.0 encoding=UTF-8?
!DOCTYPE ejb-jar PUBLIC -//Sun Microsystems,
Inc.//DTD Enterprise JavaBeans
1.1//EN http://java.sun.com/j2ee/dtds/ejb-
jar_1_1.dtd
ejb-jar
enterprise-beans
session
ejb-nameEcho/ejb-name
homeecho.EchoHome/home
remoteecho.Echo/remote
ejb-classecho.EchoBean/ejb-class
session-typeStateful/session-type
transaction-typeContainer/transaction-
type
/session
/enterprise-beans
assembly-descriptor
security-role
role-nameCustomer/role-name
/security-role
method-permission
role-nameCustomer/role-name
method
description /
ejb-nameEcho/ejb-name
method-name*/method-name
/method
/method-permission
/assembly-descriptor
/ejb-jar
jboss.xml
-
?xml version=1.0 encoding=UTF-8?
!DOCTYPE jboss PUBLIC '-//JBoss//DTD JBOSS
2.4//EN' 'http://www.jboss.org/j2ee/dtd/jboss_2_4.dtd'
jboss
security-domainjava:/jaas/default/security-
domain
enterprise-beans
session
ejb-nameEcho/ejb-name
jndi-nameEcho/jndi-name
/session
/enterprise-beans
/jboss
jboss-web.xml
-
?xml version=1.0 encoding=UTF-8?
jboss-web
security-domainjava:/jaas/default/security-
domain
ejb-ref
ejb-ref-nameEJB/Echo/ejb-ref-name
jndi-nameEcho/jndi-name
/ejb-ref
/jboss-web
--
Comment By: Scott M Stark (starksm)
Date: 2002-04-28 10:16
Message:
Logged In: YES
user_id=175228
The cookies flag belongs in the tomcat4-service.xml
descriptor, not your web.xml descriptor. See the latest
2.4.5RC3 release.
[JBoss-dev] MBeanInfo, invoke, Dynamic clients
Ok this is really more of Bill Burke's stuff. I was talking to him on Friday on IM. Another idea coming from the world of CORBA is that of dynamic clients and server side servants. It seems both ideas are linked and quite simple to implement. Take my previous were we specify a stack of client side interceptors for EJB behavior. Imagine that instead of the EJB Remote we put 1- the StandardMBean interface, or any typed interface you specify to us 2- the INVOKE() at the CLIENT LEVEL (something I will cover in the class next week) then we can essentially say that you can construct your abstract invocation like we do in JBoss EJB client side interceptors, you can set you MBean target, you can set what object in cache you are talking to, you can dynamically create an invocation (which is what we do at the proxy level today) and voils dynamic clients with full invoke power. Another thing that would be interesting is exposing a rich MBeanInfo object that can describe for the client the full stack of interceptors (client and server) so that a tool can look at the MBeanInfo and understand that he is working with an assembly that essentially throws in clientcache, tx, security and server side persistence. Just advanced descriptors. Then the way the MBeanInfo is generated is that we ask the mbean and every interceptor to append it's own MBeanInfo. You describe the full flow this way assembled at run-time. It is sort of the dynamic discovery of the personality of the pipe you are talking to. I think that it will make the view of the super-server even more tangible for tools. In terms of implementation it means some work to represent in a transparent way the MBeanName and the Method, both structure are hashed equivalents today that speed up the communication but also are dependent on intermediary interceptor to work. If we are going to expose this to the client we need to be careful. Actually the method is ok as it is a translator but the String MBeanName needs to be done explicitely (so you can pass the name from the client). 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
[JBoss-dev] Why is new ObjectName() so slow?
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
RE: [JBoss-dev] Automated JBoss Testsuite Results: 28-April-2002
Holly molly |Number of tests run: 585 | | | |Successful tests: 582 |Errors:1 |Failures: 2 | | we are almost there, kudos to Mr Stark for this push. marcf ___ 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
[JBoss-dev] Re: JBossMQ Questions
From: Andreas Schaefer [EMAIL PROTECTED] To: Hiram Chirino [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: JBossMQ Questions Date: Sat, 27 Apr 2002 22:19:22 -0700 Hi Hiram Hi Andreas, Just started to implement JSR-77 performance monitoring on JBossMQ (was just in the flow after the recent events). I came up with some questions but let me explain what JSR-77 spec. contains: a JMS stats contains: - list of connections - which contains a list of sesssions - which contains a list of consumers and producers I started adding JBoss MQ code in JMSServer because this seems to be the central component of JBossMQ. Now I need to find out what connections exists and retrieve informations from them inclusive the list of sessions and from this the list of sender/receivers or list of publisher/subscribers. All this seems not to be a problem. But I don't see the connnection between JMSServer and SpyConnection. Is there a way to get there inclusive going over JNDI or JMX ? I think you might be confused because the JMSServer supports stateless connection protocols such as RMI. So, this means is that the JMSServer does not keep track of the connections that are established with him. Once a client establishes a connection with the server, he passes a ConnectionToken object allong with every request he makes to the server. The ConnectionToken holds enough info for the server to identify from which connection the request is comming from and how to send send data asynchronously to that connection. Now in the case of the stateful transport protocols, such as the OIL and UIL, it would be possible to keep track of the connections since we have to manage the thread the reads input from the sockets. I can see us creating registing a new MBean for each connection that is accecpted. I hope that made sense. Regards, HIram Thanx x Andreas Schaefer Senior Consultant JBoss Group, LLC x _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Automated JBoss Testsuite Results: 28-April-2002
The clustering test has 1 failure that I haven't been able to figure out. I guess I will have to comment it out.(the erroneous test) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Sunday, April 28, 2002 1:54 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Automated JBoss Testsuite Results: 28-April-2002 Holly molly |Number of tests run: 585 | | | |Successful tests: 582 |Errors:1 |Failures: 2 | | we are almost there, kudos to Mr Stark for this push. 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?
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] Automated JBoss Testsuite Results: 28-April-2002
I'm pleased to say that after my latest fixes to the jca stuff i get, for Branch_3_0: Tests Failures Errors Success rate Time 582 00 100.00% 1348.885 on my linux jdk 1.4 setup. david jencks On 2002.04.28 13:54:00 -0400 marc fleury wrote: Holly molly |Number of tests run: 585 | | | |Successful tests: 582 |Errors:1 |Failures: 2 | | we are almost there, kudos to Mr Stark for this push. 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?
|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] Automated JBoss Testsuite Results: 28-April-2002
Hooray! Then 3.0RC1 has graduated. Time to FINAL. ( I believe Scott wants to do a RC2 for at least a week). Time to congratulate each other. This is history in the making and I am glad to be here with you guys. PLeC (Excellent) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Jencks |Sent: Sunday, April 28, 2002 1:20 PM |To: marc fleury |Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Automated JBoss Testsuite Results: |28-April-2002 | | |I'm pleased to say that after my latest fixes to the jca stuff i get, for |Branch_3_0: | |Tests Failures Errors Success rate Time |582 00 100.00% 1348.885 | |on my linux jdk 1.4 setup. | |david jencks | |On 2002.04.28 13:54:00 -0400 marc fleury wrote: | Holly molly | | |Number of tests run: 585 | | | | | | | |Successful tests: 582 | |Errors:1 | |Failures: 2 | | | | | | we are almost there, kudos to Mr Stark for this push. | | | 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 ___ 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] Automated JBoss Testsuite Results: 28-April-2002
It's a milestone, but ... 1. There are more bugs 2. this is only one jvm. 3. I think the testsuite should run twice with no errors (see bug 549775) 2.a Well, 1.9 jvms. Running on osx, everything passes except the cluster tests, which presumably fail because I removed cluster-service.xml. For some reason cluster-service.xml started hanging on my powerbook after the last time I booted. Is there some way to get it to throw an exception instead of hanging? 3.a I'm working on a fix to one of the big problems seen in the trace in that bug, datasources currently can't be stopped and restarted. In general do we want to claim that, on a running server, any mbean can be stopped and restarted and the server will still run? thanks david jencks On 2002.04.28 16:32:26 -0400 marc fleury wrote: Hooray! Then 3.0RC1 has graduated. Time to FINAL. ( I believe Scott wants to do a RC2 for at least a week). Time to congratulate each other. This is history in the making and I am glad to be here with you guys. PLeC (Excellent) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Jencks |Sent: Sunday, April 28, 2002 1:20 PM |To: marc fleury |Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Automated JBoss Testsuite Results: |28-April-2002 | | |I'm pleased to say that after my latest fixes to the jca stuff i get, for |Branch_3_0: | |Tests Failures Errors Success rate Time |582 00 100.00% 1348.885 | |on my linux jdk 1.4 setup. | |david jencks | |On 2002.04.28 13:54:00 -0400 marc fleury wrote: | Holly molly | | |Number of tests run: 585 | | | | | | | |Successful tests: 582 | |Errors:1 | |Failures: 2 | | | | | | we are almost there, kudos to Mr Stark for this push. | | | 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Automated JBoss Testsuite Results: 28-April-2002
Except that if you run the test twice in a row the error count does not stay at 0. Still more work to do. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: marc fleury [EMAIL PROTECTED] To: David Jencks [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, April 28, 2002 1:32 PM Subject: RE: [JBoss-dev] Automated JBoss Testsuite Results: 28-April-2002 Hooray! Then 3.0RC1 has graduated. Time to FINAL. ( I believe Scott wants to do a RC2 for at least a week). Time to congratulate each other. This is history in the making and I am glad to be here with you guys. PLeC (Excellent) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Jencks |Sent: Sunday, April 28, 2002 1:20 PM |To: marc fleury |Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Automated JBoss Testsuite Results: |28-April-2002 | | |I'm pleased to say that after my latest fixes to the jca stuff i get, for |Branch_3_0: | |Tests Failures Errors Success rate Time |582 00 100.00% 1348.885 | |on my linux jdk 1.4 setup. | |david jencks | |On 2002.04.28 13:54:00 -0400 marc fleury wrote: | Holly molly | | |Number of tests run: 585 | | | | | | | |Successful tests: 582 | |Errors:1 | |Failures: 2 | | | | | | we are almost there, kudos to Mr Stark for this push. | | | 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 ___ 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: 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
[JBoss-dev] CVS HEAD in danger
I'll be doing some major commits in a few hours. I haven't merged from mainline in about 1.5 weeks so I may kill commits that have been done in that timespan. Sorry for the problems... Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Automated JBoss Testsuite Results: 28-April-2002
oh well, now the trick is to put the champagne bottle cork BACK in the bottle :) he he marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Sunday, April 28, 2002 2:46 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Automated JBoss Testsuite Results: |28-April-2002 | | |Except that if you run the test twice in a row the error count does |not stay at 0. Still more work to do. | | |Scott Stark |Chief Technology Officer |JBoss Group, LLC | |- Original Message - |From: marc fleury [EMAIL PROTECTED] |To: David Jencks [EMAIL PROTECTED] |Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] |Sent: Sunday, April 28, 2002 1:32 PM |Subject: RE: [JBoss-dev] Automated JBoss Testsuite Results: 28-April-2002 | | | Hooray! | | Then 3.0RC1 has graduated. Time to FINAL. ( I believe Scott |wants to do a | RC2 for at least a week). | | Time to congratulate each other. | | This is history in the making and I am glad to be here with you guys. | | PLeC (Excellent) | | marcf | | | |-Original Message- | |From: [EMAIL PROTECTED] | |[mailto:[EMAIL PROTECTED]]On Behalf Of David | |Jencks | |Sent: Sunday, April 28, 2002 1:20 PM | |To: marc fleury | |Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] | |Subject: Re: [JBoss-dev] Automated JBoss Testsuite Results: | |28-April-2002 | | | | | |I'm pleased to say that after my latest fixes to the jca stuff |i get, for | |Branch_3_0: | | | |Tests Failures Errors Success rate Time | |582 00 100.00% 1348.885 | | | |on my linux jdk 1.4 setup. | | | |david jencks | | | |On 2002.04.28 13:54:00 -0400 marc fleury wrote: | | Holly molly | | | | |Number of tests run: 585 | | | | | | | | | | | |Successful tests: 582 | | |Errors:1 | | |Failures: 2 | | | | | | | | | | we are almost there, kudos to Mr Stark for this push. | | | | | | 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 | | | ___ | 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
[JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual hosts
Hi,
Sorry, it´s me again.
I´m still trying to get virtual hosts working via apache2.0.35 using the
mod_webapp connector, jboss3.0RC1 and tomcat4.0.3.
I don´t want to get on your nerves but I´ve tried just about everything and
I haven´t received any answers to my previous virtual host questions.
The strange thing is that when using mod_jk I at least get a tomcat
directory listing of my virtual host, however I haven´t managed to get any
servlets running yet.
When I switch to mod_webapp whilst keeping everything else the same I don´t
even get that.
I decided to tamper a bit with the webapp code and the output tells me that
the context is null! Why? I know this might not be a jboss question and
more a webapp question but I´m hoping that you might be able to shed some
light on the topic.
+ CODE CHANGED +++
try {
context=deploy(connection,logger,appl,host,path);
logger.log(+++ MD_CONTEXT_OUTPUT: + context + +++);
} catch (Exception e) {
logger.log(e);
}
OUTPUT
00:04:50,966 ERROR [Engine]
[org.apache.catalina.connector.warp.WarpConfigurationHandler] +++
MD_CONTEXT_OUTPUT: null +++
00:04:50,966 ERROR [Engine]
[org.apache.catalina.connector.warp.WarpConfigurationHandler] +++_MD_+++
Error deploying web ap
This must be just about my 5th posting on this subject. Maybe this time
I´ll have more luck :-).
Any hints at all would be of great help!!
bye Michael Delamere
___
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] CVS HEAD in danger
Negative. Merge the changes into your view before committing by updating your view. Don't just dump old code into main. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Jboss-Dev [EMAIL PROTECTED] Sent: Sunday, April 28, 2002 3:05 PM Subject: [JBoss-dev] CVS HEAD in danger I'll be doing some major commits in a few hours. I haven't merged from mainline in about 1.5 weeks so I may kill commits that have been done in that timespan. Sorry for the problems... Bill ___ 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] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual hosts
Your asking at the wrong time as I don't care about hooking up an
external Apache server to Tomcat while Tomcat inside of JBoss
works and we are in the process of getting releases out. Further,
mod_webapp seems about an alpha release given all the problems
on the tomcat list and I'm not debugging this connector until
the final 3.0 release is out in about 2 weeks.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Michael Delamere [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, April 28, 2002 3:16 PM
Subject: [JBoss-dev] jboss3.0 + apache2.0.35 + tomcat4.0.3 + virtual hosts
Hi,
Sorry, it´s me again.
I´m still trying to get virtual hosts working via apache2.0.35 using the
mod_webapp connector, jboss3.0RC1 and tomcat4.0.3.
I don´t want to get on your nerves but I´ve tried just about everything and
I haven´t received any answers to my previous virtual host questions.
The strange thing is that when using mod_jk I at least get a tomcat
directory listing of my virtual host, however I haven´t managed to get any
servlets running yet.
When I switch to mod_webapp whilst keeping everything else the same I don´t
even get that.
I decided to tamper a bit with the webapp code and the output tells me that
the context is null! Why? I know this might not be a jboss question and
more a webapp question but I´m hoping that you might be able to shed some
light on the topic.
+ CODE CHANGED +++
try {
context=deploy(connection,logger,appl,host,path);
logger.log(+++ MD_CONTEXT_OUTPUT: + context + +++);
} catch (Exception e) {
logger.log(e);
}
OUTPUT
00:04:50,966 ERROR [Engine]
[org.apache.catalina.connector.warp.WarpConfigurationHandler] +++
MD_CONTEXT_OUTPUT: null +++
00:04:50,966 ERROR [Engine]
[org.apache.catalina.connector.warp.WarpConfigurationHandler] +++_MD_+++
Error deploying web ap
This must be just about my 5th posting on this subject. Maybe this time
I´ll have more luck :-).
Any hints at all would be of great help!!
bye Michael Delamere
___
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?
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] Re: JBossMQ Questions
Hi Hiram I think you might be confused because the JMSServer supports stateless connection protocols such as RMI. So, this means is that the JMSServer does not keep track of the connections that are established with him. Once a client establishes a connection with the server, he passes a ConnectionToken object allong with every request he makes to the server. The ConnectionToken holds enough info for the server to identify from which connection the request is comming from and how to send send data asynchronously to that connection. Now in the case of the stateful transport protocols, such as the OIL and UIL, it would be possible to keep track of the connections since we have to manage the thread the reads input from the sockets. I can see us creating registing a new MBean for each connection that is accecpted. Or can we create an MBean which contains a list of connection created to reduce the list of MBeans ? Andy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 29-April-2002
Number of tests run: 585 Successful tests: 574 Errors:0 Failures: 11 [time of test: 29 April 2002 0:39 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] See http://lubega.com/testarchive/ibm_jdk13_20010626 for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ 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
[JBoss-dev] CVS HEAD ok
Just did my commits. Testsuite passes with flying colors. 0 errors. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] XAManagedConnection and Informix Problems
I am using the org.jboss.resource.adapter.jdbc.xa.XAManagedConnection (and related Factory) to load my Informix XA JDBC connections.Unfortunately I am consistently getting XAExceptions, of the XAER_OUTSIDE variety. I have tracked the problem down to whatI think is an Informix Driver bug, but I was wondering if we should patch the JBoss transaction manager to correct for . Here's the issue: If a connection is used in local-transaction mode, the autocommit is set to false, and the user fails to call commit or rollback prior to closing the connection, then the connection is put back into the pool with the local transaction still open. Now, if that connection is used later within a global transaction, I get the XAException. I say that this is an Informix bug because I think most JDBC vendors automatically commit on closing within local transactions. The question is, should we put in a call to commit for all closes outside of a global transaction? The code is simple, but can you think of any negative repercussions if we do this? Thanks -Larry
[JBoss-dev] Multi invokers per container committed
JBoss 3.1 (CVS-HEAD) now has the ability to bind multiple invokers per EJB container. This means that one EJB container can serve up requests from IIOP, RMI, SOAP, your-protocol-here all at the same time. Also, if your EJBs are configured correctly in jboss.xml Beans accessed through bean ejb-refs will automatically and transparently use the correct protocol. Meaning, if you start off on IIOP, you'll stay on IIOP (unless the call is colocated). There have been some fundamental changes to configuration: 1. container-configuration no longer has client-interceptors defined within it. A new invoker to proxy factory binding has the client-interceptor definitions for each proxyfactory/invoker binding combo. 2. Also, container-invoker configuration tag has been removed from container-configuration. 3. jdk1.2.2 support has been removed from standardjboss.xml 4. THere are no more Clustered container-configuration definitions in standardjboss.xml. They're no longer needed Let's take a look at the new standardjboss.xml: jboss invoker-proxy-bindings invoker-proxy-binding nameentity-rmi-invoker/name invoker-mbeanjboss:service=invoker,type=jrmp/invoker-mbean proxy-factoryorg.jboss.proxy.ejb.ProxyFactory/proxy-factory proxy-factory-config client-interceptors home interceptororg.jboss.proxy.ejb.HomeInterceptor/interceptor interceptororg.jboss.proxy.SecurityInterceptor/interceptor interceptororg.jboss.proxy.TransactionInterceptor/interceptor interceptororg.jboss.invocation.InvokerInterceptor/interceptor /home bean interceptororg.jboss.proxy.ejb.EntityInterceptor/interceptor interceptororg.jboss.proxy.SecurityInterceptor/interceptor interceptororg.jboss.proxy.TransactionInterceptor/interceptor interceptororg.jboss.invocation.InvokerInterceptor/interceptor /bean list-entity interceptororg.jboss.proxy.ejb.ListEntityInterceptor/interceptor interceptororg.jboss.proxy.SecurityInterceptor/interceptor interceptororg.jboss.proxy.TransactionInterceptor/interceptor interceptororg.jboss.invocation.InvokerInterceptor/interceptor /list-entity /client-interceptors /proxy-factory-config /invoker-proxy-binding ... The invoker-proxy-binding is a description of the binding between an Invoker and the EJB proxy factory. It also contains the Proxy Factory's configuration. For RMI ejbs, proxy-factory-config contains a list of client-interceptors. If you look at the message-driven-bean invoker-proxy-factory binding, you'll see that the proxy-factory-config contains configuration for setting up JMS. invoker-proxy-binding namemessage-driven-bean/name invoker-mbeandefault/invoker-mbean proxy-factoryorg.jboss.ejb.plugins.jms.JMSContainerInvoker/proxy-factory proxy-factory-config JMSProviderAdapterJNDIDefaultJMSProvider/JMSProviderAdapterJNDI ServerSessionPoolFactoryJNDIStdJMSPool/ServerSessionPoolFactoryJNDI MaximumSize15/MaximumSize MaxMessages1/MaxMessages OptimizedTrue/Optimized MDBConfig ReconnectIntervalSec10/ReconnectIntervalSec DLQConfig DestinationQueuequeue/DLQ/DestinationQueue MaxTimesRedelivered10/MaxTimesRedelivered TimeToLive0/TimeToLive /DLQConfig /MDBConfig /proxy-factory-config /invoker-proxy-binding Now, to actually see what the new multi-invokers can do, take a look at .../testsuite/src/main/org/jboss/test/invokers and .../testsuite/src/resources/invokers/META-INF. Let's examine the ejb-jar.xml file and jboss.xml file for this test in the t estsuite. ejb-jar.xml: entity descriptiona simple bean managed entity bean/description ejb-nameSimpleBMP/ejb-name homeorg.jboss.test.invokers.interfaces.SimpleBMPHome/home remoteorg.jboss.test.invokers.interfaces.SimpleBMP/remote ejb-classorg.jboss.test.invokers.ejb.SimpleBMPBean/ejb-class prim-key-classjava.lang.Integer/prim-key-class persistence-typeBean/persistence-type transaction-typeContainer/transaction-type reentrantfalse/reentrant /entity session descriptionA trival echo stateless session bean/description ejb-nameStatelessSession/ejb-name homeorg.jboss.test.invokers.interfaces.StatelessSessionHome/home remoteorg.jboss.test.invokers.interfaces.StatelessSession/remote ejb-classorg.jboss.test.invokers.ejb.StatelessSessionBean/ejb-class session-typeStateless/session-type transaction-typeContainer/transaction-type ejb-ref ejb-ref-nameejb/SimpleBMP/ejb-ref-name ejb-ref-typeEntity/ejb-ref-type homeorg.jboss.test.invokers.interfaces.SimpleBMPHome/home
[JBoss-dev] IIOP is broken
IIOP is broken for now. I've turned it off until I can fix it. Sorry, but I wanted to get my commits in for multi-invokers before my code diverged too much from the mainline. I'll be working on IIOP for the next couple of days to get it working. Sorry and regards, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Multi invokers per container committed
FYI, Forgot to say that this new change also allows you to define multiple client-proxy bindings per EJB container. So an invoker-proxy-binding could use the same invoker, but different client-interceptors. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Sunday, April 28, 2002 8:14 PM To: Jboss-Dev Subject: [JBoss-dev] Multi invokers per container committed JBoss 3.1 (CVS-HEAD) now has the ability to bind multiple invokers per EJB container. This means that one EJB container can serve up requests from IIOP, RMI, SOAP, your-protocol-here all at the same time. Also, if your EJBs are configured correctly in jboss.xml Beans accessed through bean ejb-refs will automatically and transparently use the correct protocol. Meaning, if you start off on IIOP, you'll stay on IIOP (unless the call is colocated). ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XAManagedConnection and Informix Problems
I need to think about this a little more, but if we fix it the fix should be in the jca wrapper, not the tx manager. Not having yet thought about it more, I wonder if the spec-compliant jca autocommit behavior would help: in the absence of a explicit local tx or xa tx, all operations are performed in their own automatic tx. Hmm, maybe, maybe not. The local wrapper I just wrote jumps through some hoops to provide this autocommit behavior. Is the problem that you (a) actually want autocommit behavior outside an explicit transaction? Or that (b) you want to (implicitly) start a local transaction and have it committed for you when you start an xa tx? I think (a) is covered by the jca spec-compliant behavior, and I think (b) is an error on your application's part. What do you think? BTW the xa wrapper needs replacing almost as much as the local one did. I suspect the local wrapper can mostly be reused, but haven't looked. thanks david jencks On 2002.04.28 20:05:45 -0400 Larry Sanderson wrote: I am using the org.jboss.resource.adapter.jdbc.xa.XAManagedConnection (and related Factory) to load my Informix XA JDBC connections. Unfortunately I am consistently getting XAExceptions, of the XAER_OUTSIDE variety. I have tracked the problem down to what I think is an Informix Driver bug, but I was wondering if we should patch the JBoss transaction manager to correct for . Here's the issue: If a connection is used in local-transaction mode, the autocommit is set to false, and the user fails to call commit or rollback prior to closing the connection, then the connection is put back into the pool with the local transaction still open. Now, if that connection is used later within a global transaction, I get the XAException. I say that this is an Informix bug because I think most JDBC vendors automatically commit on closing within local transactions. The question is, should we put in a call to commit for all closes outside of a global transaction? The code is simple, but can you think of any negative repercussions if we do this? Thanks -Larry !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META http-equiv=Content-Type content=text/html; charset=iso-8859-1 META content=MSHTML 6.00.2715.400 name=GENERATOR STYLE/STYLE /HEAD BODY bgColor=#ff DIVFONT face=Arial size=2I am using the org.jboss.resource.adapter.jdbc.xa.XAManagedConnection (and related Factory) to load my Informix XA JDBC connections.nbsp;nbsp;/FONTFONT face=Arial size=2Unfortunately I am consistently getting XAExceptions, of the XAER_OUTSIDE variety.nbsp; I have tracked the problem down to whatnbsp;I think is an Informix Driver bug, but I was wondering if we should patch the JBoss transaction manager to correct for ./FONT/DIV DIVFONT face=Arial size=2/FONTnbsp;/DIV DIVFONT face=Arial size=2Here's the issue:nbsp; If a connection is used in local-transaction mode, the autocommit is set to false, and the user fails to call commit or rollback prior to closing the connection, then the connection is put back into the pool with the local transaction still open.nbsp; Now, if that connection is used later within a global transaction, I get the XAException./FONT/DIV DIVFONT face=Arial size=2/FONTnbsp;/DIV DIVFONT face=Arial size=2I say that this is an Informix bug because I think most JDBC vendors automatically commit on closing within local transactions.nbsp; The question is, should we put in a call to commit for all closes outside of a global transaction?nbsp; The code is simple, but can you think of any negative repercussions if we do this?/FONT/DIV DIVFONT face=Arial size=2/FONTnbsp;/DIV DIVFONT face=Arial size=2Thanks/FONT/DIV DIVFONT face=Arial size=2/FONTnbsp;/DIV DIVFONT face=Arial size=2-Larry/FONT/DIV/BODY/HTML ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CustomSocketsUnitTestCase muti-run failures
As it is packaged now, the org/jboss/test/jrmp/test/CustomSocketsUnitTestCase cannot be run more than once because it includes the custom RMI socket factories it uses in the deployment package. Because of how the RMI subsystem tracks socket factory uniqueness(it considers the factory class loader), this test will always fail on redeployment with an address in use bind error. We would need a class loader cache service into which the classes that need to be consistent across deployments are loaded in order to allow this test to run multiple times. That might be an interesting service and have other applications, but its not something I want to get into for the initial 3.0 release. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 29-April-2002
Number of tests run: 585 Successful tests: 577 Errors:8 Failures: 0 [time of test: 29 April 2002 2:43 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1_02a-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/blackdown_jdk131_02_native for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ 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
[JBoss-dev] Automated JBoss Testsuite Results: 29-April-2002
Number of tests run: 585 Successful tests: 582 Errors:0 Failures: 3 [time of test: 29 April 2002 4:1 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-02a-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/blackdown_jdk131_02_green for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XAManagedConnection and Informix Problems
On 2002.04.28 23:08:53 -0400 Larry Sanderson wrote: Messages inlined... likewise Not having yet thought about it more, I wonder if the spec-compliant jca autocommit behavior would help: in the absence of a explicit local tx or xa tx, all operations are performed in their own automatic tx. Hmm, maybe, maybe not. The local wrapper I just wrote jumps through some hoops to provide this autocommit behavior. Is the problem that you (a) actually want autocommit behavior outside an explicit transaction? Or that (b) you want to (implicitly) start a local transaction and have it committed for you when you start an xa tx? I think (a) is covered by the jca spec-compliant behavior, and I think (b) is an error on your application's part. I think I want (a) - I know I don't want (b). GOOD! The problem arrises when I use an XA resource outside of a global tx. (i.e., mark an EJB method NOT_SUPPORTED, and explicitly use setAutoCommit(), commit() and rollback() on my XA JDBC connection). What are the rules regarding local tx access of XA aware resources? According to the JDBC 3.0 spec, this use should be allowed, but I don't know how it fits in with JCA. This usage is failing for me when I fail to explicitly commit or rollback my local tx. I would imagine that these tx should either be committed or rolled back by the server? Maybe not. Regardless, when the application closes a pooled resource, that resource should be in a valid state for the next access. This is where I think my Informix drivers are failing. What do you think? I don't know - does the JCA deal with any of these issues in a definitive way? I thought so until I started listing cases;-) I agree that the connection should be usable or discarded after you close the handle. I'm not sure what to do if you close a handle after doing some work but before committing. I lean towards rollback rather than commit, but resetting autocommit to true should commit outstanding work... I'll have to read the spec some more. Anyway, for outside a tx work from an ejb I think you want autocommit behavior. david -Larry ___ 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] CustomSocketsUnitTestCase muti-run failures
I think we need something more global. What I am thinking of is a dynamic extension of the server lib directory. A deployment package identifies a jar as being an extension jar and it has a version. If a jar with the same version exists in the extension cache, the package jar is ignored, else it is added to the extension cache. A jar needs to be explicitly removed from the extension cache. Removal is not tied to the original deployment package. The class loader for the extension cache is the parent class loader of every deployment unit, and it in turns delegates to server class loader. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, April 28, 2002 7:54 PM Subject: Re: [JBoss-dev] CustomSocketsUnitTestCase muti-run failures We might be able to finally find a use for the local directory feature marc insisted I put in. Something copied into a local directory are just left there forever, not undeployed. So perhaps an mbean could set up and add a classloader for the jars in the local directory from the package. We'd just need to make sure the classloader isn't removed when the package is undeployed. david jencks On 2002.04.28 20:58:55 -0400 Scott M Stark wrote: As it is packaged now, the org/jboss/test/jrmp/test/CustomSocketsUnitTestCase cannot be run more than once because it includes the custom RMI socket factories it uses in the deployment package. Because of how the RMI subsystem tracks socket factory uniqueness(it considers the factory class loader), this test will always fail on redeployment with an address in use bind error. We would need a class loader cache service into which the classes that need to be consistent across deployments are loaded in order to allow this test to run multiple times. That might be an interesting service and have other applications, but its not something I want to get into for the initial 3.0 release. Scott Stark Chief Technology Officer JBoss Group, LLC ___ 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
[JBoss-dev] Automated JBoss Testsuite Results: 29-April-2002
Number of tests run: 585 Successful tests: 576 Errors:8 Failures: 1 [time of test: 29 April 2002 5:35 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_jdk131 for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 29-April-2002
Number of tests run: 578 Successful tests: 568 Errors:9 Failures: 1 [time of test: 29 April 2002 7:8 GMT] [java.version: 1.3.1_02] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_02-b02] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_jdk131_02 for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
