July 2012 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-3583) MessageAwareListener Thread Pool does not clean up idle threads

by Peter Nordquist (JIRA)

MessageAwareListener Thread Pool does not clean up idle threads --------------------------------------------------------------- Key: JBESB-3583 URL: https://issues.jboss.org/browse/JBESB-3583 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.9, 4.8 Environment: JBoss 5.1.0.GA with ESB 4.8 running on Win 7 64-bit, Mac OS X, and RHEL 5.5 all running MySQL 5.1.5x Java 1.6.0_20 and Java 1.6.0_24 Reporter: Peter Nordquist In the MessageAwareListener at http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/rosetta/s... on line 232 a fixed thread pool is allocated. This causes the possibility of having at most maxThreads around for the life of the App server even if the service is not being used. Behind the scenes the Executors.newFixedThreadPool(_maxThreads) creates a java.util.concurrent.ThreadPoolExecutor with a core pool size of maxThreads and a max pool size of maxThreads and 0L for the keep alive time and giving it a new LinkedBlockingQueue<Runnable>() for the queue. This Executor will not precreate the threads but as calls happen it will allocate threads as needed and keep them around forever since the core pool size is the same as the max pool size. If there are a large number of services defined with high values for maxThreads a 'java.lang.OutOfMemoryError: unable to create new native thread' exception will occur. I suggest that you fix this by actually instantiating a java.util.concurrent.ThreadPoolExecutor with a core pool size of something other than maxThreads (possibly 0 since it would then destroy all threads when they are not needed) a max pool size of the passed in maxThreads and a keep alive time of your choice. We are currently using 4.8 but are evaluating 4.9 and see the same problem in that version. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

3
7
0 / 0

[JBoss JIRA] Created: (JBESB-2265) Wise action don't work with BASIC auth

by Stefano Maestri (JIRA)

Wise action don't work with BASIC auth -------------------------------------- Key: JBESB-2265 URL: https://jira.jboss.org/jira/browse/JBESB-2265 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: 4.4 Reporter: Stefano Maestri Assignee: Stefano Maestri Fix For: 4.5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

7
14
0 / 0

[JBoss JIRA] (JBESB-3742) Modify JMS Gateway for standard populatation of AuthenticationRequest for service authentication

by Tom Cunningham (JIRA)

Tom Cunningham created JBESB-3742: ------------------------------------- Summary: Modify JMS Gateway for standard populatation of AuthenticationRequest for service authentication Key: JBESB-3742 URL: https://issues.jboss.org/browse/JBESB-3742 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Message Store Affects Versions: 4.11 Reporter: Tom Cunningham Fix For: 4.11 The customer is looking to pass credentials via a JMS client so that the JMS gateway can pull those credentials from the transport(message) and create an AuthenticationRequest object that is used to authenticate against a "secured" service. What he is looking for is standard functionality similar of that of the JBR Gateway [1] rather than having to enhance the Gateway with a custom composer class. In addition, clarification on which Gateways actually currently offer this functionality and "how" the client can provide the credentials would be useful [1] http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/rosetta/s... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

3
5
0 / 0

[JBoss JIRA] (JBESB-3839) Need to be more clear on use of multiple notification lists

by Tom Cunningham (JIRA)

Tom Cunningham created JBESB-3839: ------------------------------------- Summary: Need to be more clear on use of multiple notification lists Key: JBESB-3839 URL: https://issues.jboss.org/browse/JBESB-3839 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.11 Reporter: Tom Cunningham Assignee: Tom Cunningham Fix For: 4.12 Need to be more clear on use of multiple notification lists (one for "OK", another for "error"). If this is not intended to be supported, it should be spelled out in the documents and we should provide a solution for the use case provided in the forum case here (https://community.jboss.org/thread/203190?tstart=0) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3837) Cannot find jms-1.1.jar

by Tom Cunningham (JIRA)

Tom Cunningham created JBESB-3837: ------------------------------------- Summary: Cannot find jms-1.1.jar Key: JBESB-3837 URL: https://issues.jboss.org/browse/JBESB-3837 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Build and Release Affects Versions: 4.11 CP1 Reporter: Tom Cunningham Assignee: Tom Cunningham Fix For: 4.11 CP2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
3
0 / 0

[JBoss JIRA] (JBESB-3836) Quickstart_webservice_proxy_basic failed to be deployed on jboss AS 6.11

by raul perez muñoz (JIRA)

raul perez muñoz created JBESB-3836: --------------------------------------- Summary: Quickstart_webservice_proxy_basic failed to be deployed on jboss AS 6.11 Key: JBESB-3836 URL: https://issues.jboss.org/browse/JBESB-3836 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Environment: CentOS 6.2 + jdk1.6_31 + JBOSSESB 4.11 + JBOSS AS 6.1 Reporter: raul perez muñoz I get this exception (or similar) trying to deploy any Quickstart_webservice_proxy 2012-07-25 15:41:53,962 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner) deploy, ctxPath=/Quickstart_webservice_proxy_basic 2012-07-25 15:41:53,974 INFO [org.jboss.soa.esb.listeners.deployers.mc.as6.EsbDeployment] (HDScanner) Deploying 'vfs:///opt/jboss/jboss-6.1.0.Final/server/default/tmp/esbwarfiles/Quickstart_webservice_proxy_basic-web.war' 2012-07-25 15:41:53,975 INFO [org.jboss.soa.esb.listeners.deployers.mc.as6.EsbDeployment] (HDScanner) Starting ESB Deployment 'Quickstart_webservice_proxy_basic.esb' 2012-07-25 15:41:54,035 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (HDScanner) Error installing to Start: name=jboss.esb.vfs:///opt/jboss/jboss-6.1.0.Final/server/default/deploy/Quickstart_webservice_proxy_basic.esb state=Create: org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleException: Error configuring action processing pipeline at org.jboss.soa.esb.listeners.message.MessageAwareListener.doInitialise(MessageAwareListener.java:192) [:] at org.jboss.soa.esb.listeners.lifecycle.AbstractManagedLifecycle.initialise(AbstractManagedLifecycle.java:133) [:] at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.initialiseInstances(ManagedLifecycleController.java:109) [:] at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.start(ManagedLifecycleController.java:66) [:] at org.jboss.soa.esb.listeners.deployers.mc.as6.EsbDeployment.start(EsbDeployment.java:234) [:] at sun.reflect.GeneratedMethodAccessor537.invoke(Unknown Source) [:1.6.0_31] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_31] at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_31] at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.1.SP1] at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.1.SP1] at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.1.SP1] at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:257) [jboss-kernel.jar:2.2.0.SP2] at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.SP2] at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.SP2] at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72) [jboss-kernel.jar:2.2.0.SP2] at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:202) [jboss-kernel.jar:2.2.0.SP2] at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.SP2] at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.SP2] at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.system.ServiceController.doChange(ServiceController.java:671) [:6.1.0.Final (Build SVNTag:JBoss_6.1.0.Final date: 20110816)] at org.jboss.system.ServiceController.start(ServiceController.java:443) [:6.1.0.Final (Build SVNTag:JBoss_6.1.0.Final date: 20110816)] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_31] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_31] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_31] at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_31] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.GA] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.GA] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.GA] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.GA] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.GA] at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:246) [:6.1.0.Final (Build SVNTag:JBoss_6.1.0.Final date: 20110816)] at org.jboss.internal.soa.esb.dependencies.WSDeploymentBarrierController.registerBarrierMBean(WSDeploymentBarrierController.java:101) [:] at org.jboss.internal.soa.esb.dependencies.WSDeploymentBarrierController.registerExistingDeployment(WSDeploymentBarrierController.java:132) [:] at org.jboss.internal.soa.esb.dependencies.WSDeploymentBarrierController.createService(WSDeploymentBarrierController.java:58) [:] at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:323) [:6.1.0.Final (Build SVNTag:JBoss_6.1.0.Final date: 20110816)] at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:299) [:6.1.0.Final (Build SVNTag:JBoss_6.1.0.Final date: 20110816)] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_31] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_31] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_31] at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_31] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.GA] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.GA] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.GA] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.GA] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.GA] at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:189) [:2.2.0.SP2] at $Proxy41.create(Unknown Source) at org.jboss.system.microcontainer.CreateDestroyLifecycleAction.installAction(CreateDestroyLifecycleAction.java:54) [:2.2.0.SP2] at org.jboss.system.microcontainer.CreateDestroyLifecycleAction.installAction(CreateDestroyLifecycleAction.java:42) [:2.2.0.SP2] at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:301) [:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.system.ServiceController.doChange(ServiceController.java:671) [:6.1.0.Final (Build SVNTag:JBoss_6.1.0.Final date: 20110816)] at org.jboss.system.ServiceController.create(ServiceController.java:405) [:6.1.0.Final (Build SVNTag:JBoss_6.1.0.Final date: 20110816)] at org.jboss.system.ServiceController.create(ServiceController.java:370) [:6.1.0.Final (Build SVNTag:JBoss_6.1.0.Final date: 20110816)] at org.jboss.system.deployers.ServiceDeployer.create(ServiceDeployer.java:184) [:6.1.0.Final] at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99) [:6.1.0.Final] at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:49) [:6.1.0.Final] at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:63) [:2.2.2.GA] at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.2.GA] at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.2.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.2.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.2.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.2.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.2.GA] at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2] at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.2.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.2.GA] at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.2.GA] at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.1.0.Final] at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2] at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.2.2] at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.2.2] at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:57) [:0.2.2] at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.2.2] at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:95) [:0.2.2] at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2] at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2] at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2] at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2] at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.2.2] at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.2.2] at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.2.2] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_31] at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_31] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_31] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_31] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) [:1.6.0_31] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) [:1.6.0_31] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_31] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_31] at java.lang.Thread.run(Thread.java:662) [:1.6.0_31] Caused by: org.jboss.soa.esb.ConfigurationException: Unexpected exception while instantiating action instance at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.getActionClassInstance(ActionProcessorMethodInfo.java:359) [:] at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.getActionClassInstance(ActionProcessorMethodInfo.java:340) [:] at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.<init>(ActionProcessingPipeline.java:278) [:] at org.jboss.soa.esb.listeners.message.MessageAwareListener.doInitialise(MessageAwareListener.java:186) [:] ... 117 more Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [:1.6.0_31] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) [:1.6.0_31] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) [:1.6.0_31] at java.lang.reflect.Constructor.newInstance(Constructor.java:513) [:1.6.0_31] at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.getActionClassInstance(ActionProcessorMethodInfo.java:355) [:] ... 120 more Caused by: org.jboss.soa.esb.ConfigurationException: java.lang.IllegalStateException: unrecognized internal endpoint: jboss.ws:context=Quickstart_webservice_proxy_basic_ws,endpoint=HelloWorldWS at org.jboss.soa.esb.actions.soap.proxy.SOAPProxy.<init>(SOAPProxy.java:202) [:] ... 125 more Caused by: java.lang.IllegalStateException: unrecognized internal endpoint: jboss.ws:context=Quickstart_webservice_proxy_basic_ws,endpoint=HelloWorldWS at org.jboss.soa.esb.actions.soap.proxy.SOAPProxyWsdlLoader$InternalSOAPProxyWsdlLoader.getAddress(SOAPProxyWsdlLoader.java:485) [:] at org.jboss.soa.esb.actions.soap.proxy.SOAPProxyWsdlLoader.load(SOAPProxyWsdlLoader.java:155) [:] at org.jboss.soa.esb.actions.soap.proxy.SOAPProxy.<init>(SOAPProxy.java:197) [:] ... 125 more 2012-07-25 15:41:54,051 INFO [org.jboss.soa.esb.listeners.deployers.mc.as6.EsbDeployment] (HDScanner) Destroying 'Quickstart_webservice_proxy_basic.esb' 2012-07-25 15:41:54,051 INFO [org.jboss.soa.esb.listeners.deployers.mc.as6.EsbDeployment] (HDScanner) Undeploying 'Quickstart_webservice_proxy_basic-web.war' 2012-07-25 15:41:54,052 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (HDScanner) undeploy, ctxPath=/Quickstart_webservice_proxy_basic 2012-07-25 15:41:54,060 INFO [org.jboss.soa.esb.listeners.deployers.mc.as6.EsbDeployment] (HDScanner) Deleting 'Quickstart_webservice_proxy_basic-web.war' 2012-07-25 15:41:54,061 INFO [org.jboss.internal.soa.esb.publish.ContractProviderLifecycleResource] (HDScanner) Removing ContractProvider?deployment=ID-29&service-category=Proxy_Basic&service-name=Proxy 2012-07-25 15:41:54,061 WARN [org.jboss.soa.esb.listeners.message.ServiceMessageCounterLifecycleResource] (HDScanner) Calling cleanup on existing service message counters for identity ID-29 2012-07-25 15:41:54,061 WARN [org.jboss.soa.esb.smooks.resource.SmooksResource] (HDScanner) Closing smooks resources for identity ID-29 2012-07-25 15:41:54,062 WARN [org.jboss.profileservice.deployment.hotdeploy.HDScanner] (HDScanner) Scan failed: org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS): DEPLOYMENTS IN ERROR: Deployment "jboss.esb.vfs:///opt/jboss/jboss-6.1.0.Final/server/default/deploy/Quickstart_webservice_proxy_basic.esb" is in error due to the following reason(s): java.lang.IllegalStateException: unrecognized internal endpoint: jboss.ws:context=Quickstart_webservice_proxy_basic_ws,endpoint=HelloWorldWS at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1370) [:2.2.2.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1316) [:2.2.2.GA] at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:968) [:2.2.2.GA] at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.checkComplete(MainDeployerPlugin.java:82) [:6.1.0.Final] at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.checkComplete(ProfileControllerContext.java:138) [:0.2.2] at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:246) [:0.2.2] at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.2.2] at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:57) [:0.2.2] at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.2.2] at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:95) [:0.2.2] at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2] at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2] at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2] at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2] at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.2.2] at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.2.2] at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.2.2] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_31] at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_31] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_31] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_31] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) [:1.6.0_31] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) [:1.6.0_31] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_31] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_31] at java.lang.Thread.run(Thread.java:662) [:1.6.0_31] ^C -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
1
0 / 0

[JBoss JIRA] (JBESB-3779) ServiceInvoker behaviour is inconsistent when used with transactions

by Tom Cunningham (JIRA)

Tom Cunningham created JBESB-3779: ------------------------------------- Summary: ServiceInvoker behaviour is inconsistent when used with transactions Key: JBESB-3779 URL: https://issues.jboss.org/browse/JBESB-3779 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.10 Environment: JBoss SOA 5.2.0 Platform Reporter: Michael Burman Fix For: 4.10 CP2 The ServiceInvoker behaviour is inconsistent when it comes to XA transactions. If the delivery fails with ServiceInvoker (there's a network timeout or something), the transaction is still committed, because it does not throw a RuntimeException. So instead of rolling back everything you just did in your actions, the staticRouter or such would commit the process and then throw this to DLQ. So when you run it from DLQ, you would again write to the database and so on. With SmooksSplitter this might cause some messages to go through and some not and other weird behaviour. One fix would be to patch ServiceInvoker deliverAsync (as an example, deliverSync should be fixed also): ### Eclipse Workspace Patch 1.0 #P JBossESB Index: rosetta/src/org/jboss/soa/esb/client/ServiceInvoker.java =================================================================== --- rosetta/src/org/jboss/soa/esb/client/ServiceInvoker.java (revision 37896) +++ rosetta/src/org/jboss/soa/esb/client/ServiceInvoker.java (working copy) @@ -46,9 +46,9 @@ import org.jboss.soa.esb.couriers.Courier; import org.jboss.soa.esb.couriers.CourierException; import org.jboss.soa.esb.couriers.CourierFactory; -import org.jboss.soa.esb.couriers.CourierTimeoutException; import org.jboss.soa.esb.couriers.CourierMarshalUnmarshalException; import org.jboss.soa.esb.couriers.CourierServiceBindException; +import org.jboss.soa.esb.couriers.CourierTimeoutException; import org.jboss.soa.esb.couriers.CourierTransportException; import org.jboss.soa.esb.couriers.CourierUtil; import org.jboss.soa.esb.couriers.FaultMessageException; @@ -57,6 +57,7 @@ import org.jboss.soa.esb.listeners.ha.LoadBalancePolicy; import org.jboss.soa.esb.listeners.ha.ServiceClusterInfo; import org.jboss.soa.esb.listeners.ha.ServiceClusterInfoImpl; +import org.jboss.soa.esb.listeners.jca.JcaGatewayException; import org.jboss.soa.esb.listeners.message.IncompatibleTransactionScopeException; import org.jboss.soa.esb.listeners.message.MessageDeliverException; import org.jboss.soa.esb.listeners.message.MissingServiceException; @@ -253,6 +254,12 @@ try { post(message, new EPRInvoker()); } catch (MessageDeliverException mde) { + + // We want to trigger JCA rollback in case of messagedeliver exception + if(isTransactional()) { + throw new JcaGatewayException(mde); + } + if (message.getProperties().getProperty(RedeliverStore.IS_REDELIVERY)==null && asyncRedelivery(message) && !service.equals(dlqService)) { Here's a quickstart that provides a small example (replace correctBehaviour="true" to get JMS rollbacks), it just tries to call some nonexistant gateway to throw MessageDeliveryException (if there's a proper way to cause timeout in the code, then let me know, but the exception is never the less the same). https://s3-eu-west-1.amazonaws.com/yak/jboss/jms_transacted_fail.zip Once you run it with original settings and it fails, you still end up with lines in the database. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
2
0 / 0

[JBoss JIRA] (JBESB-3732) ReadOnlyRemoteGatewayListenerIntegrationTest breaking Hudson build

by Tom Cunningham (JIRA)

Tom Cunningham created JBESB-3732: ------------------------------------- Summary: ReadOnlyRemoteGatewayListenerIntegrationTest breaking Hudson build Key: JBESB-3732 URL: https://issues.jboss.org/browse/JBESB-3732 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.11 Reporter: Tom Cunningham Assignee: Tom Cunningham Fix For: 4.11 ReadOnlyRemoteGatewayListenerIntegrationTest is breaking the Hudson build : http://hudson.qa.jboss.com/hudson/job/jboss-esb-linux/1726/consoleText Going to try commenting out that single test to see if the Hudson build can successfully complete after that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
3
0 / 0

[JBoss JIRA] (JBESB-3740) Clarify usage of acknowledge-mode on jms-message-filter

by Tom Cunningham (JIRA)

Tom Cunningham created JBESB-3740: ------------------------------------- Summary: Clarify usage of acknowledge-mode on jms-message-filter Key: JBESB-3740 URL: https://issues.jboss.org/browse/JBESB-3740 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.11 Reporter: Tom Cunningham Fix For: 4.11 Description of problem: The ESB Programmers Guide [1] only states that CLIENT_ACKNOWLEDGE mode can be set on the jms-message-filter configuration, but does not talk about the resulting behavior, or about any restrictions. The docs should be more clear about - the resulting behavior if different ack modes are used - any restrictions that apply, such as not using CLIENT_ACKNOWLEDGE mode on non-gateway queues using jms-provider - which providers these settings apply to (jms-provider, jms-jca-provider) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (JBESB-3128) http_gateway synchronousTimeout - operates twice as slow as expected the first time it is encountered by a service

by Len DiMaggio (JIRA)

http_gateway synchronousTimeout - operates twice as slow as expected the first time it is encountered by a service ------------------------------------------------------------------------------------------------------------------ Key: JBESB-3128 URL: https://jira.jboss.org/jira/browse/JBESB-3128 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Process flow Affects Versions: 4.7 Environment: 4.7 GA Reporter: Len DiMaggio I'm seeing a very odd problem with the ESB's http_gateway synchronousTimeout property. Briefly - the timer operates 100% slower than it should - but only the first time the timer is invoked for deployed .esb archive. This is reproducible at will with ESB 4.7 and SOA-P 5.0 ER7. After experimenting with this - the delay seems to be on a per-service basis - in other words, the first time a service that hits synchronousTimeout, the timeout operates twice as slow as it should. Starting with the second time that a service encounters a synchronousTimeout, the timeout operates as expected. I'm seeing this with the default synchronousTimeout value, and if the value is defined in the service definition in jboss-esb.xml ======================================== A modified version of the http_gateway quickstart is attached to demonstrate the problem. The modifications are: * A new action class (my40secAction) is added - this class is identical to myAction, except that it introduces a 40 seconde delay. * A modified jboss-esb.xml file - the Sales:List service is modified to have a 10 second synchronousTimeout, and the action invokes the My40secAction class - and a second service (SlowSales) is added - this service is a clone of Sales:List: <service category="Sales" name="List" description="" invmScope="GLOBAL"> <listeners>  <http-gateway name="sales" busidref="secureFriends" urlPattern="sales/*"> <property name="synchronousTimeout" value="10000"/> </http-gateway> </listeners> <actions mep="RequestResponse"> <action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.My40secAction"/> </actions> </service> <service category="SlowSales" name="SlowList" description="" invmScope="GLOBAL"> <listeners>  <http-gateway name="slowsales" busidref="secureFriends" urlPattern="slowsales/*"> <property name="synchronousTimeout" value="10000"/> </http-gateway> </listeners> <actions mep="RequestResponse"> <action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.My40secAction"/> </actions> </service> ======================================== Here's an example of the behavior I'm seeing: Test run #1 - approx 20 sec - unexpected as the test is configured for 10 sec timeout [ldimaggi@ldimaggi http_gateway]$ date;lynx -dump -source -auth=kermit:thefrog http://localhost:8080/Quickstart_http_gateway/http/sales/a/b/c; date Fri Jan 15 15:52:47 EST 2010 <html><head><title>JBoss Web/2.1.3 - Error report</title><style></style> </head><body><h1>HTTP Status 500 - </h1><HR size="1" noshade="noshade">type Exception reportmessage description The server encountered an internal error () that prevented it from fulfilling this request.exception <pre>javax.servlet.ServletException: Failed to deliver message. org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:215) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) </pre>root cause <pre>org.jboss.soa.esb.listeners.message.ResponseTimeoutException: No response received for service [Sales:List]. org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:427) org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:219) org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:187) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) </pre>note The full stack trace of the root cause is available in the JBoss Web/2.1.3 logs.<HR size="1" noshade="noshade"><h3>JBoss Web/2.1.3</h3></body></html>Fri Jan 15 15:53:07 EST 2010 Then - immediately follows test run #2 - approx 10 seconds - this is what I would have expected [ldimaggi@ldimaggi http_gateway]$ date;lynx -dump -source -auth=kermit:thefrog http://localhost:8080/Quickstart_http_gateway/http/sales/a/b/c; date Fri Jan 15 15:53:14 EST 2010 <html><head><title>JBoss Web/2.1.3 - Error report</title><style></style> </head><body><h1>HTTP Status 500 - </h1><HR size="1" noshade="noshade">type Exception reportmessage description The server encountered an internal error () that prevented it from fulfilling this request.exception <pre>javax.servlet.ServletException: Failed to deliver message. org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:215) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) </pre>root cause <pre>org.jboss.soa.esb.listeners.message.ResponseTimeoutException: No response received for service [Sales:List]. org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:427) org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:219) org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:187) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) </pre>note The full stack trace of the root cause is available in the JBoss Web/2.1.3 logs.<HR size="1" noshade="noshade"><h3>JBoss Web/2.1.3</h3></body></html>Fri Jan 15 15:53:25 EST 2010 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

5
15
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues July 2012