June 2010 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-2805) Splitter EAI Pattern: A router that really split the message and delivery the message parts to different message channels

by Ricardo Ferreira (JIRA)

Splitter EAI Pattern: A router that really split the message and delivery the message parts to different message channels ------------------------------------------------------------------------------------------------------------------------- Key: JBESB-2805 URL: https://jira.jboss.org/jira/browse/JBESB-2805 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Content Based Routing Affects Versions: 4.6, 4.5, 4.4 Reporter: Ricardo Ferreira Current JBoss ESB Routers (StaticRouter and StaticWiretap) does not implement fully the EAI Patterns Splitter (http://www.eaipatterns.com/Sequencer.html). Those implementations just take the incoming message and redelivery for diferent services using basic routing. But in the pattern description we found: "Use a Splitter to BREAK OUT the composite message into a series of INDIVIDUAL MESSAGES, each containing data related to one item" The proposal is to implement a generic Splitter (org.jboss.soa.esb.actions.Splitter) that takes a message, and, using Smooks, separate the message onto diferent messages (individual messages) and send those individual messages to others message channels. Here's a example of this action: <action name="splitter" class="org.jboss.soa.esb.actions.Splitter"> <property name="destinations"> <route-to service-category="Enterprise Business Services" service-name="FirstService"> <message-splitter smooksConfig="/META-INF/smooks-res-1.xml" resultType="STRING" /> </route-to> <route-to service-category="Enterprise Business Services" service-name="SecondService"> <message-splitter smooksConfig="/META-INF/smooks-res-2.xml" resultType="JAVA" /> </route-to> </property> </action> I've implemented this action and it is fully working in the following enviroment: OS: Red Hat Enterprise Linux 5 JVM: Sun JDK 1.5-16 JBoss ESB 4.5 I would like that this feature would be available in the JBoss ESB and the SOA Platform product, since, I've customers that asked me for this kind of feature. -- 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

15 years, 7 months

3
8
0 / 0

[JBoss JIRA] Created: (JBESB-2849) Add caching of JAXR connections

by Kevin Conner (JIRA)

Add caching of JAXR connections ------------------------------- Key: JBESB-2849 URL: https://jira.jboss.org/jira/browse/JBESB-2849 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Registry and Repository Affects Versions: 4.6 Reporter: Kevin Conner Assignee: Kevin Conner Fix For: 4.7 These are heavyweight objects, especially when integrating juddi v3. We should be caching these to reduce the impact. -- 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

15 years, 7 months

2
6
0 / 0

[JBoss JIRA] Created: (JBESB-3009) GettingStarted.odt -> Maven/JDocbook project contribution

by Darrin Mison (JIRA)

GettingStarted.odt -> Maven/JDocbook project contribution --------------------------------------------------------- Key: JBESB-3009 URL: https://jira.jboss.org/jira/browse/JBESB-3009 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Reporter: Darrin Mison Attachments: Getting_Started_Guide.zip This is a conversion of existing content of the trunk GettingStarted.odt to docbook XML with a Maven pom.xml to build it. source: https://svn.jboss.org/repos/labs/labs/jbossesb/trunk/product/docs/Getting... Revision 30054 Let me know your thoughts and I can continue on with the other documents. Note that the content is word for word, only a few obvious spelling mistakes were corrected. The Author list is based on the SVN log for the file The Legal Notice is a slightly massaged version from the .odt and would need to be verified. The file layout is also compatible with Publican for easy integration into SOA Platform documentation. -- 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

15 years, 7 months

1
4
0 / 0

[JBoss JIRA] Created: (JBESB-880) The ESB is blocked under heavy load when using JMS

by Jiri Pechanec (JIRA)

The ESB is blocked under heavy load when using JMS -------------------------------------------------- Key: JBESB-880 URL: http://jira.jboss.com/jira/browse/JBESB-880 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta, Transports Affects Versions: 4.2 Milestone Release 3 Environment: RHEL 5, PostgreSQL Reporter: Jiri Pechanec Assigned To: Mark Little Priority: Blocker When the ESB is forced to process a huge batch of messages then it blocks completely. The ESB configuration was just one service with one listener and gateway. Both gateway and listener are using JMS. The testing was executed twice using one and then four threads per listener and gateway. The service contains two actions that serves only for message counting. If you try to send 10000 messages sized around 20 KB it will probaly block after few minutes of processing. The ESB do not respond to TERM signal and even JMX console is not available. The only solution is to kill process violently. With the smaller messages the block does not happend or happends after bigger amount of messages. The sender is generating following log messages [Timer-1][BisocketServerInvoker] org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlMonitorTimerTask@201d592a: detected failure on control connection Thread[control: Socket[addr=/10.34.34.47,port=2660,localport=51957],5,main]: requesting new control connection We can not exclude problem in JBoss Messaging itself but when we tried to use plain JMS without ESB we were able to send/receive 300000 messages without any problem. Moreover the more messages were processed the longer time it takes for the next batch to be processed. -- 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

15 years, 7 months

7
33
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

15 years, 7 months

3
9
0 / 0

[JBoss JIRA] Created: (JBESB-1900) Current system date in sql-provider where-condition

by Raghavan TV (JIRA)

Current system date in sql-provider where-condition --------------------------------------------------- Key: JBESB-1900 URL: https://jira.jboss.org/jira/browse/JBESB-1900 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Environment: JBoss ESB 4.3GA + JBoss 4.2.2 or JBOss 4.0.0 + Oracle 10g + Windows Xp or HP-UX 11.0 Reporter: Raghavan TV I have a simple table where I store my Orders. e.g. DB - Oracle 10g Table ORDER_QUEUE ---------------------------------------- ORDER_ID NUMBER(5) FIELD1 VARCHAR2(10) FIELD2 VARCHAR2(10) ORDER_DATE DATE ESB_STATUS VARCHAR2(1) TIMESTAMP_COL DATE ----------------------------------------- My requirement is to process only those records where ORDER_DATE = Current System Date that hosts my AppServer Am trying to work with the sample provided. I updated the where condition as follows and it works fine. <sql-bus busid="helloSQLChannel" > <sql-message-filter tablename="ORDER_QUEUE" status-column="ESB_STATUS" where-condition="TO_DATE(ORDER_DATE,'DD-MON-YYYY') = (SELECT TO_DATE(SYSDATE,'DD-MON-YYYY') FROM DUAL)" message-column="message" message-id-column="ORDER_ID" insert-timestamp-column="TIMESTAMP_COL" /> </sql-bus> [where-condition="TO_CHAR(ORDER_DATE,'DD-MON-YYYY') = (SELECT TO_CHAR(SYSDATE,'DD-MON-YYYY') FROM DUAL)"] But the query is more specific to a Oracle DB. If I decide to change the provider in the future, then this filter will fail! Also if the DB and AppServer are in different TZ, we have a problem Is there some other workaround to use the AppServer Date in the where-condition ? -- 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

15 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBESB-3085) Loading of DRL Files in ContentBasedRouter

by Fernando Ribeiro (JIRA)

Loading of DRL Files in ContentBasedRouter ------------------------------------------ Key: JBESB-3085 URL: https://jira.jboss.org/jira/browse/JBESB-3085 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Content Based Routing Affects Versions: 4.7 Reporter: Fernando Ribeiro Unlike XsltAction, for example, ContentBasedRouter tries to find the template file in the file system before loading it from the classpath. // Get the properties file stream... if (ruleSetFile.exists()) { try { ruleStream = new FileInputStream(ruleSetFile); } catch (FileNotFoundException e) { throw new MessageRouterException("Unable to open rule properties file '" + ruleSetFile.getAbsolutePath() + "'.", e); } lastLoaded = ruleSetFile.lastModified(); } else { ruleStream = ClassUtil.getResourceAsStream(ruleSetConfig, AbstractPropertyRulesRouter.class); } (from AbstractPropertyRulesRouter.java) It is an easy miss because it is the only parameter that can't begin with "/". -- 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

15 years, 8 months

3
13
0 / 0

[JBoss JIRA] Created: (JBESB-776) Need a Maven ESB Archetype

by Tom Cunningham (JIRA)

Need a Maven ESB Archetype -------------------------- Key: JBESB-776 URL: http://jira.jboss.com/jira/browse/JBESB-776 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Tooling Reporter: Tom Cunningham Assigned To: Tom Cunningham Fix For: 5.0 We have a maven task which compiles an .esb package. We should also have a maven "archetype" which creates the preferred project layout for Maven. See for details on archetypes http://maven.apache.org/plugins/maven-archetype-plugin/ -- 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

15 years, 8 months

4
3
0 / 0

[JBoss JIRA] Created: (JBESB-3311) ReplyTo EPR must be manually reset after Aggregator action is used

by Kevin Conner (JIRA)

ReplyTo EPR must be manually reset after Aggregator action is used ------------------------------------------------------------------ Key: JBESB-3311 URL: https://jira.jboss.org/jira/browse/JBESB-3311 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Content Based Routing Affects Versions: 4.8 Reporter: David van Balen Fix For: 4.9 The ESB depends on the message's replyTo to know where to send a reply in a RequestResponse service. However, the Aggregator action makes no attempt to preserve the replyTo when it creates an aggregate message for a series. In most cases, I would think the replyTo on the aggregated messages would be the same, so adding it onto the resulting aggregated message would seem like a good idea. Otherwise, it has to be handled manually in the assembler action. -- 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

15 years, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (JBESB-3310) Aggregator meta data in properties

by Kevin Conner (JIRA)

Aggregator meta data in properties ---------------------------------- Key: JBESB-3310 URL: https://jira.jboss.org/jira/browse/JBESB-3310 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Content Based Routing Affects Versions: 4.8 Reporter: Kevin Conner Fix For: 4.9 The MessageMulticaster creates an aggregation id and stores this value in message properties. Normally this does not prove to be an issue but when using invm transport it may cause issues. When the message is sent to multiple services, using pass by reference semantics, then all services will see the *same* properties and may, depending on timing, see the same aggregation id. The aggregation value should really be in the message context as this section is always duplicated when creating a reference, never shared. The problem we face is that users may already be referencing the property, especially if they are creating a fresh response message, so we need to think about handling this. -- 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

15 years, 8 months

1
3
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues June 2010