[Design of EJB 3.0] - Re: Reintroducing Asynchronous Support
by david.lloyd＠jboss.com
Does EJB 3.1 specify use of java.util.concurrent.Future? 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:
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".
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.
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.
For Remoting and XNIO I ended up creating a new future interface (within XNIO) specifically designed for I/O and remote invocation operations:
http://anonsvn.jboss.org/repos/xnio/xnio-base/trunk/api/src/main/java/org...
In addition I provide abstract implementations, and a utility method to create a java.util.concurrent.Future for interfaces which require it. Semantically, the wrapper Future will ignore the "interruptIfRunning" parameter to .cancel(), and .cancel() blocks until it is known whether the operation was successfully cancelled.
I'm not saying you should introduce an XNIO or Remoting 3 dependency - well, unless you want to :) - but I think it's safe to say that java.util.concurrent.Future isn't an acceptable mechanism for getting the result of a remote invocation. Been there, tried that. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184529#4184529
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184529
17 years, 2 months
[Design of POJO Server] - Re: JBAS-6104; slow Seam deployments
by shane.bryzak＠jboss.com
Ok I've done a clean build with latest trunk and I'm afraid to say there hasn't been much of an improvement. I've included part of the call tree in case it's some help.
53.0% - 152 s - 1 inv. org.ajax4jsf.application.AjaxViewHandler.renderView
50.3% - 144 s - 1 inv. org.ajax4jsf.application.ViewHandlerWrapper.renderView
50.3% - 144 s - 1 inv. javax.faces.application.ViewHandler.renderView
42.4% - 122 s - 527 inv. org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getInputStream
41.5% - 119 s - 527 inv. org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getVirtualFile
41.5% - 119 s - 527 inv. org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.resolveVirtualFile
41.3% - 118 s - 527 inv. org.jboss.virtual.VFS.findChild
41.3% - 118 s - 527 inv. org.jboss.virtual.plugins.context.AbstractVFSContext.getChild
41.2% - 118 s - 373 inv. org.jboss.virtual.plugins.context.DelegatingHandler.getChild
41.2% - 118 s - 373 inv. org.jboss.virtual.plugins.context.zip.ZipEntryHandler.getChild
41.2% - 118 s - 373 inv. org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.structuredFindChild
24.9% - 71,681 ms - 536 inv. org.jboss.virtual.plugins.context.zip.ZipEntryHandler.createChildHandler
16.2% - 46,689 ms - 60 inv. org.jboss.virtual.plugins.context.DelegatingHandler.getChild
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184489#4184489
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184489
17 years, 2 months
[Design of EJB 3.0] - Re: Kill Default Remote Binding if 1+ @RemoteBinding is spec
by ALRubinger
"wolfc" wrote : What happens if:
| @Stateless(name="MyBean")
| | @Local(MyLocal.class)
| | @Remote(MyRemote.class)
| | @RemoteBinding(jndiBinding="MyBean")
| | class MyBean{...}
I thought of something similar to this after going to bed last night.
We need to reserve the namespace used by default bindings. Your example above shows a collision:
MyBean - Explicit from MyBean
| MyBean/local - Default Local Business
...but also there's the stuff under the namespace:
MyBean/remote-MyRemote.class
So the rule's gotta be twofold:
* If at least 1 @RemoteBinding is specified, skip binding of default remote business location
* @LocalBinding and @RemoteBinding must not interfere with the namespace
This is all dependent upon the binding namespace; I'm assuming a JAR packaging above. In an EAR this all becomes prefixed w/ "[earName/".
Keep in mind that the idea of a "namespace" is provided by our implementation details ie. BasicJndiBindingPolicy, and other JNDI Binding Policies may not have this restriction. So we cannot validate against the namespace itself as a validation check; we'd have to validate all of the targeted JNDI bindings against each other to check for conflicts. Skipping the validation check just throws a CCE from Context.bind, which doesn't tell the user too much.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184479#4184479
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184479
17 years, 2 months
[Design of JBoss Transaction Services] - Can't redeploy the transaction manager
by adrian＠jboss.org
If you boot JBoss then do
touch transaction-jboss-beans.xml
you get the following errors which suggests that stopping the tx service
is not properly tidying up after itself.
| 14:06:34,765 INFO [TransactionManagerService] Stopping transaction recovery manager
| 14:06:34,953 INFO [TransactionManagerService] JBossTS Transaction Service (JTA version) - JBoss Inc.
| 14:06:34,954 INFO [TransactionManagerService] Setting up property manager MBean and JMX layer
| 14:06:34,958 FATAL [TransactionManagerService] Failed to create and register Propagation Context Manager
| javax.naming.NameAlreadyBoundException: TransactionPropagationContextImporter
| at org.jnp.server.NamingServer.bind(NamingServer.java:202)
| at org.jnp.interfaces.NamingContext.bind(NamingContext.java:625)
| at org.jnp.interfaces.NamingContext.bind(NamingContext.java:586)
| at javax.naming.InitialContext.bind(InitialContext.java:359)
| at com.arjuna.ats.jbossatx.jta.TransactionManagerService.bindRef(TransactionManagerService.java:683)
| at com.arjuna.ats.jbossatx.jta.TransactionManagerService.create(TransactionManagerService.java:191)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
| at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
| at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
| at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
| at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
| at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
| at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
| at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
| at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
| at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:124)
| at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
| at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1410)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1128)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1149)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1069)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:752)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:541)
| at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:290)
| at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:221)
| at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
| at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280)
| at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135)
| at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65)
| at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:142)
| at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166)
| at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
| at java.lang.Thread.run(Thread.java:595)
| 14:06:34,959 INFO [TransactionManagerService] Initializing recovery manager
| 14:06:34,960 INFO [TransactionManagerService] Recovery manager configured
| 14:06:34,960 INFO [TransactionManagerService] Binding TransactionManager JNDI Reference
| 14:06:34,971 INFO [TransactionManagerService] Starting transaction recovery manager
| 14:06:34,971 ERROR [AbstractKernelController] Error installing to Start: name=TransactionManager state=Create
| java.lang.IllegalThreadStateException
| at java.lang.Thread.start(Thread.java:571)
| at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.start(RecoveryManagerImple.java:210)
| at com.arjuna.ats.arjuna.recovery.RecoveryManager.startRecoveryManagerThread(RecoveryManager.java:219)
| at com.arjuna.ats.jbossatx.jta.TransactionManagerService.start(TransactionManagerService.java:252)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
| at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
| at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
| at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
| at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
| at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
| at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
| at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
| at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
| at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:124)
| at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
| at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1410)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1128)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1149)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1069)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:752)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:541)
| at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:290)
| at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:221)
| at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
| at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280)
| at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135)
| at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65)
| at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:142)
| at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166)
| at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
| at java.lang.Thread.run(Thread.java:595)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184462#4184462
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184462
17 years, 2 months