July 2007 - jboss-dev-forums - Jboss List Archives

[Design of AOP on JBoss (Aspects/JBoss)] - New AOP ClassLoading tests in ASIntegration

by adrian＠jboss.org

I've created some AOP classloading tests in the asintegration project that show my current sticking point. The basic problem is incorrect use of the TCL. These are the "simple tests" where I've created a hacked versioned of the test that works if I play around with the TCL "randomly". :-) Some of them work without hacking. For interest, I also created a more complex test which show something about about where I want to get to. This fails even when hacking the TCL, the problem is a ClassCastException due it using the wrong classes/classloader for other reasons. NOTE: None of these use the "JBoss5Integration" which I haven't created yet. These are all with the ScopedClassPool default implementation (and other places in AOP using the wrong classloader). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067543#4067543 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067543

17 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Why bother with APR?

by timfox

"david.lloyd(a)jboss.com" wrote : "remy.maucherat(a)jboss.com" wrote : Actually, I think NIO is pointless. | | I didn't ask, "Who here thinks NIO is pointless". I asked if there were any good benchmarks comparing NIO to APR in terms of performance. | | I've also heard things like "APR is more flexible", but I haven't seen any information to back that up either. I believe the RHM team compared NIO (using Apache MINA) to Apache APR and also to asynchronous IO using direct Linux OS calls (i.e. not going through the APR abstraction layer). I believe the direct hooks gave the best performance, NIO was pretty good, and APR not so good due to the overhead of having to find a common API over all OSs. Sorry for the vaguities, but this is what I remember them mentioning. Don't know if their findings were correct or not. BTW we (JBM) definitely need NIO for handling large number of connections. APR is a "nice to have" if it gives radically better performance than NIO, but I'm not particularly bothered about it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067537#4067537 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067537

17 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: AnnotatedElementMetaDataLoader missing impl

by adrian＠jboss.org

There's lots of stuff "missing" or at least NOT TESTED. :-) http://jira.jboss.com/jira/browse/JBMICROCONT-70 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067531#4067531 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067531

17 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - JBMICROCONT-181 & ManagedDeployments

by scott.stark＠jboss.org

I just checked in the current direction I'm heading in terms of updating the contract for deployer layer in terms of management views. The top level management view is a ManagedDeployment containing ManagedComponents. The role of the existing ManagedObject is not explicit in these views. Its more of an implementation detail around ManagedPropertys being connected to a DeploymentUnit metadata attachment instance. The existing DeployerClient.getManagedObjects methods should be dropped in favor of the new DeployerClient.getManagedDeployment method. Likewise, the ManagedObjectCreator should be dropped in favor of the ManagedDeploymentCreator/ManagedComponentCreator interfaces. What I'm currently doing is working through the use cases the existing ProfileServiceUnitTestCase has as well as the "TODO JBMICROCONT-181 Critique" comment Adrian has in the ManagedObjectCreator. I believe that we will have a standard ManagedDeploymentCreator implementation that uses the org.jboss.managed.api.annotation.* annotations to build the ManagedDeployment/ManagedComponent instances by parsing the DeploymentUnit attachments to identify what makes up the management interface. I also see that this could be augmented by deployers providing ManagedComponentCreators to deal with component properties that cannot adequately be described via annotations. Right now I'm working on creating a DeployerManagedDeploymentUnitTestCase that illustrates the logic for a datasource(s) type of deployment. Let me know if there is a big disconnect with the api I checked in and this direction. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067530#4067530 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067530

17 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Why bother with APR?

by david.lloyd＠jboss.com

"remy.maucherat(a)jboss.com" wrote : Actually, I think NIO is pointless. I didn't ask, "Who here thinks NIO is pointless". I asked if there were any good benchmarks comparing NIO to APR in terms of performance. I've also heard things like "APR is more flexible", but I haven't seen any information to back that up either. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067501#4067501 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067501

17 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Why bother with APR?

by mladen.turk＠jboss.com

Also speaking about performance: http://labs.jboss.com/file-access/default/members/jbossweb/freezone/index... There are lots of other nice looking images if you are interested :) I didn't publish them, just because I don't think the speed itself is that important. I agree that if some concepts from APR backported to NIO would be very valuable. Especially the fast non-blocking/blocking transition. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067487#4067487 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067487

17 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Why bother with APR?

by remy.maucherat＠jboss.com

Actually, I think NIO is pointless. First, the API is more complex and not GC friendly, but more importantly, APR is already in production pretty much everywhere inside httpd. OTOH, NIO is implemented as a bunch of native code inside the JVM, so it results in having more native code, and it's also more difficult to maintain (if you run into an NIO bug, there's no way to fix it except to update the whole JVM). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067485#4067485 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067485

17 years, 6 months

1
0
0 / 0

[Design of JBoss Wiki] - Re: Portal 2.6 support...

by thomas.heute＠jboss.com

Sign the petition for 2.6 support of the Wiki portlet (just kidding) ;) Or wait a bit By the way JBoss Portal 2.6.1 is out and will help JBoss Wiki to run on JBoss AS 4.2.x View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067418#4067418 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067418

17 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Why bother with APR?

by mladen.turk＠jboss.com

The major usage of APR is to provide a high concurrency for Servlet like engines changing the connection model from thread/connection to thread/request beyond many others like OS sendfile support etc. Comparing NIO to that model gives you few times performance decrease over the APR. Last time I compared Glassfish with Tomcat+APR it was 10 times (!) slower. His other document http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-299... says on slide 20 that Tomcat is still 10% faster then Grizzly (even without APR) Nevertheless, benchmarks are like assholes. Everyone has one. Regards, Mladen View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067413#4067413 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067413

17 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Why bother with APR?

by david.lloyd＠jboss.com

I've been having an email discussion with various parties about NIO versus APR. I'm thinking specifically in terms of Remoting, but I think that the discussion can be more generally applied. What I want to know is, why we should bother (with a modern JVM) to use APR when NIO is standard and built in. Specifically, I have not found any published benchmarks about the subject, except for that published by Jean-Francois Arcand here: http://weblogs.java.net/blog/jfarcand/archive/2006/03/can_a_grizzly_r.html His findings seem to be that NIO performs as well as APR in Coyote, if not better. Are there any counter-benchmarks out there? Google didn't seem to turn up anything relevant. And, how big a margin is needed before it becomes worth it to use APR? Personally I feel it would be far more productive, not to mention better for the community, to put our efforts towards working with the EG to improve NIO, if it is deficient in some way. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067405#4067405 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067405

17 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2007