October 2007 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-1200) stopping AbstractThreadedManagedLifecycle after the thread has finished causes exception

by Kevin Conner (JIRA)

stopping AbstractThreadedManagedLifecycle after the thread has finished causes exception ---------------------------------------------------------------------------------------- Key: JBESB-1200 URL: http://jira.jboss.com/jira/browse/JBESB-1200 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.2.1 IR2 Reporter: Kevin Conner Assigned To: Kevin Conner Fix For: 4.2.1 Stopping a threaded lifecycle which has terminated early results in the following exception. org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleException: Thread is not running at org.jboss.soa.esb.listeners.lifecycle.AbstractThreadedManagedLifecycle.doStop(AbstractThreadedManagedLifecycle.java:149) Attempts to stop the thread should only happen if it is still running, otherwise it should be silent. -- 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

16 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBESB-1169) EPR copy is shallow

by Kevin Conner (JIRA)

EPR copy is shallow ------------------- Key: JBESB-1169 URL: http://jira.jboss.com/jira/browse/JBESB-1169 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.2.1 IR1 Reporter: Kevin Conner Assigned To: Mark Little Fix For: 4.2.1 There is a copy method on the EPR class (not the java way of doing things but that is another matter) and it does a shallow copy. If you alter any of the PortReference attributes after copying then they are reflected in the original EPR. -- 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

16 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBESB-1178) FTP Gateway Listener threads hang on Firewall reboot.

by Philippe Ignace (JIRA)

FTP Gateway Listener threads hang on Firewall reboot. ----------------------------------------------------- Key: JBESB-1178 URL: http://jira.jboss.com/jira/browse/JBESB-1178 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.0 Environment: JBOSS-AS 4.0.4,JBOSS- ESB 4.0, JVM Sun 1.5 RedHat linux. Reporter: Philippe Ignace Assigned To: Mark Little There is a firewall between the FTP Gateway and the FTP server. The firewall rebooted, cleans the FTP session tables. The socket used used for FTP communication are set with a timeout of 0 (indefinite) the client theads does not get any communication exception, but it does not get any answer either => the thread get indefinitely stuck. The server must be rebooted. There is to my knowledge no way to configure a timeout in the "org.jboss.internal.soa.util.EdtFtpImpl" class. Suggested workaround/patch : Use a System property to set the value : Add the following code : int timeOut = Integer.getInteger("jboss.esb.socket.timeout", -1); if (timeOut>=0) { try { m_oConn.setTimeout(timeOut); } catch (IOException e) { throw new RemoteFileSystemException("Failed while setting timeout=" + timeOut, e); } _logger.debug("TimeOut socket FTP=" + timeOut); } After the checkParms() invocation inside the private void initialize(boolean ...) method Same issue with the SFTP client, I guess (I am not using it though). Thanks. -- 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

16 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBESB-1180) Tidy up error handling in action pipeline text

by Mark Little (JIRA)

Tidy up error handling in action pipeline text ---------------------------------------------- Key: JBESB-1180 URL: http://jira.jboss.com/jira/browse/JBESB-1180 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.2.1 IR1 Reporter: Mark Little Assigned To: Mark Little Priority: Minor Fix For: 4.2.1 -- 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

16 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBESB-1184) Make sure ObjectMapper docs mentions quoting rule

by Mark Little (JIRA)

Make sure ObjectMapper docs mentions quoting rule ------------------------------------------------- Key: JBESB-1184 URL: http://jira.jboss.com/jira/browse/JBESB-1184 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.2.1 IR1 Reporter: Mark Little Assigned To: Mark Little Priority: Trivial Fix For: 4.2.1 -- 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

16 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBESB-1202) NotifyFiles is very intollerant of the format of the URI attribute values

by Tom Fennelly (JIRA)

NotifyFiles is very intollerant of the format of the URI attribute values ------------------------------------------------------------------------- Key: JBESB-1202 URL: http://jira.jboss.com/jira/browse/JBESB-1202 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta, Transports Affects Versions: 4.2.1 IR2 Reporter: Tom Fennelly Assigned To: Tom Fennelly Fix For: 4.2.1 Balks on the likes of "file://H:/Jboss/ESB/trunk/product/samples/quickstarts/helloworld_file_notifier/results.log". Should be more user friendly. -- 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

16 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBESB-1050) DBMessageStoreImpl: Cannot change transaction isolation level in the middle of a transaction. Postgres

by Daniel Bevenius (JIRA)

DBMessageStoreImpl: Cannot change transaction isolation level in the middle of a transaction. Postgres ------------------------------------------------------------------------------------------------------ Key: JBESB-1050 URL: http://jira.jboss.com/jira/browse/JBESB-1050 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Message Store Reporter: Daniel Bevenius Priority: Minor Fix For: 4.2.1 IR1 We have been seeing this DEBUG level message when we have more then one message with the same classification in the message store: 2007-09-14 10:08:05,376 DEBUG [org.jboss.internal.soa.esb.persistence.format.db.DBMessageStoreImpl] Deadlocks may occur under normal processing 2007-09-14 10:08:05,376 DEBUG [org.jboss.internal.soa.esb.persistence.format.db.DBMessageStoreImpl] Cannot change transaction isolation level in the middle of a transaction. org.postgresql.util.PSQLException: Cannot change transaction isolation level in the middle of a tran saction. at org.postgresql.jdbc2.AbstractJdbc2Connection.setTransactionIsolation(AbstractJdbc2Connection. java:733) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.setJdbcTransactionIsolation(Base WrapperManagedConnection.java:534) at org.jboss.resource.adapter.jdbc.WrappedConnection.setTransactionIsolation(WrappedConnection.j ava:390) at org.jboss.internal.soa.esb.persistence.format.db.DBMessageStoreImpl.redeliver(DBMessageStoreI mpl.java:318) at org.jboss.soa.esb.actions.MessageRedeliverer.process(MessageRedeliverer.java:74) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline .java:265) at org.jboss.soa.esb.listeners.ScheduleListener.onSchedule(ScheduleListener.java:108) at org.jboss.soa.esb.schedule.ScheduleProvider$ESBScheduledJob.execute(ScheduleProvider.java:212 ) at org.quartz.core.JobRunShell.run(JobRunShell.java:202) The code lines above might not directly match the ones in the current trunk as I've made a few modifications locally to support a simple redelivery of messages described in this dev forum thread: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116023&start=10 This following line of code in the redeliver method is causing this message: con = mgr.getConnection(); con.setAutoCommit(false); con.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED); The redeliver method is called by MessageRedeliverer action. The first message uid is successful but the second call will log the above message. But I do think that this will be an issue when using postgres. Some info about postgres and its transaction isolation levels: Quote: "In postgres, you can use all four possible transaction isolation levels. Internally, there are only two distinct isolation levels, which correspond to the levels Read Committed and Serializable. When you select the level Read Uncommitted you actually get Read Committed, and when you select Repeatable Read you really get Serializable, so the actual isolation level may be stricter than what you select." -- 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

16 years, 8 months

4
8
0 / 0

[JBoss JIRA] Created: (JBESB-1193) TransformXML2POJOTest fails on hudson

by Kevin Conner (JIRA)

TransformXML2POJOTest fails on hudson ------------------------------------- Key: JBESB-1193 URL: http://jira.jboss.com/jira/browse/JBESB-1193 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Examples, Testing Affects Versions: 4.2.1 IR1 Reporter: Kevin Conner Assigned To: Tom Fennelly Fix For: 4.2.1 IR2 The reason this fails is because the output is now sensitive to the timezone. -- 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

16 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JBESB-1194) AbstractFileGateway has invalid responder test

by Kevin Conner (JIRA)

AbstractFileGateway has invalid responder test ---------------------------------------------- Key: JBESB-1194 URL: http://jira.jboss.com/jira/browse/JBESB-1194 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.2.1 IR1 Reporter: Kevin Conner Assigned To: Kevin Conner Fix For: 4.2.1 IR2 The AbstractFileGateway has an invalid test for responder, intended for LegacyMessageComposerAdapter. The test result is passed into ListenerUtil.getMaxMillisGatewayWait as an additional check but it is not needed. Any message composer which is not a LegacyMessageComposerAdapter will always fail the call to get max millis as the default value of the test is false. The test actually serves no purpose as the existence of the responder is checked when the configuration is created and an exception thrown if invalid. -- 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

16 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBESB-1157) Notifier ignores default location

by Burr Sutter (JIRA)

Notifier ignores default location --------------------------------- Key: JBESB-1157 URL: http://jira.jboss.com/jira/browse/JBESB-1157 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.2.1 IR1 Reporter: Burr Sutter Assigned To: Mark Little Fix For: 4.2.1 org.jboss.soa.esb.actions.Notifier.java pulls the message content using this technique: message.getBody().get(BytesBody.BYTES_LOCATION) I believe it should be message.getBody().get() Use Case: A message containing "STUFF" flows through the JMS Gateway, through the native listener, into the action chain. MyAction.java - modifies the appends " HAPPENS" to the message data using this technique: String origData = (String) message.getBody().get(); message.getBody().add(origData + " HAPPENS"); the next action in the chain is the Notifier: <action name="notificationAction" class="org.jboss.soa.esb.actions.Notifier"> <property name="okMethod" value="notifyOK" /> <property name="notification-details"> <NotificationList type="OK"> <target class="NotifyConsole" /> </NotificationList> </property> </action> which displays "STUFF", just the original inbound data, not that message that was modified by the actions above it. -- 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

16 years, 8 months

4
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues October 2007