[Design of POJO Server] - Re: JBAS-6104; slow Seam deployments
by shane.bryzak＠jboss.com
Deployment seems to be fine now, as Pete said. The issue is when you hit a Seam application for the first time, a whole bunch of stuff needs to be initialised. I did some deeper profiling, and here's a sample of some of the places where the most calls are being made to VirtualFileURLConnection.getInputStream:
25.2% - 90,069ms - 335 inv. com.sun.facelets.util.Classpath.searchFromURL
10.0% - 35,665ms - 11 inv. com.sun.facelets.compiler.TagLibraryConfig.create
1.0% - 3,461ms - 1 inv. org.ajax4jsf.resource.JarResource.getResourceAsStream (called from TemplateCSSRendered.getTemplate)
13.1% - 46,692ms - 11 inv. org.jboss.seam.deployment.SeamDeploymentProperties.addPropertiesFromResourceBundle (called indirectly from HotDeploymentStrategy.getDeploymentHandlers)
12.9% - 46,115ms - 11 inv. org.jboss.seam.deployment.SeamDeploymentProperties.addPropertiesFromResourceBundle (called indirectly from DeploymentStrategy.getDeploymentHandlers - initialized by WarRootDeploymentStrategy)
12.7% - 45,284ms - 11 inv. org.jboss.seam.deployment.SeamDeploymentProperties.addPropertiesFromResourceBundle (called indirectly from DeploymentStrategy.getScanner)
12.6% - 45,042ms - 11 inv. org.jboss.seam.deployment.SeamDeploymentProperties.addPropertiesFromResourceBundle (called indirectly from DeploymentStrategy.getScanner, initialized by WarRootDeploymentStrategy.scan)
The percentages are the fraction of total CPU time taken during application initialization for the first request hitting a Seam application, in this case seam-booking. Looking at where most of the calls are being made from, we can possibly do some optimization in SeamDeploymentProperties (I'll start investigating this next) however even with some optimizations here the fact remains that vfs still seems very under-performant.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184705#4184705
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184705
15 years, 10 months
[Design of EJB 3.0] - Re: Reintroducing Asynchronous Support
by ALRubinger
"david.lloyd(a)jboss.com" wrote : Does EJB 3.1 specify use of java.util.concurrent.Future?
Yes.
"EJB 3.1 Core Specification 4.5.2" wrote : The client return type of an asynchronous method is either void or java.util.concurrent.Future, where V is the result value type.
"david.lloyd(a)jboss.com" wrote : I only ask because I've discovered a couple of problems with it for remove invocation use that I ran into when working on Remoting...
Clearly I'd like to take advantage of your experience here, but not at the expense of confusing users with more nonstandard APIs. So perhaps I can take a hybrid approach.
"david.lloyd(a)jboss.com" wrote : 1) It is not entirely clear if .cancel() should block until it knows whether or not the cancel succeeded. The designers clearly did not expect there to be any time lag between the invocation of the .cancel() method and the ability to determine the result. With remote invocation one wishes to be able to cancel asynchronously; you could always return false but the docs clearly state that false means "the task could not be cancelled, typically because it has already completed normally".
Though not explicitly stated, to fulfill the JavaDoc's requirements of j.u.c.Future, we'd have to block until we knew whether the operation would be cancelled.
In the case of EJB, a call to "cancel" is a request by the client. The bean must be written to support cancellation, and "mayInterruptIfRunning" would have to be ignored as that context is not available to the bean provider to check.
"EJB 3.1 Core Spec, 3.5.2.2" wrote : A client can request that an asynchronous invocation be cancelled by calling the Future.cancel(boolean mayInterruptIfRunning) method. A Bean Developer can check whether the client has requested cancellation by calling the SessionContext.isCancelled() method within the context of the asynchronous method.
Now, if the bean provider chooses to honor the request to cancel, there's a missing mechanism to let the client to know whether the request was fulfilled. So what should be the proper return value of "cancel()"?
I'll pose this question to the JSR318 EG.
"david.lloyd(a)jboss.com" wrote : 2) It should not be the client's decision whether or not the server interrupts the task thread. Nevertheless, .cancel() accepts a boolean parameter which indicates whether the task should be cancelled. It's clear that this interface was meant to be used from code that has authority over the thread pool which is executing the task.
>From the spec above, this flag is lost and not available in SessionContext anyway.
"david.lloyd(a)jboss.com" wrote : 3) The API itself lends very little power to the end-user (no methods to await interruptibly, no way to receive failure or cancellation notifications other than catching exceptions).
|
| 4) There is no mechanism for users to register a callback which can be invoked when the operation is done.
True story. The implementation I'm looking to replace/simplify also provides blocking to "get" via the Oswego concurrent utils. And only the XNIO impl provides for callbacks.
At first glance I'd approach this by using a XNIO Future impl under the hood, and wrapping w/ j.u.c.Future to return to the client. This would also pave the way to provide for more than one async interface to the client, who could choose his view (XNIO, j.u.c, etc). I'm weary of drawing in another dependency unless it's already brought into AS somewhere?
Then again, eventually we're gonna need Remoting 3 which depends on XNIO, so worst case is we'd be tacking on this library prematurely...
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184650#4184650
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184650
15 years, 10 months