September 2010 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-3473) Message Loss or premature execution termination in an action during shutdown

by Dave Siracusa (JIRA)

Message Loss or premature execution termination in an action during shutdown ---------------------------------------------------------------------------- Key: JBESB-3473 URL: https://jira.jboss.org/browse/JBESB-3473 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.0 Environment: RHEL 64bit Reporter: Dave Siracusa I'm able to reproduce JMS message loss or premature action termination during shutdown. I enqueued several thousand mesages into an ESB application. While the messages were being processed I toggle (stop/start) lifecycle state for the acting jms listeners via JMX in order to simulate shutdown. I noticed periodic warnings in the serverlog (listing 1). The final tally indicated message loss. Via code inspection the bug appears to be self-evident. Basically when the doStop method (JMXConsole) is called it sets state to STOPPING and immediately terminates the executor thread (MessageAwareListener.java). If the thread was currently processing bad things happen. I'm using transcated queues and it appears the JMS message transaction evaporates and the message is not returned to the queue. I added some code to AbstractThreadedManagedLifecycle.java to remedy the issue. It uses the default terminationPeriod (60 seconds), unless it is specified in the jboss-esb.xml file. AbstractThreadedManagedLifecycle.java --------------------------------------- protected void doStop() throws ManagedLifecycleException { runningLock.lock() ; try { if (isRunning()) { setRunning(ManagedLifecycleThreadStatae.STOPPING) ; } // Dave Siracusa -start if (!waitUntilStopped()) { throw new ManagedLifecycleException("Thread still active!") ; } // Dave Siracusa - end } finally { runningLock.unlock() ; } } MessageAwareListener.java --------------------------- protected void doStop() throws ManagedLifecycleException { super.doStop(); _execService.shutdown() ; } Listing 1 ---------- 2010-09-01 15:04:40,924 WARN [org.jboss.soa.esb.listeners.lifecycle.AbstractThreadedManagedLifecycle] (Thread-200) Unexpected error from doRun() java.util.concurrent.RejectedExecutionException at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecutionThreadPoolExecutor.java:1768) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658) at org.jboss.soa.esb.listeners.message.MessageAwareListener.waitForEventAndProcess(MessageAwareListener.java:359) at org.jboss.soa.esb.listeners.message.MessageAwareListener.doRun(MessageAwareListener.java:253) at org.jboss.soa.esb.listeners.lifecycle.AbstractThreadedManagedLifecycle.run(AbstractThreadedManagedLifecycle.java:115) at java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
9
0 / 0

[JBoss JIRA] Created: (JBESB-3396) ESB CEP support for multiple event streams

by David Ward (JIRA)

ESB CEP support for multiple event streams ------------------------------------------ Key: JBESB-3396 URL: https://jira.jboss.org/browse/JBESB-3396 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Configuration, Content Based Routing, Documentation, Examples Affects Versions: 4.9 Reporter: David Ward Assignee: David Ward Fix For: 4.9 CP1 CEP applications often are designed to correlate messages from multiple event streams. A common example (used often the Drools CEP presentations and documentation) is a Online Trading System, which has a "Home Broker Stream" and a "Stock Trader Stream". An Enterprise Service Bus such as JBoss ESB can provide a good architecture to support this type of CEP application. The developer could create three ESB Serivces. The first would create the Drool stateful knowledge session (and somehow publish this object to make it available for the other services), insert static facts, and call fireUntilHalt. The second service would represent the Home Broker Stream. It would receive trade requests from the Home Broker (say via a SOAP message), transform the XML into Java BuyOrderEvent objects, and insert these events into the stateful knowledge session via the Home Broker Stream entry point. The third service would be similar to the second service, except that it would handle messages from the Stock Trader, which for the sake of this example, come in as XML via a JMS transport, get transformed into Java BuyAckEvent objects and inserted into the session via the Stock Trader Stream entry point. The rationale for having multiple services is to be able to handle different protocols and perform different transformations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBESB-3404) Improve business_ruleservice_cep quickstart

by David Ward (JIRA)

Improve business_ruleservice_cep quickstart ------------------------------------------- Key: JBESB-3404 URL: https://jira.jboss.org/browse/JBESB-3404 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Content Based Routing, Examples Affects Versions: 4.9 Reporter: David Ward Assignee: David Ward Fix For: 4.9 CP1 The business_ruleservice_cep quickstart is a good start to an example CEP application. For example, it uses @role(event)'s and sliding time windows. However, it could be improved in at least a couple ways: 1. Also use entry-points. 2. Re-work it so that things like classnames, test hooks and some of the overall scenario make a bit more sense for a CEP app. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
3
0 / 0

[JBoss JIRA] Created: (JBESB-3474) Support Dual Authentication (username/pass and private key) in for SFTP listener

by Dustin Johnson (JIRA)

Support Dual Authentication (username/pass and private key) in for SFTP listener -------------------------------------------------------------------------------- Key: JBESB-3474 URL: https://jira.jboss.org/browse/JBESB-3474 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.7 Reporter: Dustin Johnson When creating an SFTP listener, and specifying both a username/password combination and a private key, only the username/password credentials are passed to the FTP server. This can be a problem when an FTP server requires both forms of authentication. The problem appears to occur in org.jboss.internal.soa.esb.util.SecureFtpImpl.java, in initialize(bConnect). It performs the following check: if (m_sPasswd != null) { final UserInfo ui = new SecureFtpUserInfo(null, m_sPasswd) ; session.setUserInfo(ui) ; session.setConfig("PreferredAuthentications", "password,keyboard-interactive") ; } else if (m_oCertificate != null) { // Setup ssh key stuff session.setConfig("PreferredAuthentications", "publickey") ; } The solution may be as simple as removing the else portion, so it always checks for the certificate to be present and adds the credentials regardless of whether a username/password was also presented. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBESB-3428) JAX-WS dependency mismatch between Picketlink/Security and WISE components

by Tom Fennelly (JIRA)

JAX-WS dependency mismatch between Picketlink/Security and WISE components --------------------------------------------------------------------------- Key: JBESB-3428 URL: https://jira.jboss.org/browse/JBESB-3428 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Security, Web Services Affects Versions: 4.9 Reporter: Tom Fennelly Fix For: 4.9 CP1 JBoss AS5 + Java 6. If you have an esb app that looks like a combo of the security_saml and one of the wise examples.... you'll break. The saml code (Picketlink) requires the jboss-native version of the jaxws jars from the server/client folder, while the wise code requires the jaxws version from the ESB Server? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBESB-3466) Small typo on programmers guide, Annotated Action Classes section

by Jehudi Castro (JIRA)

Small typo on programmers guide, Annotated Action Classes section ----------------------------------------------------------------- Key: JBESB-3466 URL: https://jira.jboss.org/browse/JBESB-3466 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.9 Environment: This is the version of the documentation that I'm looking at: http://jboss.org/jbossesb/docs/4.9/manuals/pdf/Programmers_Guide.pdf Reporter: Jehudi Castro Priority: Trivial Look for the section "4.1.4.2. @Process Method Return Values", page 39 fix the first word on the paragraph: "f the specified ESB Message location contains a value of the wrong type, a MessageDeliverException exception is thrown." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
4
0 / 0

[JBoss JIRA] Created: (JBESB-3344) JAXRRegistryImpl does not unregister services correctly from jUDDI.

by Marek Baluch (JIRA)

JAXRRegistryImpl does not unregister services correctly from jUDDI. ------------------------------------------------------------------- Key: JBESB-3344 URL: https://jira.jboss.org/browse/JBESB-3344 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Registry and Repository, Rosetta Affects Versions: 4.7 CP1, 4.7 CP2 Reporter: Marek Baluch Priority: Blocker JAXRRegistryImpl does not unregister services correctly from jUDDI. Only bindings are deleted but the service itself remains in the registry. These orphaned service records cause also problems when there are more server instances in the cluster. How to reproduce ------------------- Just deploy and undeploy a QS. Then have a look in jUDDI console. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues September 2010