August 2007 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-746) Potential memory leak in Aggregator

by Jiri Pechanec (JIRA)

Potential memory leak in Aggregator ----------------------------------- Key: JBESB-746 URL: http://jira.jboss.com/jira/browse/JBESB-746 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.2 Milestone Release 3 Reporter: Jiri Pechanec Assigned To: Mark Little Priority: Minor There is minor potential memory leak in Aggregator action. 1) The message is in timeout 2) The process method is started by receiveing one part of timeout message 3) Timeout checker checks the same message 4) Regular process creates aggregated message and removes the record in notification HashMap 5) Timout checker sends a notfificaion message and creates the record in notification HashMap 6) Regular process method receives notification message and ignores it as already timed out 7) The record remains in notification map Recommended solution Add _notified.remove(uuId) call to the branch that handles ignoring already timed out messages. -- 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

18 years, 5 months

3
6
0 / 0

[JBoss JIRA] Created: (JBESB-719) The messages can be lost in case of ESB termination

by Jiri Pechanec (JIRA)

The messages can be lost in case of ESB termination --------------------------------------------------- Key: JBESB-719 URL: http://jira.jboss.com/jira/browse/JBESB-719 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.2 Milestone Release 3 Reporter: Jiri Pechanec Assigned To: Mark Little Even if the ESB is using internally reliable JMS as a transport the messages can be lost during ESB termination. The reasons for this behaviour are two 1) ESB uses internally queue sessions with AUTO_ACK flag 2) Pick-up and deliver couriers works in different session Proposed solution 1) Change flag to CLIENT_ACK 2) JMS sessions are allocated from the pool using JMSConnectionPool.getQueueSession(). If the allocated session is stored into ThreadLocal variable and returned by the subsequent calls by the same thread and get commited on call JMSConnectionPool.closeSession() then all internal message transfers via JMS will be done in transaction - one transfer/one transaction. -- 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

18 years, 5 months

4
10
0 / 0

[JBoss JIRA] Created: (JBESB-832) ${jboss.bind.address} support in ESB configuration files

by Matt Hicks (JIRA)

${jboss.bind.address} support in ESB configuration files -------------------------------------------------------- Key: JBESB-832 URL: http://jira.jboss.com/jira/browse/JBESB-832 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Configuration Affects Versions: 4.2 Milestone Release 3 Environment: RHEL 5 / JBoss 4.2.1 Reporter: Matt Hicks Assigned To: Mark Little Fix For: 4.2 Milestone Release 3 We use virtual IPs supported by the JBoss binding parameter on startup (e.g. bin/run.sh -c esb -b 172.17.0.1). However, there are several problems with the ESB configuration when doing this. The first file is simple: * <JBOSS_HOME>/deploy/jbossesb.sar/jbossesb-properties.xml This file needs every instance of 'localhost' changed to '${jboss.bind.address}' and it works. The next 3 files aren't as simple since JBoss doesn't support property replacement in properties files to my knowledge: * <JBOSS_HOME>/deploy/juddi-service.sar/juddi.war/WEB-INF/juddi.properties * <JBOSS_HOME>/deploy/jbossesb.sar/esb.juddi.properties * <JBOSS_HOME>/deploy/smooks.esb/smooks.esb.properties These files need to have the same property dynamically looked up based on the binding or might need to be converted to XML to have the property replaced. -- 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

18 years, 5 months

6
13
0 / 0

[JBoss JIRA] Created: (JBESB-871) Configure core ESB services using ServiceBindingManager

by Kevin Conner (JIRA)

Configure core ESB services using ServiceBindingManager ------------------------------------------------------- Key: JBESB-871 URL: http://jira.jboss.com/jira/browse/JBESB-871 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Configuration Reporter: Kevin Conner Assigned To: Kevin Conner We should be able to configure the core ESB services using the ServiceBindingManager. The configuration should include the following esb.juddi.properties smooks.esb.properties jbossesb-properties.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

18 years, 6 months

1
6
0 / 0

[JBoss JIRA] Created: (JBESB-736) ReceiveJMSMessage class is confusing and partly buggy

by Jiri Pechanec (JIRA)

ReceiveJMSMessage class is confusing and partly buggy ----------------------------------------------------- Key: JBESB-736 URL: http://jira.jboss.com/jira/browse/JBESB-736 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Examples Affects Versions: 4.2 Milestone Release 3 Reporter: Jiri Pechanec Assigned To: Mark Little Priority: Optional The class used in samples for reading JMS messages from the queue is confusing and partly buggy. The class repeatedly reads from the queue directly and repeatedly sets up own listener. Also it creates an infinite number of sessions that are not closed. Recommended solution In method main cut the call of method receive one from the infinite loop and put it before the loop. Place a sleep method inside the infinite loop. In that way both direct reading and listener pattern will be demonstrated. Initialization of all resources will be executed only once. -- 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

18 years, 6 months

4
7
0 / 0

[JBoss JIRA] Created: (JBESB-810) jBPM Admin Console Build

by Burr Sutter (JIRA)

jBPM Admin Console Build ------------------------ Key: JBESB-810 URL: http://jira.jboss.com/jira/browse/JBESB-810 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: BPM Affects Versions: 4.2 Milestone Release 3 Reporter: Burr Sutter Assigned To: Mark Little Priority: Critical Fix For: 4.2.1 The build script for jBPM's Admin Console must be augmented to allow for the creation of an ESB "friendly" .war file. Currently the jbpm-console.war contains JSF libs which are incompatible with App Server 4.2. Plus, the ESB version of the jbpm-console.war should NOT include the jbpm/jpdl jars since those are already found in the jbpm.esb directory. Finally, the jbpm-console.war should be deployed in the jbpm.esb via ESB deployment build/installation script. -- 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

18 years, 6 months

5
8
0 / 0

[JBoss JIRA] Created: (JBESB-735) Documentation for the jBPM 3.2.1 Admin Console with the ESB is needed

by Burr Sutter (JIRA)

Documentation for the jBPM 3.2.1 Admin Console with the ESB is needed --------------------------------------------------------------------- Key: JBESB-735 URL: http://jira.jboss.com/jira/browse/JBESB-735 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: BPM Affects Versions: 4.2 Milestone Release 2 Reporter: Burr Sutter Assigned To: Mark Little Fix For: 4.2 My notes on how to make it run with AS 4.2 with Java 5 are here: http://jboss.org/index.html?module=bb&op=viewtopic&t=112908 And here: Steps (for AS 4.2 + Messaging 1.3 + ESB 4.2MR3) 1. Deploy attached hypersonic databases to the server\messaging\data\hypersonic director. jbpmDB.properties, jbpmDB.script 2. Deploy attached datasource - jbpm-ds.xml into the server\messaging\deploy directory 3. Deploy attached jbpm-console.war - created from CVS because the one in the jBPM3.2.1 suite do not work with Java 5 4. Modify the conf\login-config.xml be inserting the following: <application-policy name = "jbpm"> <authentication> <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required"> <module-option name="dsJndiName">java:/JbpmDS</module-option> <module-option name="principalsQuery"> SELECT PASSWORD_ FROM JBPM_ID_USER WHERE NAME_=? </module-option> <module-option name="rolesQuery"> SELECT g.NAME_ ,'Roles' FROM JBPM_ID_USER u, JBPM_ID_MEMBERSHIP m, JBPM_ID_GROUP g WHERE g.TYPE_='security-role' AND m.GROUP_ = g.ID_ AND m.USER_ = u.ID_ AND u.NAME_=? </module-option> </login-module> </authentication> </application-policy> 5. Modify the server\messaging\deploy\jbpm.esb\hibernate.cfg.xml so that it uses the DS defined in step 2. The result should look something like the following: <property name="hibernate.dialect">org.hibernate.dialect.HSQLDialect</property>  <property name="hibernate.cache.provider_class">org.hibernate.cache.HashtableCacheProvider</property>  <property name="hibernate.connection.datasource">java:/JbpmDS</property>  6. Start your server with run -c messaging N . http://localhost:8080/jbpm-console -- 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

18 years, 6 months

6
15
0 / 0

[JBoss JIRA] Created: (JBESB-858) Make sure we use the right versions of dependant components (part 2)

by Kurt Stam (JIRA)

Make sure we use the right versions of dependant components (part 2) -------------------------------------------------------------------- Key: JBESB-858 URL: http://jira.jboss.com/jira/browse/JBESB-858 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.2 Reporter: Kurt Stam Assigned To: Kurt Stam Fix For: 4.2.1 For 4.2 we have: JBM 1.4 CR1 Drools 4.0GA JBWS 2.0.0GA JBAS 4.2.1GA jBPM 3.2.1 For 4.2.1 we need to upgrade to JBM 1.4 GA Drools 4.0.x maintenance release JBWS 2.0x? look at removing ejb3 dependency (may not need an update, but maybe a config issue) jBPM 3.2.2 to fix currently known issues for the ESB with the 3.2.1 build. -- 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

18 years, 6 months

3
13
0 / 0

[JBoss JIRA] Created: (JBESB-855) JMSCourier does not return JMS Session to pool in jmsConnectRetry

by Daniel Bevenius (JIRA)

JMSCourier does not return JMS Session to pool in jmsConnectRetry ----------------------------------------------------------------- Key: JBESB-855 URL: http://jira.jboss.com/jira/browse/JBESB-855 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transports Reporter: Daniel Bevenius Assigned To: Mark Little Fix For: 4.2.1 Google group ref : http://groups.google.se/group/jbossesb/browse_frm/thread/477d6a3bca232ab2... We started to see this message in our ESB server log: [org.jboss.internal.soa.esb.rosetta.pooling.JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again I took a look at JMSCouriers jmsConnectRetry() method and this section caught my attention: private void jmsConnectRetry (Exception exc) { _logger.debug("JMS error. Attempting JMS reconnect.", exc); _jmsSession = null; _messageProducer = null; _messageConsumer = null; ... } Should the session be returned to the pool instead of only setting it to null? Something like this perhaps: _pool.releaseSession( _jmsSession ); /Daniel -- 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

18 years, 6 months

2
6
0 / 0

[JBoss JIRA] Created: (JBESB-943) Document wiretap actions in messageActionGuide

by Kevin Conner (JIRA)

Document wiretap actions in messageActionGuide ---------------------------------------------- Key: JBESB-943 URL: http://jira.jboss.com/jira/browse/JBESB-943 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.2 Milestone Release 3 Reporter: Kevin Conner Assigned To: Mark Little -- 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

18 years, 6 months

3
6
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues August 2007