August 2009 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-2550) "local first" load balancing policy

by toby cabot (JIRA)

"local first" load balancing policy ----------------------------------- Key: JBESB-2550 URL: https://jira.jboss.org/jira/browse/JBESB-2550 Project: JBoss ESB Issue Type: Patch Security Level: Public (Everyone can see) Affects Versions: 4.4 Reporter: toby cabot Here's a patch that adds org.jboss.soa.esb.listeners.ha.LocalFirstRoundRobin which will choose a local EPR if there is one and fall back to RoundRobin if not. We like this because it keeps processing on a single host when that's possible and only goes off-host (which is relatively expensive) if necessary. -- 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
4
0 / 0

[JBoss JIRA] Created: (JBESB-1937) Document performance tuning parameters

by Kevin Conner (JIRA)

Document performance tuning parameters -------------------------------------- Key: JBESB-1937 URL: https://jira.jboss.org/jira/browse/JBESB-1937 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.4 Reporter: Kevin Conner Assignee: Jervis Liu Fix For: 4.5 We need to include documentation on tuning parameters that are available within the ESB. Jervis has made a good start to this as part of the recent work he has been doing, his experience should be used as the basis. -- 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-1121) JBoss Web Console integration (message alerter)

by Tom Cunningham (JIRA)

JBoss Web Console integration (message alerter) ----------------------------------------------- Key: JBESB-1121 URL: http://jira.jboss.com/jira/browse/JBESB-1121 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Tom Cunningham Assigned To: Tom Cunningham According to their docs, the JBoss Web Console does console-based alerts and email-alerts. It'd be nice if there was also was an ESB option - where based off of a JMX Bean property, a message is sent to whatever ESB service the user specifies in their monitoring XML. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBESB-1851) JAXRConnectionFactory should not rely on System properties when creating a Connection

by Daniel Bevenius (JIRA)

JAXRConnectionFactory should not rely on System properties when creating a Connection ------------------------------------------------------------------------------------- Key: JBESB-1851 URL: http://jira.jboss.com/jira/browse/JBESB-1851 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Examples, Registry and Repository Reporter: Daniel Bevenius The quickstarts that use the ServiceInvoker all seem to do this (atleast the ones that I've looked at) : System.setProperty("javax.xml.registry.ConnectionFactoryClass","org.apache.ws.scout.registry.ConnectionFactoryImpl"); Now, we have this property in the jbossesb-properties.xml as: <property name="org.jboss.soa.esb.registry.factoryClass" value="org.apache.ws.scout.registry.ConnectionFactoryImpl"/> This property is read by JAXRConnectionFactory constructor and saved into a Properties object as: props.setProperty("javax.xml.registry.factoryClass", Configuration.getRegistryFactoryClass()); The 'props' are set on the ConnectionFactory object that is created in the getConnection() method: protected Connection getConnection() { Connection connection = null; try { // Create the connection, passing it the configuration properties ConnectionFactory factory = ConnectionFactory.newInstance(); factory.setProperties(props); connection = factory.createConnection(); connection.setCredentials(creds); } catch (JAXRException e) { logger.log(Level.ERROR, "Could not set up a connection to the Registry. " + e.getMessage(), e); } return connection; } Here we can see that ConnectionFactory.newInstance() method will be called prior to the properties getting set on the factory, which is natural. But the problem is that ConnectionFactory.newInstance() method looks like this: private static final String SYS_PROP_NAME = "javax.xml.registry.ConnectionFactoryClass"; public static ConnectionFactory newInstance() throws JAXRException { String factoryName = null; ConnectionFactory factory = null; try { String defaultName = null; factoryName = System.getProperty(SYS_PROP_NAME, defaultName); ClassLoader loader =Thread.currentThread().getContextClassLoader(); Class factoryClass = loader.loadClass(factoryName); factory = (ConnectionFactory) factoryClass.newInstance(); } catch(Throwable e) { throw new JAXRException("Failed to create instance of:"+factoryName, e); } return factory; } We should not be relying on the system properties in order to do this. Our JAXRConnectionFactory should be creating the factory directly and not using ConnectionFactory, this is the real error IMO. If we do this then we will not be affected by anyone else in the AS overriding JAXR. Kev See also this googlegroups thread for more background info: http://groups.google.se/group/jbossesb/browse_frm/thread/3a5ce28b4a0f6bca -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

4
5
0 / 0

[JBoss JIRA] Created: (JBESB-2457) SoapUIClientService does not populate request attributes

by Kevin Conner (JIRA)

SoapUIClientService does not populate request attributes -------------------------------------------------------- Key: JBESB-2457 URL: https://jira.jboss.org/jira/browse/JBESB-2457 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: 4.4 CP2, 4.5 Reporter: Joakim Sandström SoapUIClientService only appears to handle population of text elements and not the attributes. expected request: <soapenv:Body> <ns:updateCustomer customerId="124343"> <ns:name> <ns:firstName>FIRSTNAME</ns:firstName> actual request: <soapenv:Body> <ns:updateCustomer customerId="?"> <ns:name> <ns:firstName>FIRSTNAME</ns:firstName> -- 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

1
4
0 / 0

[JBoss JIRA] Created: (JBESB-2208) JON plugin can not be compiled against JOPR source

by Thorbj?rn Blixen-Finecke (JIRA)

JON plugin can not be compiled against JOPR source -------------------------------------------------- Key: JBESB-2208 URL: https://jira.jboss.org/jira/browse/JBESB-2208 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Tooling Affects Versions: 4.4 CP1 Environment: All Reporter: Thorbj?rn Blixen-Finecke Priority: Minor The org.jbosson.plugins.jbossesb.DeploymentComponent imports the class org.rhq.plugins.utils.FileUtils. This class does not exist in the RHQ 1.2.0 or JOPR 2.2.0 source. The JON plugin can therefore not be compiled against the JOPR source. -- 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

4
7
0 / 0

[JBoss JIRA] Created: (JBESB-2580) The use of EBWS service can interfere with deployment of war packaged inside ESB

by Jiri Pechanec (JIRA)

The use of EBWS service can interfere with deployment of war packaged inside ESB -------------------------------------------------------------------------------- Key: JBESB-2580 URL: https://jira.jboss.org/jira/browse/JBESB-2580 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta, Web Services Affects Versions: 4.4 CP2 Reporter: Jiri Pechanec Priority: Minor I have en ESB file that contains EBWS. Moreover the ESB also contains WAR file inside to be deployed. During deployment I get the exception 2009-05-21 13:08:02,831 ERROR [org.jboss.deployment.MainDeployer] Could not create deployment: file:/home/jpechane/testing/esbtests/tests/quickstarts/tests/output/lib/Performance_ebwsproxy.esb org.jboss.deployment.DeploymentException: Error during create of ESB Module: file:/home/jpechane/testing/esbtests/tests/quickstarts/tests/output/lib/Performance_ebwsproxy.esb; - nested throwable: (org.jboss.deployment.DeploymentException: Duplicate subDeployment name: Performance_ebwsproxy.war) at org.jboss.soa.esb.listeners.config.JBoss4ESBDeployer.create(JBoss4ESBDeployer.java:395) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:566) 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.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.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.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266) 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.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:180) 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.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.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 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: org.jboss.deployment.DeploymentException: Duplicate subDeployment name: Performance_ebwsproxy.war at org.jboss.soa.esb.listeners.config.JBoss4ESBDeployer.create(JBoss4ESBDeployer.java:344) ... 58 more It is caused by ESB to internally generating war file with the same name as is the ESB package - as visible from JMX console jboss.web.deployment id=-1124246638,war=web-console.war id=-1342401103,war=Performance_ebwsproxy.war id=-1609398172,war=jbossws-context.war id=-2023986111,war=Performance_ebwsproxy.war id=-301626075,war=jbpm-console.war id=-414077734,war=juddi.war id=-835178978,war=invoker.war id=1789078566,war=ROOT.war id=587009610,war=contract.war id=792752244,war=jmx-console.war id=972266901,war=jbossesb.war If it then later tries to deploy embedded WAR file that has the same name as ESB package the deployment fails with very misleading message -- 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

2
6
0 / 0

[JBoss JIRA] Created: (JBESB-2329) FTP Gateway: error-delete does not work

by Thomas Guenter (JIRA)

FTP Gateway: error-delete does not work --------------------------------------- Key: JBESB-2329 URL: https://jira.jboss.org/jira/browse/JBESB-2329 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Adapters Affects Versions: 4.4 Environment: jbossesb-server-4.4.GA on Mac OS 10.5 Reporter: Thomas Guenter Priority: Minor If the error-delete attribute in a ftp-message-filter is set to "true" (as default), it is expected that no error file will be generated at all. Instead an error file with the default error-suffix is created in the (input-)directory. Since the logic that handles these issues is implemented in the class org.jboss.soa.esb.listeners.gateway.AbstractFileGateway, it is likely that the FileGatewayListener is also affected but this hasn't been tested yet. -- 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

3
5
0 / 0

[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, 9 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, 9 months

3
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues August 2009