[JBoss JIRA] (JBESB-3798) Ftp Provider is processing sub-directories in loop when input-suffix is not specified
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3798:
-------------------------------------
Summary: Ftp Provider is processing sub-directories in loop when input-suffix is not specified
Key: JBESB-3798
URL: https://issues.jboss.org/browse/JBESB-3798
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Adapters
Affects Versions: 4.11 CP1
Reporter: Tom Cunningham
Assignee: Tom Cunningham
Fix For: 4.11 CP1
>From Vinicius :
When input-suffix is not specified on ftp-message-filter property of
ftp-provider, the ESB will try to process all files and folders, therefore, the
process will become in loop.
How reproducible:
Easy
Steps to Reproduce:
1. Setup a Ftp Server;
2. Create a directory structure similar as follows:
<ROOT_FOLDER>
|
|----<SUB_FOLDER_1>
|----<SUB_FOLDER_2>
3.Create an ESB project with a similar ftp-provider configuration as follows:
<ftp-provider name="<name>" hostname="<hostname>">
<ftp-bus busid="<busIdname>" >
<ftp-message-filter
protocol="ftp"
username="<user>"
password="<PASS>"
input-suffix=""
directory=""
post-directory="<SUB_FOLDER_1>"
error-directory="<SUB_FOLDER_2>"/>
</ftp-bus>
</ftp-provider>
<services>
<service category="myCategory" description="Hello World File Action (esb
listener)" name="myFileListener" invmScope="GLOBAL">
<listeners>
<ftp-listener busidref="helloFTPChannel" is-gateway="true"
name="FtpGateway" scheduleidref="1-sec-trigger" />
</listeners>
<actions mep="OneWay">
<action class="org.jboss.soa.esb.actions.SystemPrintln"
name="print-after">
<property name="message" value="Message after!" />
</action>
</actions>
</service>
</services>
Actual results:
All files and sub-folders will be processed in loop;
All files and sub-folders will be renamed in loop. Example:
README.txt.esbWorking.esbWorking.esbWorking.esbWorking.esbWorking.esbWorking
Expected results:
Only files should be processed.
Additional Info:
Our current Ftp implementation org.jboss.internal.soa.esb.util.FtpImpl [1], has
the following method to list remote files:
protected FTPClient m_oConn ; *Apache FTp Client - commons-net-2.0.jar
public String[] getFileListFromRemoteDir (String p_sSuffix)
throws RemoteFileSystemException, IOException
{
String sSuffix = (null == p_sSuffix) ? "*" : "*" + p_sSuffix;
try
{
changeRemoteDirectory() ;
return m_oConn.listNames(sSuffix) ;
}
catch (final IOException ioe)
{
throw new RemoteFileSystemException(ioe) ;
}
}
As we can see, we're using the "listNames()" [2] method, which returns all
files and folders within the current directory.
Furthermore, this class provides a "listFiles()" [3] method which returns an
array of FtpFile [4] objects, and finally, has methods to validate whether
we're dealing with a file or a folder as well - isFile() [5] / isDirectory()
[6]
Links:
[1] -
http://anonsvn.jboss.org/repos/labs/labs/jbossesb/tags/JBESB_4_7_CP1_ER10...
[2] -
http://commons.apache.org/net/api-3.1/org/apache/commons/net/ftp/FTPClien...
[3] -
http://commons.apache.org/net/api-3.1/org/apache/commons/net/ftp/FTPClien...
[4] -
http://commons.apache.org/net/api-3.1/org/apache/commons/net/ftp/FTPFile....
[5] -
http://commons.apache.org/net/api-3.1/org/apache/commons/net/ftp/FTPFile....
[6] -
http://commons.apache.org/net/api-3.1/org/apache/commons/net/ftp/FTPFile....
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
- 2
- 4
[JBoss JIRA] (JBESB-3795) Camel gateway doesn't work when spaces are in gateway URL
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3795:
-------------------------------------
Summary: Camel gateway doesn't work when spaces are in gateway URL
Key: JBESB-3795
URL: https://issues.jboss.org/browse/JBESB-3795
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Adapters
Affects Versions: 4.11 CP1
Reporter: Tom Cunningham
Assignee: Tom Cunningham
Fix For: 4.11 CP1
>From : https://bugzilla.redhat.com/show_bug.cgi?id=814297
In some Camel components there is need to have spaces in gateway URL. For
example when used Camel SQL component[1] in ESB application, it should look
like this:
"esbschedule:5000:sql:select unique_id,data_column from
camel_sql_entry_data?dataSourceRef=java:/DefaultDS"
When you try to deploy application with exception is thrown:
Caused by: java.net.URISyntaxException: Illegal character in opaque part at
index 10: sql:select unique_id,data_column from
camel_sql_entry_data?dataSourceRef=java:/DefaultDS
This bug depends on previous bug I've reported about SQL gateway so It has to
be resolved first.
Deployment log and reproducer is attached.
1. Start server
2. Unzip reproducer to quickstarts directory
3. Configure quickstarts.properties to target your server profile
4. from camel_sql_spaces directory run: ant deploy
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
- 2
- 5
[JBoss JIRA] (JBESB-3794) ServiceInvoker behaviour is inconsistent when used with transactions
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3794:
-------------------------------------
Summary: ServiceInvoker behaviour is inconsistent when used with transactions
Key: JBESB-3794
URL: https://issues.jboss.org/browse/JBESB-3794
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Transports
Affects Versions: 4.10
Environment: JBoss SOA 5.2.0 Platform
Reporter: Michael Burman
Assignee: Tom Cunningham
Fix For: 4.10 CP2
The ServiceInvoker behaviour is inconsistent when it comes to XA transactions. If the delivery fails with ServiceInvoker (there's a network timeout or something), the transaction is still committed, because it does not throw a RuntimeException. So instead of rolling back everything you just did in your actions, the staticRouter or such would commit the process and then throw this to DLQ. So when you run it from DLQ, you would again write to the database and so on. With SmooksSplitter this might cause some messages to go through and some not and other weird behaviour.
One fix would be to patch ServiceInvoker deliverAsync (as an example, deliverSync should be fixed also):
### Eclipse Workspace Patch 1.0
#P JBossESB
Index: rosetta/src/org/jboss/soa/esb/client/ServiceInvoker.java
===================================================================
--- rosetta/src/org/jboss/soa/esb/client/ServiceInvoker.java (revision 37896)
+++ rosetta/src/org/jboss/soa/esb/client/ServiceInvoker.java (working copy)
@@ -46,9 +46,9 @@
import org.jboss.soa.esb.couriers.Courier;
import org.jboss.soa.esb.couriers.CourierException;
import org.jboss.soa.esb.couriers.CourierFactory;
-import org.jboss.soa.esb.couriers.CourierTimeoutException;
import org.jboss.soa.esb.couriers.CourierMarshalUnmarshalException;
import org.jboss.soa.esb.couriers.CourierServiceBindException;
+import org.jboss.soa.esb.couriers.CourierTimeoutException;
import org.jboss.soa.esb.couriers.CourierTransportException;
import org.jboss.soa.esb.couriers.CourierUtil;
import org.jboss.soa.esb.couriers.FaultMessageException;
@@ -57,6 +57,7 @@
import org.jboss.soa.esb.listeners.ha.LoadBalancePolicy;
import org.jboss.soa.esb.listeners.ha.ServiceClusterInfo;
import org.jboss.soa.esb.listeners.ha.ServiceClusterInfoImpl;
+import org.jboss.soa.esb.listeners.jca.JcaGatewayException;
import org.jboss.soa.esb.listeners.message.IncompatibleTransactionScopeException;
import org.jboss.soa.esb.listeners.message.MessageDeliverException;
import org.jboss.soa.esb.listeners.message.MissingServiceException;
@@ -253,6 +254,12 @@
try {
post(message, new EPRInvoker());
} catch (MessageDeliverException mde) {
+
+ // We want to trigger JCA rollback in case of messagedeliver exception
+ if(isTransactional()) {
+ throw new JcaGatewayException(mde);
+ }
+
if (message.getProperties().getProperty(RedeliverStore.IS_REDELIVERY)==null
&& asyncRedelivery(message)
&& !service.equals(dlqService)) {
Here's a quickstart that provides a small example (replace correctBehaviour="true" to get JMS rollbacks), it just tries to call some nonexistant gateway to throw MessageDeliveryException (if there's a proper way to cause timeout in the code, then let me know, but the exception is never the less the same).
https://s3-eu-west-1.amazonaws.com/yak/jboss/jms_transacted_fail.zip
Once you run it with original settings and it fails, you still end up with lines in the database.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
- 1
- 4