[JBoss-dev] [HEAD] Does URLDeploymentScanner with DeploymentCache work?
Hello, I would like to implement my own custom MainDeployer. MyMainDeployer mbean will delagete calls to MainDeployer mbean. The question is what methods do I need provide in MyMainDeployer to make a fully functional MainDeployer. I thought it should be only the methods from Deployer interface (deploy, undeploy, isDeployed). But after looking into URLDeploymentScanner source code I'm not sure about it. First URLDeploymentScanner calls interface method deploy on Deployer --- deployer = (Deployer) MBeanProxy.create(Deployer.class, deployerName, server); ... deployer.deploy(du.url); --- And second URLDeploymentScanner calls method checkIncompleteDeployments which is implemented in MainDeployer mbean but not specifed in Deployer interface. --- getServer().invoke(getDeployer(), checkIncompleteDeployments, args, sig); --- So in my opinion URLDeploymentScanner depends on MainDeployer but it is possible in deployment descriptor specify another deployer (eg. DeploymentCache) and URLDeploymentScanner will not work. What are your experiences? Does replacing MainDeployer with DeploymentCache work and if yes, how it is possible? Thank you for any comments David Klimek -- http://www.sweb.cz/david.klimek --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Optimisation for proxy creation?
Hello, While digging in ProxyFactory (Branch_3_0) to solve some clustering issues/optimisations, I thought about the current proxy creation and maybe we should do something here: I think it is a hotspot. In getStatefulSessionEJBObject and getEntityEJBObject, each time we must return a proxy, we: 1 - create a context object 2 - assign some id, invoker, etc. to the context 3 - create a ClientContainer that holds the context 4 - load the interceptor chain and assigne the ClientContainer as the first element of the chain 5 - create a java proxy that holds the chain (i.e. the ClientContainer) Elements 1, 2, 3 and 5 could be ok in term of performance. Element 4 is not cheap. Loading the chain will iterate over the interceptor classes and create a new instance of the class and build the chain. Now we have two cases: A - it is a remote call B - it is a local call If it is a remote call, it first mean that we could cache this chain because it will be serialized (copied) anyway. But the next question is: what really changes between proxies? Only the Context (that holds the identity). Consequently, wouldn't be much more efficient (for remote call) to pre-marshall everything except the ClientContainer and the context so that when returning a proxy, we only have to serialize these two objects and not the whole thing. We would have: Java Proxy = ProxyHandler-ClientContainer = Marshalled chain+invoker+... |-- Context When the proxy is unmarshalled on the remote side, the ClientContainer starts by unmarshalling the chain (as the RMI subsystem do it currently) and complete the chain. If it is a local call, then the chain generation is ok as we use a pass-value semantic and each proxy must have its own copy of the chain. Question 1 (for local calls!): could we share *on the server* this chain between proxies of the *same* EJB. If that's the case, then it means that we wouldn't need to re-create this chain everytime. Now, I've only spoken about getStatefulSessionEJBObject and getEntityEJBObject. But now think about getEntityCollection! Its implementation does exactly that N times! = in CMP when you return a collection in-VM (by-reference) of, let's say 100 elements, we not only create 100 proxies, but we also create 4x100 interceptors instances that we plug together. Now imagine that our client-side interceptors can be shared for all proxies of the same EJB type (on the server). In this case, we would still have to build 100 proxies, but no interceptors at all: we would just have all ClientContainers target the same chain of interceptors. Conclusion, we should look at: - minimizing serialization work for remote calls - minimizing object creation for local calls Am I lost on the moon? Cheers, Sacha --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Optimisation for proxy creation?
Sure, this is something to try out to see how much of an improvement can be made. Start with entities as these are the most likely to be created frequently. I really doubt session proxy creation can be a hotspot as its just not a frequent event in a normal workflow. As for sharing interceptors, its a question of whether or not they have state. None currently do, but they could, for example an encryption key. We would have to have an attribute that defines whether the interceptor is stateless and if the entire stack for a container is stateless, it can be reused. Otherwise it has to be copied. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Sacha Labourey [EMAIL PROTECTED] To: Jboss-Dev [EMAIL PROTECTED] Cc: Scott M Stark [EMAIL PROTECTED]; Bill Burke [EMAIL PROTECTED] Sent: Saturday, January 11, 2003 1:12 AM Subject: Optimisation for proxy creation? Hello, While digging in ProxyFactory (Branch_3_0) to solve some clustering issues/optimisations, I thought about the current proxy creation and maybe we should do something here: I think it is a hotspot. In getStatefulSessionEJBObject and getEntityEJBObject, each time we must return a proxy, we: 1 - create a context object 2 - assign some id, invoker, etc. to the context 3 - create a ClientContainer that holds the context 4 - load the interceptor chain and assigne the ClientContainer as the first element of the chain 5 - create a java proxy that holds the chain (i.e. the ClientContainer) Elements 1, 2, 3 and 5 could be ok in term of performance. Element 4 is not cheap. Loading the chain will iterate over the interceptor classes and create a new instance of the class and build the chain. Now we have two cases: A - it is a remote call B - it is a local call If it is a remote call, it first mean that we could cache this chain because it will be serialized (copied) anyway. But the next question is: what really changes between proxies? Only the Context (that holds the identity). Consequently, wouldn't be much more efficient (for remote call) to pre-marshall everything except the ClientContainer and the context so that when returning a proxy, we only have to serialize these two objects and not the whole thing. We would have: Java Proxy = ProxyHandler-ClientContainer = Marshalled chain+invoker+... |-- Context When the proxy is unmarshalled on the remote side, the ClientContainer starts by unmarshalling the chain (as the RMI subsystem do it currently) and complete the chain. If it is a local call, then the chain generation is ok as we use a pass-value semantic and each proxy must have its own copy of the chain. Question 1 (for local calls!): could we share *on the server* this chain between proxies of the *same* EJB. If that's the case, then it means that we wouldn't need to re-create this chain everytime. Now, I've only spoken about getStatefulSessionEJBObject and getEntityEJBObject. But now think about getEntityCollection! Its implementation does exactly that N times! = in CMP when you return a collection in-VM (by-reference) of, let's say 100 elements, we not only create 100 proxies, but we also create 4x100 interceptors instances that we plug together. Now imagine that our client-side interceptors can be shared for all proxies of the same EJB type (on the server). In this case, we would still have to build 100 proxies, but no interceptors at all: we would just have all ClientContainers target the same chain of interceptors. Conclusion, we should look at: - minimizing serialization work for remote calls - minimizing object creation for local calls Am I lost on the moon? Cheers, Sacha --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666150 ] Cannot use discover for a HA-JNDI for another partition
Bugs item #666150, was opened at 2003-01-11 11:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=666150group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Sacha Labourey (slaboure) Summary: Cannot use discover for a HA-JNDI for another partition Initial Comment: If a JBoss service wants to lookup another service that is reference in the HA-JNDI service running in another HA-Partition, automatic discovery cannot be used and the only way to lookup this service is by using an explicit PROVIDER_URL string. Currently, when PROVIDER_URL is not specified, the NamingContext will try to use the local server if available or do a discoverServer otherwise, independently of any JNP_PARTITION_NAME parameter that could have been specified in the naming properties. The source complain can be found here (as well as a start of resolution): http://www.jboss.org/modules.php? op=modloadname=phpBB_14file=indexaction=viewt opictopic=269201 Work in progress. The fixed solution will most probably keep a table of (partition name = locally available HA- JNDI service) so that if the HA-JNDI service also runs locally, no network broadcast is necessary. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=666150group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666154 ] HA-Home not refreshed in JNDI
Bugs item #666154, was opened at 2003-01-11 11:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=666154group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Sacha Labourey (slaboure) Summary: HA-Home not refreshed in JNDI Initial Comment: When a clustered container starts, it creates its home proxy and binds it in JNDI. In the clustered case, this proxy contains: - the list of currently available target containers - the version id used to keep track of the evolution of the cluster topology. The hypothesis that was made at first when coding that, is that the JNDI server do *not* marshall the home proxy that is bound in JNDI so that when the list of target containers is updated, the proxy always contain the last available information (the proxy as a reference to the list). Nevertheless, it appears that the JNDI service *do* serialized content at binding time. Consequently, the target list available in the proxy is the one that was available at container start time. Consequently, when getting the home for the first time, the list may not be up-to-date anymore. This has two important consequences: 1) homes that are used only once may always make invocations against the same set of nodes 2) (more important) when the list of target contains a proxy to a *dead* node, when the clustered proxy is unserialized by RMI, the RMI subsystem attempts to contact that node (!!). If the instance is simply dead, that's ok because it will quickly receive an answer from the target OS (port not open), but if the *host* is not reachable (not only the service), then the socket will have to wait on TCP timeout which may be quite long!!! Work in progress. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=666154group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666157 ] Version ID not updated in clustered proxy
Bugs item #666157, was opened at 2003-01-11 11:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=666157group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Sacha Labourey (slaboure) Summary: Version ID not updated in clustered proxy Initial Comment: Proxies generated by EJB container never have their version id refreshed. Consequently, even if the target list received by a remote client is up-to-date, the version id is not and at the next call (i.e. for every first invocation), the (same) list of targets will be downloaded from the server (which use some bandwith, serialization, etc). Work in progress. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=666157group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-663859 ] Deadlock in shutdown hooks when interrupting startup
Bugs item #663859, was opened at 2003-01-07 09:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=663859group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Dave Marquard (lurp) Assigned to: Scott M Stark (starksm) Summary: Deadlock in shutdown hooks when interrupting startup Initial Comment: Steps to reproduce: While JBoss is starting up (i.e., deploying services, ejbs, etc.), hit Ctrl+C to halt the VM. About two thirds of the time a deadlock will happen in the shutdown hooks. JBoss version: 3.0.5rc1 JDK version: 1.4.1_01 OS: Windows XP The thread dump of the deadlock is attached. -- Comment By: Scott M Stark (starksm) Date: 2003-01-11 03:13 Message: Logged In: YES user_id=175228 This has been fixed for 3.0.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=663859group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665067 ] Managed Connection equals Null! Problems in JBOSS 3.0.3
Bugs item #665067, was opened at 2003-01-09 15:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=665067group_id=22866 Category: JBossCX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Michael Ukpong (michaelukpong) Assigned to: David Jencks (d_jencks) Summary: Managed Connection equals Null! Problems in JBOSS 3.0.3 Initial Comment: The .remove() method of some Entity beans I wrote and deployed in JBoss 3.0.0 is now throwing a Managed Connection = null exception in Jboss 3.0.3. I earlier noticed that these entities gave a you are not getting the semantics you expect warning (both in Jboss 3.0.0 and 3.0.3) but I ignored this warning in Jboss 3.0.0. Could this be the cause of the exception now thrown in Jboss 3.0.3? The funny thing is that if you keep looping on the remove (), where the number of iterations is the record length of the underlying table + 1, it eventually works! So its like the managed connection is restored after a certain number of failed attempts. What could this mean? Note that this remove() method is NOT called directly from a servlet, but through a stateless session bean. -- Comment By: David Jencks (d_jencks) Date: 2003-01-11 13:41 Message: Logged In: YES user_id=60525 Please try 3.0.5 and see if the problem is already fixed. How about some details or a test case? BMP or CMP? If BMP, are you holding the connection between method invocations or getting it each time you need it? Have you defined .equals in your entity? Have you marked the datasource as an unsharable resource? Thanks david jencks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=665067group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666150 ] Cannot use discover for a HA-JNDI for another partition
Bugs item #666150, was opened at 2003-01-11 11:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=666150group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Sacha Labourey (slaboure) Summary: Cannot use discover for a HA-JNDI for another partition Initial Comment: If a JBoss service wants to lookup another service that is reference in the HA-JNDI service running in another HA-Partition, automatic discovery cannot be used and the only way to lookup this service is by using an explicit PROVIDER_URL string. Currently, when PROVIDER_URL is not specified, the NamingContext will try to use the local server if available or do a discoverServer otherwise, independently of any JNP_PARTITION_NAME parameter that could have been specified in the naming properties. The source complain can be found here (as well as a start of resolution): http://www.jboss.org/modules.php? op=modloadname=phpBB_14file=indexaction=viewt opictopic=269201 Work in progress. The fixed solution will most probably keep a table of (partition name = locally available HA- JNDI service) so that if the HA-JNDI service also runs locally, no network broadcast is necessary. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=666150group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666157 ] Version ID not updated in clustered proxy
Bugs item #666157, was opened at 2003-01-11 11:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=666157group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Sacha Labourey (slaboure) Summary: Version ID not updated in clustered proxy Initial Comment: Proxies generated by EJB container never have their version id refreshed. Consequently, even if the target list received by a remote client is up-to-date, the version id is not and at the next call (i.e. for every first invocation), the (same) list of targets will be downloaded from the server (which use some bandwith, serialization, etc). Work in progress. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=666157group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666154 ] HA-Home not refreshed in JNDI
Bugs item #666154, was opened at 2003-01-11 11:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=666154group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Sacha Labourey (slaboure) Summary: HA-Home not refreshed in JNDI Initial Comment: When a clustered container starts, it creates its home proxy and binds it in JNDI. In the clustered case, this proxy contains: - the list of currently available target containers - the version id used to keep track of the evolution of the cluster topology. The hypothesis that was made at first when coding that, is that the JNDI server do *not* marshall the home proxy that is bound in JNDI so that when the list of target containers is updated, the proxy always contain the last available information (the proxy as a reference to the list). Nevertheless, it appears that the JNDI service *do* serialized content at binding time. Consequently, the target list available in the proxy is the one that was available at container start time. Consequently, when getting the home for the first time, the list may not be up-to-date anymore. This has two important consequences: 1) homes that are used only once may always make invocations against the same set of nodes 2) (more important) when the list of target contains a proxy to a *dead* node, when the clustered proxy is unserialized by RMI, the RMI subsystem attempts to contact that node (!!). If the instance is simply dead, that's ok because it will quickly receive an answer from the target OS (port not open), but if the *host* is not reachable (not only the service), then the socket will have to wait on TCP timeout which may be quite long!!! Work in progress. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=666154group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: Optimisation for proxy creation?
OK, I did some testing: from a client (not in-VM) on the same host, calling 100x findAll which returns 1000 EB from an In-Memory BMP. I implemented different solutions: 1) I preload the chain and reuse it 2) I preload the chain and if one of the interceptors is marked as stateless=false I dynamically add a new interceptor in front of the chain that contains a copy of the chain (in a MO) 3) I preload the whole chain and store it in a MO and I have a new ClientContainer implementation that do not take an Interceptor as parameter but an MO that contains the chain Time on my machines were something like: - default (no optimisation): 11 seconds - opt 1): 8 second - opt 2): 7-8 second - opt 3): 22 seconds!!! I don't understand why!!! For opt 3, may the problem is related to the fact that in the marshalled collection that is returned from findAll, all proxies do share the same chain, which is very good (bandwith!) for case 1 and 2 but maybe in case 3, as the content is inside a MO, each proxy will get its own byte[]. Don't know, just a quick 10'000 feet analysis. Implementation 2 is cool because it can work easily locally and remotly for stateless and stateful chains. I am pretty sure the number would be better if the client and server would be running on different hosts (because in my case, the total amount of client+server serialization was all on the same machine while with the optimisations, the server work is quite reduced). So, is 4 seconds out of 11 (35%) a sufficient improvment so that I commit the new files? Modifications are: - ProxyFactory updated - MarshallerInterceptor added N.B.: the tests-unit testsuite module target runs correctly with these modifications -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Scott M Stark Envoyé : samedi, 11 janvier 2003 10:51 À : Jboss-Dev Objet : [JBoss-dev] Re: Optimisation for proxy creation? Sure, this is something to try out to see how much of an improvement can be made. Start with entities as these are the most likely to be created frequently. I really doubt session proxy creation can be a hotspot as its just not a frequent event in a normal workflow. As for sharing interceptors, its a question of whether or not they have state. None currently do, but they could, for example an encryption key. We would have to have an attribute that defines whether the interceptor is stateless and if the entire stack for a container is stateless, it can be reused. Otherwise it has to be copied. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Sacha Labourey [EMAIL PROTECTED] To: Jboss-Dev [EMAIL PROTECTED] Cc: Scott M Stark [EMAIL PROTECTED]; Bill Burke [EMAIL PROTECTED] Sent: Saturday, January 11, 2003 1:12 AM Subject: Optimisation for proxy creation? Hello, While digging in ProxyFactory (Branch_3_0) to solve some clustering issues/optimisations, I thought about the current proxy creation and maybe we should do something here: I think it is a hotspot. In getStatefulSessionEJBObject and getEntityEJBObject, each time we must return a proxy, we: 1 - create a context object 2 - assign some id, invoker, etc. to the context 3 - create a ClientContainer that holds the context 4 - load the interceptor chain and assigne the ClientContainer as the first element of the chain 5 - create a java proxy that holds the chain (i.e. the ClientContainer) Elements 1, 2, 3 and 5 could be ok in term of performance. Element 4 is not cheap. Loading the chain will iterate over the interceptor classes and create a new instance of the class and build the chain. Now we have two cases: A - it is a remote call B - it is a local call If it is a remote call, it first mean that we could cache this chain because it will be serialized (copied) anyway. But the next question is: what really changes between proxies? Only the Context (that holds the identity). Consequently, wouldn't be much more efficient (for remote call) to pre-marshall everything except the ClientContainer and the context so that when returning a proxy, we only have to serialize these two objects and not the whole thing. We would have: Java Proxy = ProxyHandler-ClientContainer = Marshalled chain+invoker+... |-- Context When the proxy is unmarshalled on the remote side, the ClientContainer starts by unmarshalling the chain (as the RMI subsystem do it currently) and complete the chain. If it is a local call, then the chain generation is ok as we use a pass-value semantic and each proxy must have its own copy of the chain. Question 1 (for local calls!): could we share *on the server* this chain between proxies of the *same* EJB. If that's the case, then it means that we wouldn't need to re-create this chain everytime. Now, I've only
[JBoss-dev] Jboss JMX View Attributes
Hi jboss friends, please vote: based on the jmx specification a JMX Mbeant attribute can be each object. I want to implement the Attribute editing in the jboss jmx gui next days. You think it make sence to edit the attributes as a.) Primitive in the eclipse property sheet view. b.) with a may be over scaled complex object instance wizard. Thanks for your input. Stefan --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 11-January-2003
JBoss daily test results SUMMARY Number of tests run: 1012 Successful tests: 1006 Errors:5 Failures: 1 [time of test: 2003-01-11.12-12 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.3] See http://users.jboss.org/~starksm/Branch_3_0/2003-01-11.12-12 for details of this test. 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: LocalWrapperCleanupUnitTestCase Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: SimpleUnitTestCase Test:testSecureHttpInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.security.auth.login.LoginException Message: Missing users.properties file. - Suite: SimpleUnitTestCase Test:testLoginInitialContext(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.AuthenticationException Message: Failed to login using protocol=testLoginInitialContext - Suite: HttpsUnitTestCase Test:testHttpsURL(org.jboss.test.security.test.HttpsUnitTestCase) Type:error Exception: java.io.IOException Message: Failed to get SSLContext for TLS algorithm - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-666392 ] XML fixes
Patches item #666392, was opened at 2003-01-12 00:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376687aid=666392group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Ville Skyttä (scop) Assigned to: Nobody/Anonymous (nobody) Summary: XML fixes Initial Comment: Here's a patch containing multiple XML validity fixes for files in JBoss 3.0, basically just moving around things. The patch is against CVS Branch_3_0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376687aid=666392group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: Optimisation for proxy creation?
At this point I don't want this going into the 3.0.5 release. You can put it in after the release and include it in 3.2.0RC1 to get feedback. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Sacha Labourey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Scott M Stark [EMAIL PROTECTED] Sent: Saturday, January 11, 2003 8:42 AM Subject: RE: [JBoss-dev] Re: Optimisation for proxy creation? OK, I did some testing: from a client (not in-VM) on the same host, calling 100x findAll which returns 1000 EB from an In-Memory BMP. I implemented different solutions: 1) I preload the chain and reuse it 2) I preload the chain and if one of the interceptors is marked as stateless=false I dynamically add a new interceptor in front of the chain that contains a copy of the chain (in a MO) 3) I preload the whole chain and store it in a MO and I have a new ClientContainer implementation that do not take an Interceptor as parameter but an MO that contains the chain Time on my machines were something like: - default (no optimisation): 11 seconds - opt 1): 8 second - opt 2): 7-8 second - opt 3): 22 seconds!!! I don't understand why!!! For opt 3, may the problem is related to the fact that in the marshalled collection that is returned from findAll, all proxies do share the same chain, which is very good (bandwith!) for case 1 and 2 but maybe in case 3, as the content is inside a MO, each proxy will get its own byte[]. Don't know, just a quick 10'000 feet analysis. Implementation 2 is cool because it can work easily locally and remotly for stateless and stateful chains. I am pretty sure the number would be better if the client and server would be running on different hosts (because in my case, the total amount of client+server serialization was all on the same machine while with the optimisations, the server work is quite reduced). So, is 4 seconds out of 11 (35%) a sufficient improvment so that I commit the new files? Modifications are: - ProxyFactory updated - MarshallerInterceptor added N.B.: the tests-unit testsuite module target runs correctly with these modifications --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean persistence?
lördagen den 11 januari 2003 kl 19.42 skrev Dain Sundstrom: anyone working on it? When do you expect to In some sidesteps projects here ... it is easy when hsqldb is up ... or in a grid ... when one master is up to have configurations federated. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 3.0.5
Its been integrated. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Corby Page [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 07, 2003 2:16 PM Subject: [JBoss-dev] JBoss 3.0.5 Can we please apply Patch #621702 to the 3_0 branch in time for the 3.0.5 release? https://sourceforge.net/tracker/?func=detailaid=621702group_id=22866atid=376687 Thanks, Corby --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
