September 2009 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-2253) Improve wise QS readme

by Jim Ma (JIRA)

Improve wise QS readme ---------------------- Key: JBESB-2253 URL: https://jira.jboss.org/jira/browse/JBESB-2253 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Examples Affects Versions: 4.4 CP1 Reporter: Jim Ma Priority: Minor Fix For: 4.4 CP2 Attachments: wise-qs-readme.patch Add extra information "when configure wise.core.properties , use '/' instead of '\', or you should double your '\' like '\\' on Windows" -- 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

14 years, 8 months

2
5
0 / 0

[JBoss JIRA] Created: (JBESB-2204) jBPM Persistence race condition in EsbActionHandler under high load

by Damon Brown (JIRA)

jBPM Persistence race condition in EsbActionHandler under high load ------------------------------------------------------------------- Key: JBESB-2204 URL: https://jira.jboss.org/jira/browse/JBESB-2204 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Process flow Affects Versions: 4.4 Environment: AS 4.2.3.GA, jBPM 3.2.3.GA + ehcache, RHEL 5, x86_64, 1.6.0 Sun JVM, Oracle 10g Reporter: Damon Brown Priority: Minor Attachments: CallbackCommand.java.patch Under extremely high load, the org.jboss.soa.esb.services.jbpm.cmd.CallbackCommand:90 cannot always locate the Token to signal for the target process. The exception is not propagated to the CallbackQueue and the message is not retried. The target process is left in a suspended state even though the ESB service has completed its action. The failure rate is machine-load dependent (1 - 5% failure rate). The root cause of the missing token is not able to be attributed to the jBPM hibernate session directly. I extended org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler directly to forcibly flush the current state of the token to the database. Within the same action, I queried for the state of the object, which was returned successfully. There appears to be a race condition from ESB service invocation (EsbActionHandler), token persistence (hibernate flush), and command callback (CallbackCommand). The particular ESB service I am invoking has a short suspense. Other ESB services, which take longer to execute, do not exhibit this behavior. The behavior for the short-suspense service was random, but repeatable. The patch file attached to this issue attempts to resolve the issue by re-trying the token look-up three times with an intermittent sleep. Within my environment, under high load conditions, the token failed to resolve on the first try 1% - 5% of the time (98% average success on first try), with a 100% success rate on the second try. The target process instance is successfully signaled. -- 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

14 years, 8 months

3
6
0 / 0

[JBoss JIRA] Created: (JBESB-1972) EBWS endpoints are created even if ESB config file is onvalid

by Jiri Pechanec (JIRA)

EBWS endpoints are created even if ESB config file is onvalid ------------------------------------------------------------- Key: JBESB-1972 URL: https://jira.jboss.org/jira/browse/JBESB-1972 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta, Web Services Affects Versions: 4.4 CP1 Reporter: Jiri Pechanec Priority: Critical If there is a validation error in ESB config file the EBWS endpoints are created and their WSDL is accessible 2008-09-01 12:59:17,623 WARN [org.jboss.system.ServiceController] Problem starting service jboss.esb:deployment=EBWS.esb java.lang.RuntimeException: java.lang.IllegalStateException: ESB file had validation errors. at org.jboss.soa.esb.listeners.config.Configuration.create(Configuration.java:138) at org.jboss.soa.esb.listeners.config.JBoss4ESBDeployment.startService(JBoss4ESBDeployment.java:99) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) at sun.reflect.GeneratedMethodAccessor333.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at org.jboss.system.ServiceController.start(ServiceController.java:435) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:588) at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:562) at sun.reflect.GeneratedMethodAccessor364.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at sun.reflect.GeneratedMethodAccessor317.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266) at sun.reflect.GeneratedMethodAccessor109.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74) at org.jboss.jmx.connector.invoker.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:108) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179) at sun.reflect.GeneratedMethodAccessor108.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:818) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:419) at sun.reflect.GeneratedMethodAccessor107.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: ESB file had validation errors. at org.jboss.soa.esb.listeners.config.Configuration.create(Configuration.java:132) ... 80 more 2008-09-01 12:59:17,632 INFO [org.jboss.web.tomcat.service.TomcatDeployer] deploy, ctxPath=/EBWS, warUrl=.../tmp/deploy/esbwarfiles/EBWS.esb/EBWS-exp.war/ 2008-09-01 12:59:18,060 INFO [org.jboss.wsf.stack.jbws.WSDLFilePublisher] WSDL published to: file:/home/jpechane/pokus/43IR2AS/jboss-as/server/postgresql/data/wsdl/EBWS.esb/EBWS.war/esbservicesample_helloworldpubservice.wsdl 2008-09-01 12:59:18,068 INFO [org.jboss.wsf.stack.jbws.WSDLFilePublisher] WSDL published to: file:/home/jpechane/pokus/43IR2AS/jboss-as/server/postgresql/data/wsdl/EBWS.esb/EBWS.war/esbservicesample_requestreply.wsdl 2008-09-01 12:59:18,073 INFO [org.jboss.wsf.stack.jbws.WSDLFilePublisher] WSDL published to: file:/home/jpechane/pokus/43IR2AS/jboss-as/server/postgresql/data/wsdl/EBWS.esb/EBWS.war/esbservicesample_oneway.wsdl -- 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

14 years, 8 months

3
8
0 / 0

[JBoss JIRA] Created: (JBESB-2619) Clarify generation of default ReplyTo EPRs in Programmers' Guide

by Kevin Conner (JIRA)

Clarify generation of default ReplyTo EPRs in Programmers' Guide ---------------------------------------------------------------- Key: JBESB-2619 URL: https://jira.jboss.org/jira/browse/JBESB-2619 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.4 CP3 Reporter: Kevin Conner Fix For: 4.4 CP4 The Programmers' Guide states that default ReplyTo EPRs will be created for service invocations but it does not state that this only happens for synchronous deliveries. Asynchronous deliveries will *not* have the ReplyTo initialised by default and any ReplyTo required must be explicit. We need to update the documentation and make this point clear. -- 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

14 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBESB-2617) InVMcourier deliver lockstep needs reworking

by Kevin Conner (JIRA)

InVMcourier deliver lockstep needs reworking -------------------------------------------- Key: JBESB-2617 URL: https://jira.jboss.org/jira/browse/JBESB-2617 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.4 CP3 Reporter: Kevin Conner Fix For: 4.4 CP4 The code loops, using a 5ms wait, and this has a performance impact. This needs to be reworked so that it does not cycle in this manner. -- 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

14 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBESB-2341) local date translating error when run esb smooks examples

by Feng Qian (JIRA)

local date translating error when run esb smooks examples --------------------------------------------------------- Key: JBESB-2341 URL: https://jira.jboss.org/jira/browse/JBESB-2341 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Examples Reporter: Feng Qian I am a jboss tools guy. When I did the task for importing ESB examples to eclipse workspace, I got a issue like: https://jira.jboss.org/jira/browse/JBIDE-3654. I just fixed this issue by adding <param name="locale-language">en</param> to smooks file. I do not know if the runtime examples has this issue because I can test it on my machine. If not, please close this jira. -- 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

14 years, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (JBESB-2124) Message Count and Message Count (avg) don't differ

by Jaroslaw Kijanowski (JIRA)

Message Count and Message Count (avg) don't differ -------------------------------------------------- Key: JBESB-2124 URL: https://jira.jboss.org/jira/browse/JBESB-2124 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Management Affects Versions: 4.4 CP1 Reporter: Jaroslaw Kijanowski $SUBJECT (see avg.png) + what does it mean to have a message count average? An average over what time? per minute? I guess per 'collection interval' ... but we have already an avg column for all metrics... why a separate metric? -- 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

14 years, 8 months

4
14
0 / 0

[JBoss JIRA] Created: (JBESB-1992) EBWS Security needs rework and unification

by Jiri Pechanec (JIRA)

EBWS Security needs rework and unification ------------------------------------------ Key: JBESB-1992 URL: https://jira.jboss.org/jira/browse/JBESB-1992 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta, Security, Web Services Affects Versions: 4.4 Reporter: Jiri Pechanec There is now security implementation at two levels - specifying webservice="security" attribute enables JBossWS security handler - specifying security elemnt enables WSSecuritySoapExtractor The WSSecuritySoapExtractor operates at XML/DOM level which means that is completely independent on JBossWS security handler. Please consider unifying the configuration and JBossWS facility use. Morever check the WSSecurityInfoExtractor if there is also a way to use JBossWS functions instead of Smooks parsing. -- 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

14 years, 8 months

4
13
0 / 0

[JBoss JIRA] Created: (JBESB-2051) Exception thrown by wise soap client during deployment are not easy to understand

by Stefano Maestri (JIRA)

Exception thrown by wise soap client during deployment are not easy to understand --------------------------------------------------------------------------------- Key: JBESB-2051 URL: https://jira.jboss.org/jira/browse/JBESB-2051 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Reporter: Stefano Maestri Assignee: Stefano Maestri -- 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

14 years, 8 months

3
4
0 / 0

[JBoss JIRA] Created: (JBESB-2273) Extend BusinessRulesProcessor action to support entry-point

by Burr Sutter (JIRA)

Extend BusinessRulesProcessor action to support entry-point ----------------------------------------------------------- Key: JBESB-2273 URL: https://jira.jboss.org/jira/browse/JBESB-2273 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.4 CP1 Reporter: Burr Sutter BusinessRulesProcessor allows for a "stateful" rules session as of ESB 4.4, however, it doesn't allow subsequent inbound messages to inject those messages into the already existing stateful rules session via the entry-point API. <action class="org.jboss.soa.esb.actions.BusinessRulesProcessor" name="OrderDiscountBasedOnCustomerHistory"> <property name="ruleSet" value="OrderDiscountOnMultipleOrders.drl" /> <property name="ruleReload" value="false" /> <property name="stateful" value="true" /> <property name="object-paths"> <object-path esb="body.TheOrderHeader" /> <object-path esb="body.TheCustomer" /> </property> </action> We might extend this like so: <object-path esb="body.TheOrderHeader" entry-point="OrderStream" /> <object-path esb="body.TheCustomer" entry-point="CustomerStream" /> The date time stamp should be based on message DOB but perhaps overrideable here as well. The use of entry-points would also mean that the Rules session is "self cleaning" as it automatically garbage collects stale facts. -- 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

14 years, 9 months

6
10
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues September 2009