Re: Unconnected sockets not implemented exception in camel-ftp when using ftps
I have now created a JIRA in commons-net for this issue: https://issues.apache.org/jira/browse/NET-327 https://issues.apache.org/jira/browse/NET-327However, I still think we must fix this in camel-ftp by some kind of work-around (maybe similar to the one I proposed in https://issues.apache.org/activemq/browse/CAMEL-2829). Have you had a chance to look at it Claus? /Bengt 2010/6/18 Bengt Rodehav be...@rodehav.com JIRA created: https://issues.apache.org/activemq/browse/CAMEL-2829 https://issues.apache.org/activemq/browse/CAMEL-2829/Bengt 2010/6/18 Bengt Rodehav be...@rodehav.com Claus, I'm not sure what you mean by: I think we should add an option on the endpoint to allow people to turn this on/off. Some would like to reuse existing connections to avoid the connect - upload - disconnect cycle when they upload many files etc. IMO we would not disconnect more often than today. We would just change the connect() method in FtpsOperations so that it creates a new instance of FTPSClient prior to a connection attempt. I assume that since the connect() method is called in the first place, we are not currently connected and there is no way to reuse an existing connection. Am I right? I have made some modifications in camel-ftp along these lines. I will create a JIRA ticket for this bug and attach my changes as diff files to the issue. I just tested my changes and they do solve the problem I have encountered but I haven't tested whether I have introduced any new problems or not. Anyway, this is what I did: *FtpsEndpoint* I added the following members to keep track of the configuration of the FTPSClient: private boolean isNeedClientAuth = false; private KeyManager keyManager; private TrustManager trustManager; I modified the createFtpClient() method so that it doesn't actually create a FTPSClient but only calculates and stores the configuration in the above members. I also renamed it to createFtpsConfiguration() to reflect that. The createRemoteFileOperations() method was also changed accordingly. It no longer interacts directly with an FTPSClient (since it is not created yet). *FtpsOperations* I added the private createFtpsClient() method that takes care of creating an FTPSClient from configuration stored in the FtpsEndpoint. The createFtpsClient() is called in the connect() method just before the call to the real connect() method in the superclass (FtpOperations). I changed the constructor so that it no longer takes a client as an argument. I send null as client to the super class constructor. This is of course a major change in behavior that you need to take a look at it. Neither FtpsOperations nor its super class FtpOperations can no longer assume that a client exists until the first connection attempt has been made. *FtpOperations* I had to make the client member non-final since I now set it on every call to the connect() method in FtpsOperations. BTW, I agree with you that the SFTPClient in commons-net is flawed. It should provide a way to re-initialize itself so that a new connect() could be made. The FTPClient seems to work that way and it also provides a disconnect() method. If they do not intend to support this, then they should at least state, as part of the documentation, that the SFTPClient cannot be reused across multiple connections. I've posted about this on their mailing list but hasn't got any reply yet. Meanwhile the above can be regarded as a (complicated...) work-around. /Bengt 2010/6/18 Claus Ibsen claus.ib...@gmail.com On Thu, Jun 17, 2010 at 11:56 PM, Bengt Rodehav be...@rodehav.com wrote: Claus, Having looked a bit more at the commons-net code it's becoming clear to me that you probably can't just reconnect an FTPSClient once it has entered secure communication mode. I can't find a way to re-initialise an FTPSClient. I tried the disconnect() method (in the super class FTPClient) but it didn't get the FTPSClient out of secure communication mode. To be safe I think we should always start with a newly instantiated FTPSClient when we try to connect. Today the FTPSClient is created by the FtpsEndpoint. I don't think it has to. It could just get all the righ configuration parameters and pass it to FtpsOperations which would then instantiate a new FTPSClient at every connect attempt. If we do it this way for ftps I guess it would make sense with the same setup for plain ftp. What do you think? I think we should add an option on the endpoint to allow people to turn this on/off. Some would like to reuse existing connections to avoid the connect - upload - disconnect cycle when they upload many files etc. And frankly I can't see the problem why a secure connection cannot self heal and be able to re-establish itself. After all FTPSClient got all the connection information. And hence I would consider it a missing feature / glitch in the FTP library. Imagine
Re: Unconnected sockets not implemented exception in camel-ftp when using ftps
On Mon, Jun 21, 2010 at 8:52 AM, Bengt Rodehav be...@rodehav.com wrote: I have now created a JIRA in commons-net for this issue: https://issues.apache.org/jira/browse/NET-327 Good https://issues.apache.org/jira/browse/NET-327However, I still think we must fix this in camel-ftp by some kind of work-around (maybe similar to the one I proposed in https://issues.apache.org/activemq/browse/CAMEL-2829). Have you had a chance to look at it Claus? No sorry I am to busy with other issues but we got the ticket so we will look into it before 2.4 is cut. /Bengt 2010/6/18 Bengt Rodehav be...@rodehav.com JIRA created: https://issues.apache.org/activemq/browse/CAMEL-2829 https://issues.apache.org/activemq/browse/CAMEL-2829/Bengt 2010/6/18 Bengt Rodehav be...@rodehav.com Claus, I'm not sure what you mean by: I think we should add an option on the endpoint to allow people to turn this on/off. Some would like to reuse existing connections to avoid the connect - upload - disconnect cycle when they upload many files etc. IMO we would not disconnect more often than today. We would just change the connect() method in FtpsOperations so that it creates a new instance of FTPSClient prior to a connection attempt. I assume that since the connect() method is called in the first place, we are not currently connected and there is no way to reuse an existing connection. Am I right? I have made some modifications in camel-ftp along these lines. I will create a JIRA ticket for this bug and attach my changes as diff files to the issue. I just tested my changes and they do solve the problem I have encountered but I haven't tested whether I have introduced any new problems or not. Anyway, this is what I did: *FtpsEndpoint* I added the following members to keep track of the configuration of the FTPSClient: private boolean isNeedClientAuth = false; private KeyManager keyManager; private TrustManager trustManager; I modified the createFtpClient() method so that it doesn't actually create a FTPSClient but only calculates and stores the configuration in the above members. I also renamed it to createFtpsConfiguration() to reflect that. The createRemoteFileOperations() method was also changed accordingly. It no longer interacts directly with an FTPSClient (since it is not created yet). *FtpsOperations* I added the private createFtpsClient() method that takes care of creating an FTPSClient from configuration stored in the FtpsEndpoint. The createFtpsClient() is called in the connect() method just before the call to the real connect() method in the superclass (FtpOperations). I changed the constructor so that it no longer takes a client as an argument. I send null as client to the super class constructor. This is of course a major change in behavior that you need to take a look at it. Neither FtpsOperations nor its super class FtpOperations can no longer assume that a client exists until the first connection attempt has been made. *FtpOperations* I had to make the client member non-final since I now set it on every call to the connect() method in FtpsOperations. BTW, I agree with you that the SFTPClient in commons-net is flawed. It should provide a way to re-initialize itself so that a new connect() could be made. The FTPClient seems to work that way and it also provides a disconnect() method. If they do not intend to support this, then they should at least state, as part of the documentation, that the SFTPClient cannot be reused across multiple connections. I've posted about this on their mailing list but hasn't got any reply yet. Meanwhile the above can be regarded as a (complicated...) work-around. /Bengt 2010/6/18 Claus Ibsen claus.ib...@gmail.com On Thu, Jun 17, 2010 at 11:56 PM, Bengt Rodehav be...@rodehav.com wrote: Claus, Having looked a bit more at the commons-net code it's becoming clear to me that you probably can't just reconnect an FTPSClient once it has entered secure communication mode. I can't find a way to re-initialise an FTPSClient. I tried the disconnect() method (in the super class FTPClient) but it didn't get the FTPSClient out of secure communication mode. To be safe I think we should always start with a newly instantiated FTPSClient when we try to connect. Today the FTPSClient is created by the FtpsEndpoint. I don't think it has to. It could just get all the righ configuration parameters and pass it to FtpsOperations which would then instantiate a new FTPSClient at every connect attempt. If we do it this way for ftps I guess it would make sense with the same setup for plain ftp. What do you think? I think we should add an option on the endpoint to allow people to turn this on/off. Some would like to reuse existing connections to avoid the connect - upload - disconnect cycle when they upload many files etc. And frankly I can't see the problem why a secure connection cannot
Re: Unconnected sockets not implemented exception in camel-ftp when using ftps
On Mon, Jun 21, 2010 at 9:11 AM, Bengt Rodehav be...@rodehav.com wrote:
OK
Bengt could you try changing camel-ftp in the RemoteFileProducer
public class RemoteFileProducerT extends GenericFileProducerT
implements ServicePoolAware {
And remove the implements ServicePoolAware which should cause Camel to
not pool it and thus you get a new fresh instance each time.
Then try testing with that to see if that fixes the re-connect issue.
What we can then do is to add some nice option in the endpoint URI so
you can configure the pooling behavior.
2010/6/21 Claus Ibsen claus.ib...@gmail.com
On Mon, Jun 21, 2010 at 8:52 AM, Bengt Rodehav be...@rodehav.com wrote:
I have now created a JIRA in commons-net for this issue:
https://issues.apache.org/jira/browse/NET-327
Good
https://issues.apache.org/jira/browse/NET-327However, I still think we
must fix this in camel-ftp by some kind of work-around (maybe similar to
the
one I proposed in https://issues.apache.org/activemq/browse/CAMEL-2829).
Have you had a chance to look at it Claus?
No sorry I am to busy with other issues but we got the ticket so we
will look into it before 2.4 is cut.
/Bengt
2010/6/18 Bengt Rodehav be...@rodehav.com
JIRA created:
https://issues.apache.org/activemq/browse/CAMEL-2829
https://issues.apache.org/activemq/browse/CAMEL-2829/Bengt
2010/6/18 Bengt Rodehav be...@rodehav.com
Claus,
I'm not sure what you mean by:
I think we should add an option on the endpoint to allow people to
turn this on/off.
Some would like to reuse existing connections to avoid the connect -
upload - disconnect cycle when they upload many files etc.
IMO we would not disconnect more often than today. We would just change
the connect() method in FtpsOperations so that it creates a new
instance of
FTPSClient prior to a connection attempt. I assume that since the
connect()
method is called in the first place, we are not currently connected and
there is no way to reuse an existing connection. Am I right?
I have made some modifications in camel-ftp along these lines. I will
create a JIRA ticket for this bug and attach my changes as diff files
to the
issue. I just tested my changes and they do solve the problem I have
encountered but I haven't tested whether I have introduced any new
problems
or not.
Anyway, this is what I did:
*FtpsEndpoint*
I added the following members to keep track of the configuration of the
FTPSClient:
private boolean isNeedClientAuth = false;
private KeyManager keyManager;
private TrustManager trustManager;
I modified the createFtpClient() method so that it doesn't actually
create
a FTPSClient but only calculates and stores the configuration in the
above
members. I also renamed it to createFtpsConfiguration() to reflect
that.
The createRemoteFileOperations() method was also changed accordingly.
It
no longer interacts directly with an FTPSClient (since it is not
created
yet).
*FtpsOperations*
I added the private createFtpsClient() method that takes care of
creating
an FTPSClient from configuration stored in the FtpsEndpoint. The
createFtpsClient() is called in the connect() method just before the
call to
the real connect() method in the superclass (FtpOperations).
I changed the constructor so that it no longer takes a client as an
argument. I send null as client to the super class constructor. This is
of
course a major change in behavior that you need to take a look at it.
Neither FtpsOperations nor its super class FtpOperations can no longer
assume that a client exists until the first connection attempt has been
made.
*FtpOperations*
I had to make the client member non-final since I now set it on every
call to the connect() method in FtpsOperations.
BTW, I agree with you that the SFTPClient in commons-net is flawed. It
should provide a way to re-initialize itself so that a new connect()
could
be made. The FTPClient seems to work that way and it also provides a
disconnect() method. If they do not intend to support this, then they
should
at least state, as part of the documentation, that the SFTPClient
cannot be
reused across multiple connections. I've posted about this on their
mailing
list but hasn't got any reply yet. Meanwhile the above can be regarded
as a
(complicated...) work-around.
/Bengt
2010/6/18 Claus Ibsen claus.ib...@gmail.com
On Thu, Jun 17, 2010 at 11:56 PM, Bengt Rodehav be...@rodehav.com
wrote:
Claus,
Having looked a bit more at the commons-net code it's becoming clear
to
me
that you probably can't just reconnect an FTPSClient once it has
entered
secure communication mode. I can't find a way to re-initialise an
FTPSClient. I tried the disconnect() method (in the super class
FTPClient)
but it didn't get the FTPSClient out of secure communication mode.
To be safe I think we should
Re: Unconnected sockets not implemented exception in camel-ftp when using ftps
Claus,
Just tried and it works. Very simple way of achieving our goals I must say.
Two questions:
1. How does the consumer side work? I haven't tried it yet but wouldn't it
have the same problems?
2. Regarding the option you would introduce to control this behaviour, will
it default to no-caching for ftps? I guess it must, given the problems in
FTPSClient.
/Bengt
2010/6/21 Claus Ibsen claus.ib...@gmail.com
On Mon, Jun 21, 2010 at 9:11 AM, Bengt Rodehav be...@rodehav.com wrote:
OK
Bengt could you try changing camel-ftp in the RemoteFileProducer
public class RemoteFileProducerT extends GenericFileProducerT
implements ServicePoolAware {
And remove the implements ServicePoolAware which should cause Camel to
not pool it and thus you get a new fresh instance each time.
Then try testing with that to see if that fixes the re-connect issue.
What we can then do is to add some nice option in the endpoint URI so
you can configure the pooling behavior.
2010/6/21 Claus Ibsen claus.ib...@gmail.com
On Mon, Jun 21, 2010 at 8:52 AM, Bengt Rodehav be...@rodehav.com
wrote:
I have now created a JIRA in commons-net for this issue:
https://issues.apache.org/jira/browse/NET-327
Good
https://issues.apache.org/jira/browse/NET-327However, I still think
we
must fix this in camel-ftp by some kind of work-around (maybe similar
to
the
one I proposed in
https://issues.apache.org/activemq/browse/CAMEL-2829).
Have you had a chance to look at it Claus?
No sorry I am to busy with other issues but we got the ticket so we
will look into it before 2.4 is cut.
/Bengt
2010/6/18 Bengt Rodehav be...@rodehav.com
JIRA created:
https://issues.apache.org/activemq/browse/CAMEL-2829
https://issues.apache.org/activemq/browse/CAMEL-2829/Bengt
2010/6/18 Bengt Rodehav be...@rodehav.com
Claus,
I'm not sure what you mean by:
I think we should add an option on the endpoint to allow people to
turn this on/off.
Some would like to reuse existing connections to avoid the connect
-
upload - disconnect cycle when they upload many files etc.
IMO we would not disconnect more often than today. We would just
change
the connect() method in FtpsOperations so that it creates a new
instance of
FTPSClient prior to a connection attempt. I assume that since the
connect()
method is called in the first place, we are not currently connected
and
there is no way to reuse an existing connection. Am I right?
I have made some modifications in camel-ftp along these lines. I
will
create a JIRA ticket for this bug and attach my changes as diff
files
to the
issue. I just tested my changes and they do solve the problem I have
encountered but I haven't tested whether I have introduced any new
problems
or not.
Anyway, this is what I did:
*FtpsEndpoint*
I added the following members to keep track of the configuration of
the
FTPSClient:
private boolean isNeedClientAuth = false;
private KeyManager keyManager;
private TrustManager trustManager;
I modified the createFtpClient() method so that it doesn't actually
create
a FTPSClient but only calculates and stores the configuration in the
above
members. I also renamed it to createFtpsConfiguration() to reflect
that.
The createRemoteFileOperations() method was also changed
accordingly.
It
no longer interacts directly with an FTPSClient (since it is not
created
yet).
*FtpsOperations*
I added the private createFtpsClient() method that takes care of
creating
an FTPSClient from configuration stored in the FtpsEndpoint. The
createFtpsClient() is called in the connect() method just before the
call to
the real connect() method in the superclass (FtpOperations).
I changed the constructor so that it no longer takes a client as an
argument. I send null as client to the super class constructor. This
is
of
course a major change in behavior that you need to take a look at
it.
Neither FtpsOperations nor its super class FtpOperations can no
longer
assume that a client exists until the first connection attempt has
been
made.
*FtpOperations*
I had to make the client member non-final since I now set it on
every
call to the connect() method in FtpsOperations.
BTW, I agree with you that the SFTPClient in commons-net is flawed.
It
should provide a way to re-initialize itself so that a new connect()
could
be made. The FTPClient seems to work that way and it also provides a
disconnect() method. If they do not intend to support this, then
they
should
at least state, as part of the documentation, that the SFTPClient
cannot be
reused across multiple connections. I've posted about this on their
mailing
list but hasn't got any reply yet. Meanwhile the above can be
regarded
as a
(complicated...) work-around.
Re: Unconnected sockets not implemented exception in camel-ftp when using ftps
On Mon, Jun 21, 2010 at 10:22 AM, Bengt Rodehav be...@rodehav.com wrote:
Claus,
Just tried and it works. Very simple way of achieving our goals I must say.
Two questions:
It was just a quick test to see if that resolved it here and now as a
workaround.
1. How does the consumer side work? I haven't tried it yet but wouldn't it
have the same problems?
Yes there is only one instance of the consumer and its not pooled. So
it may have the issue of not being able to re-connect due Apache FTP
issue.
So we may have to implement a better re-connect logic in camel-ftp.
Maybe re-creating the FTPClient which works
2. Regarding the option you would introduce to control this behaviour, will
it default to no-caching for ftps? I guess it must, given the problems in
FTPSClient.
Its a bit confusing if some is pooled and others are not. But I do
also think its best that it just works out of the box. We should add a
WARN / INFO etc to the wiki page so its easy to spot. But maybe we
should fix the re-connect logic and then the producer could still be
pooled.
/Bengt
2010/6/21 Claus Ibsen claus.ib...@gmail.com
On Mon, Jun 21, 2010 at 9:11 AM, Bengt Rodehav be...@rodehav.com wrote:
OK
Bengt could you try changing camel-ftp in the RemoteFileProducer
public class RemoteFileProducerT extends GenericFileProducerT
implements ServicePoolAware {
And remove the implements ServicePoolAware which should cause Camel to
not pool it and thus you get a new fresh instance each time.
Then try testing with that to see if that fixes the re-connect issue.
What we can then do is to add some nice option in the endpoint URI so
you can configure the pooling behavior.
2010/6/21 Claus Ibsen claus.ib...@gmail.com
On Mon, Jun 21, 2010 at 8:52 AM, Bengt Rodehav be...@rodehav.com
wrote:
I have now created a JIRA in commons-net for this issue:
https://issues.apache.org/jira/browse/NET-327
Good
https://issues.apache.org/jira/browse/NET-327However, I still think
we
must fix this in camel-ftp by some kind of work-around (maybe similar
to
the
one I proposed in
https://issues.apache.org/activemq/browse/CAMEL-2829).
Have you had a chance to look at it Claus?
No sorry I am to busy with other issues but we got the ticket so we
will look into it before 2.4 is cut.
/Bengt
2010/6/18 Bengt Rodehav be...@rodehav.com
JIRA created:
https://issues.apache.org/activemq/browse/CAMEL-2829
https://issues.apache.org/activemq/browse/CAMEL-2829/Bengt
2010/6/18 Bengt Rodehav be...@rodehav.com
Claus,
I'm not sure what you mean by:
I think we should add an option on the endpoint to allow people to
turn this on/off.
Some would like to reuse existing connections to avoid the connect
-
upload - disconnect cycle when they upload many files etc.
IMO we would not disconnect more often than today. We would just
change
the connect() method in FtpsOperations so that it creates a new
instance of
FTPSClient prior to a connection attempt. I assume that since the
connect()
method is called in the first place, we are not currently connected
and
there is no way to reuse an existing connection. Am I right?
I have made some modifications in camel-ftp along these lines. I
will
create a JIRA ticket for this bug and attach my changes as diff
files
to the
issue. I just tested my changes and they do solve the problem I have
encountered but I haven't tested whether I have introduced any new
problems
or not.
Anyway, this is what I did:
*FtpsEndpoint*
I added the following members to keep track of the configuration of
the
FTPSClient:
private boolean isNeedClientAuth = false;
private KeyManager keyManager;
private TrustManager trustManager;
I modified the createFtpClient() method so that it doesn't actually
create
a FTPSClient but only calculates and stores the configuration in the
above
members. I also renamed it to createFtpsConfiguration() to reflect
that.
The createRemoteFileOperations() method was also changed
accordingly.
It
no longer interacts directly with an FTPSClient (since it is not
created
yet).
*FtpsOperations*
I added the private createFtpsClient() method that takes care of
creating
an FTPSClient from configuration stored in the FtpsEndpoint. The
createFtpsClient() is called in the connect() method just before the
call to
the real connect() method in the superclass (FtpOperations).
I changed the constructor so that it no longer takes a client as an
argument. I send null as client to the super class constructor. This
is
of
course a major change in behavior that you need to take a look at
it.
Neither FtpsOperations nor its super class FtpOperations can no
longer
assume that a client exists until the first connection attempt has
been
made.
*FtpOperations*
I had to
Re: camel 2.3.0 failed to download
Hi I just tried to download Camel 2.3 and it worked fine. I got this mirror page and clicked the first link http://www.apache.org/dyn/closer.cgi/camel/apache-camel/2.3.0/apache-camel-2.3.0.zip Which was a swedish site http://apache.dataphone.se/camel/apache-camel/2.3.0/apache-camel-2.3.0.zip So it may be a bad mirror list where in the area where you are living. Try again. Or try that swedish link above. On Fri, Jun 18, 2010 at 1:16 AM, saltnlight5 saltnlig...@gmail.com wrote: When I try any of the mirror link for download, it shows 404 Not Found error. Turns out the path seems to be wrong. It points to activemq instead of camel. Example link download pages displayed: http://apache.osuosl.org/activemq/apache-camel/2.3.0/apache-camel-2.3.0.tar.gz it should be: http://apache.osuosl.org/camel/apache-camel/2.3.0/apache-camel-2.3.0.tar.gz /Zemian -- View this message in context: http://camel.465427.n5.nabble.com/camel-2-3-0-failed-to-download-tp510022p510022.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: marshal to CSV with pipe delimiter
On Thu, Jun 17, 2010 at 11:23 AM, Christian Müller christian.muel...@gmail.com wrote: Hello Willem, thanks for the reply. I'm fine with this. I will not enhance this component, unless somebody smarter than me propose otherwise... :-) Yeah bindy is most likely nicer with object mapping. But sometimes you just need to old school to get a List of rows which has been separated. So I think it brings value to offer a option to configure the separator. So please go ahead Christian. Well i still think Andys problem should be possible with Camel. He configures the data format and Christian On Thu, Jun 17, 2010 at 6:46 AM, Willem Jiang willem.ji...@gmail.comwrote: Hi Christian, It should be easy to add the configure feature into CsvDataFromat. But after checking out the web site of the commons csv, it looks like the commons csv 1.0 is never released since 2008. Maybe we should consider to retire camel-csv and I don't think we need to enhance it as there are some alternatives solution in camel already. Willem Christian Müller wrote: Hello Claus, today I realized, that the org.apache.camel.model.dataformat.CsvDataFormat doesn't support any attributes or nested elements in the XML DSL. So, currently the last unit test I provided for camel-csv, is not possible for the XML DSL. Should we improve camel-csv for this? I'm not sure, because with camel-bindy and soon also with camel-smooks (I waiting for Tom Fennellys feedback) we offer two alternatives... Regards, Christian On Tue, Jun 15, 2010 at 10:48 PM, Christian Müller christian.muel...@gmail.com wrote: Hello Andy! I added a unit test for camel-csv which uses a pipe by marshaling the object. You will find the test [here| http://svn.apache.org/viewvc/camel/trunk/components/camel-csv/src/test/java/org/apache/camel/dataformat]./csv/CsvMarshalPipeDelimiterTest.java?view=markuphttp://svn.apache.org/viewvc/camel/trunk/components/camel-csv/src/test/java/org/apache/camel/dataformat%5D./csv/CsvMarshalPipeDelimiterTest.java?view=markup http://svn.apache.org/viewvc/camel/trunk/components/camel-csv/src/test/java/org/apache/camel/dataformat%5D./csv/CsvMarshalPipeDelimiterTest.java?view=markup I will also add an unit test for the XML DSL, but currently I have some problems with it. After that, I will review the wiki and may be I will update it. Hope this helps, Christian -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: Unconnected sockets not implemented exception in camel-ftp when using ftps
On Mon, Jun 21, 2010 at 10:36 AM, Claus Ibsen claus.ib...@gmail.com wrote:
On Mon, Jun 21, 2010 at 10:22 AM, Bengt Rodehav be...@rodehav.com wrote:
Claus,
Just tried and it works. Very simple way of achieving our goals I must say.
Two questions:
It was just a quick test to see if that resolved it here and now as a
workaround.
1. How does the consumer side work? I haven't tried it yet but wouldn't it
have the same problems?
Yes there is only one instance of the consumer and its not pooled. So
it may have the issue of not being able to re-connect due Apache FTP
issue.
So we may have to implement a better re-connect logic in camel-ftp.
Maybe re-creating the FTPClient which works
The only issue I can see with creating a new FTPClient is the fact
that the end user can configure the endpoint to use a specific custom
client he have chosen. So in that case Camel should not trash his
client and re-create a new default. This problem would be the same if
you do not pool the producer. As it would be the same instance of the
client being given on the next time the producer is created. Only
fixing the root problem in the FTPClient can fix this.
But this will fix both the consumer and producer issue. I recon this
is the best solution so far?
And we should try to avoid leaks etc. so I think we at first should
ask the client to disconnect itself, before we re-create the client.
2. Regarding the option you would introduce to control this behaviour, will
it default to no-caching for ftps? I guess it must, given the problems in
FTPSClient.
Its a bit confusing if some is pooled and others are not. But I do
also think its best that it just works out of the box. We should add a
WARN / INFO etc to the wiki page so its easy to spot. But maybe we
should fix the re-connect logic and then the producer could still be
pooled.
/Bengt
2010/6/21 Claus Ibsen claus.ib...@gmail.com
On Mon, Jun 21, 2010 at 9:11 AM, Bengt Rodehav be...@rodehav.com wrote:
OK
Bengt could you try changing camel-ftp in the RemoteFileProducer
public class RemoteFileProducerT extends GenericFileProducerT
implements ServicePoolAware {
And remove the implements ServicePoolAware which should cause Camel to
not pool it and thus you get a new fresh instance each time.
Then try testing with that to see if that fixes the re-connect issue.
What we can then do is to add some nice option in the endpoint URI so
you can configure the pooling behavior.
2010/6/21 Claus Ibsen claus.ib...@gmail.com
On Mon, Jun 21, 2010 at 8:52 AM, Bengt Rodehav be...@rodehav.com
wrote:
I have now created a JIRA in commons-net for this issue:
https://issues.apache.org/jira/browse/NET-327
Good
https://issues.apache.org/jira/browse/NET-327However, I still think
we
must fix this in camel-ftp by some kind of work-around (maybe similar
to
the
one I proposed in
https://issues.apache.org/activemq/browse/CAMEL-2829).
Have you had a chance to look at it Claus?
No sorry I am to busy with other issues but we got the ticket so we
will look into it before 2.4 is cut.
/Bengt
2010/6/18 Bengt Rodehav be...@rodehav.com
JIRA created:
https://issues.apache.org/activemq/browse/CAMEL-2829
https://issues.apache.org/activemq/browse/CAMEL-2829/Bengt
2010/6/18 Bengt Rodehav be...@rodehav.com
Claus,
I'm not sure what you mean by:
I think we should add an option on the endpoint to allow people to
turn this on/off.
Some would like to reuse existing connections to avoid the connect
-
upload - disconnect cycle when they upload many files etc.
IMO we would not disconnect more often than today. We would just
change
the connect() method in FtpsOperations so that it creates a new
instance of
FTPSClient prior to a connection attempt. I assume that since the
connect()
method is called in the first place, we are not currently connected
and
there is no way to reuse an existing connection. Am I right?
I have made some modifications in camel-ftp along these lines. I
will
create a JIRA ticket for this bug and attach my changes as diff
files
to the
issue. I just tested my changes and they do solve the problem I have
encountered but I haven't tested whether I have introduced any new
problems
or not.
Anyway, this is what I did:
*FtpsEndpoint*
I added the following members to keep track of the configuration of
the
FTPSClient:
private boolean isNeedClientAuth = false;
private KeyManager keyManager;
private TrustManager trustManager;
I modified the createFtpClient() method so that it doesn't actually
create
a FTPSClient but only calculates and stores the configuration in the
above
members. I also renamed it to createFtpsConfiguration() to reflect
that.
The createRemoteFileOperations() method was also changed
accordingly.
It
no longer interacts directly
Camel JMX - JSR 160
Hi, Can we access Mbean services of Camel using another JMX protocol than RMI like it is possible through Java JSR 160 (remote jmx) ? KR, Charles Moulliard Senior Enterprise Architect (J2EE, .NET, SOA) Apache Camel - ServiceMix Committer ~~~ Blog : http://cmoulliard.blogspot.com | Twitter : http://twitter.com/cmoulliard Linkedin : http://www.linkedin.com/in/charlesmoulliard | Skype: cmoulliard
Re: Problem with maintaining a JMS subscription after waking from sleep
Hi Willem, Thanks for that. Just to note that upgrading to Camel 2.3.0 did not change the outcome i.e. my application failed to re-connect to the topic upon waking up. I have now built and deployed a release using 5.3.2 AMQ artefacts so we'll see if that makes any difference (I shall know in about 12 hours!). Kind regards, Christopher -- View this message in context: http://camel.465427.n5.nabble.com/Problem-with-maintaining-a-JMS-subscription-after-waking-from-sleep-tp510193p510394.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-activemq unable to serialize Body after camel-exec usage
Hi, try to convert the body to something that implements serializable (e.g. String), after the log endpoint. It seems that the log endpoint converts the body to a ByteArrayInputStream, which is not serializable. Regards, Mitko From: Francois Lefoll francois.lef...@racinegroup.com To: users@camel.apache.org Date: 21.06.2010 15:47 Subject: camel-activemq unable to serialize Body after camel-exec usage Hi, I got a simple testcase: activemq-exec-activemq. as exec, I will only use /bin/more (ie: copy stdin into stdout...) this fails : camel:route camel:from uri=activemq:queue:queue1/ camel:to uri=exec:/bin/more/ camel:to uri=log:myLogger/ camel:to uri=activemq:queue:queue2/ /camel:route Jun 21, 2010 3:35:35 PM org.apache.camel.component.exec.ExecProducer process INFO: Executing ExecCommand [args=[], executable=/bin/more, timeout=9223372036854775807, outFile=null, workingDir=null, useStderrOnEmptyStdout=false] Jun 21, 2010 3:35:36 PM org.apache.camel.component.exec.ExecProducer process INFO: The command ExecCommand [args=[], executable=/bin/more, timeout=9223372036854775807, outFile=null, workingDir=null, useStderrOnEmptyStdout=false] had exit value 0 Jun 21, 2010 3:35:36 PM org.apache.camel.processor.Logger process INFO: Exchange[ExchangePattern:InOnly, BodyType:org.apache.camel.component.exec.ExecResult, Body:emptyMessage/] Jun 21, 2010 3:35:36 PM org.apache.camel.processor.Logger log SEVERE: Failed delivery for exchangeId: ID:user-laptop-44928-1277111283287-2:10:1:1:31. Exhausted after delivery attempt: 1 caught: java.lang.RuntimeException: java.io.ByteArrayInputStream java.lang.RuntimeException: java.io.ByteArrayInputStream at org.apache.activemq.command.ActiveMQObjectMessage.storeContent(ActiveMQObjectMessage.java:104) at org.apache.activemq.command.ActiveMQObjectMessage.setObject(ActiveMQObjectMessage.java:155) at org.apache.activemq.ActiveMQSession.createObjectMessage(ActiveMQSession.java:378) at org.apache.activemq.pool.PooledSession.createObjectMessage(PooledSession.java:153) ... Caused by: java.io.NotSerializableException: java.io.ByteArrayInputStream at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509) ... Did I miss something ? Thanks for your help, Regards, Francois -- View this message in context: http://camel.465427.n5.nabble.com/camel-activemq-unable-to-serialize-Body-after-camel-exec-usage-tp510418p510418.html Sent from the Camel - Users mailing list archive at Nabble.com. InterComponentWare AG: Vorstand: Peter Kirschbauer (Vors.), Jörg Stadler / Aufsichtsratsvors.: Prof. Dr. Christof Hettich Firmensitz: 69190 Walldorf, Altrottstraße 31 / AG Mannheim HRB 351761 / USt.-IdNr.: DE 198388516
Re: camel-activemq unable to serialize Body after camel-exec usage
Hi Mitko, Unfortunately, the error is not due to the log action, Same issue without the log, same issue reading (xml) result from an outFile... camel-activemq seems unable to read a Body passed by a camel-exec. I say seems, because, I get this error below jetty-6.1.9, but testing under tomcat-6.0.26, I don't get such error From my window, it really look to be a bug. Regards, Francois -- View this message in context: http://camel.465427.n5.nabble.com/camel-activemq-unable-to-serialize-Body-after-camel-exec-usage-tp510418p510428.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-activemq unable to serialize Body after camel-exec usage
Hi Francois, Did you try the following: camel:route camel:from uri=activemq:queue:queue1/ camel:to uri=exec:/bin/more/ camel:convertBodyTo type=java.lang.String/ camel:to uri=log:myLogger/ camel:to uri=activemq:queue:queue2/ /camel:route and / or camel:route camel:from uri=activemq:queue:queue1/ camel:to uri=exec:/bin/more/ camel:to uri=log:myLogger/ camel:convertBodyTo type=java.lang.String/ camel:to uri=activemq:queue:queue2/ /camel:route Regards, Mitko From: Francois Lefoll francois.lef...@racinegroup.com To: users@camel.apache.org Date: 21.06.2010 16:39 Subject: Re: camel-activemq unable to serialize Body after camel-exec usage Hi Mitko, Unfortunately, the error is not due to the log action, Same issue without the log, same issue reading (xml) result from an outFile... camel-activemq seems unable to read a Body passed by a camel-exec. I say seems, because, I get this error below jetty-6.1.9, but testing under tomcat-6.0.26, I don't get such error From my window, it really look to be a bug. Regards, Francois -- View this message in context: http://camel.465427.n5.nabble.com/camel-activemq-unable-to-serialize-Body-after-camel-exec-usage-tp510418p510428.html Sent from the Camel - Users mailing list archive at Nabble.com. InterComponentWare AG: Vorstand: Peter Kirschbauer (Vors.), Jörg Stadler / Aufsichtsratsvors.: Prof. Dr. Christof Hettich Firmensitz: 69190 Walldorf, Altrottstraße 31 / AG Mannheim HRB 351761 / USt.-IdNr.: DE 198388516
Re: camel netty batch
On Mon, Jun 21, 2010 at 3:58 PM, Charles Moulliard cmoulli...@gmail.com wrote: Hi, Is there a way to tell the camel-netty component to not creating a camel exchange for every message received from a TCP/IP connection but to group them in a batch of by example 1000 messages ? This could be very helpful especially when we have to process from a TCP server thousands of messages / second. No you cannot do this. You may be able to create a custom netty protocol and batch together in that protocol. I would assume this is the way to go. Then you can remember how many messages you got or wait for a special end of byte marker or whatever. Maybe others have better ideas? KR, Charles Moulliard Senior Enterprise Architect (J2EE, .NET, SOA) Apache Camel - ServiceMix Committer ~~~ Blog : http://cmoulliard.blogspot.com | Twitter : http://twitter.com/cmoulliard Linkedin : http://www.linkedin.com/in/charlesmoulliard | Skype: cmoulliard -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
error handling during failover
Hello,
I have a simple route using failover:
route
from
uri=cxf://http://localhost:8181/echoServer/echo?wsdlURL=/etc/bus-connector/echo.wsdlamp;serviceName={http://www.telecats.nl/nl.tc.rd.exp.echoService}EchoServiceamp;portName={http://www.telecats.nl/nl.tc.rd.exp.echoService}EchoServiceImplPortamp;dataFormat=MESSAGE;
/
loadBalance
failover
exceptionjava.lang.Throwable/exception
/failover
to
uri=cxf://http://localhost:8182/echoServer/echo?wsdlURL=file:/etc/bus-connector/echo.wsdlamp;serviceName={http://www.telecats.nl/nl.tc.rd.exp.echoService}EchoServiceamp;portName={http://www.telecats.nl/nl.tc.rd.exp.echoService}EchoServiceImplPortamp;dataFormat=MESSAGE;
/
to
uri=cxf://http://localhost:8183/echoServer/echo?wsdlURL=file:/etc/bus-connector/echo.wsdlamp;serviceName={http://www.telecats.nl/nl.tc.rd.exp.echoService}EchoServiceamp;portName={http://www.telecats.nl/nl.tc.rd.exp.echoService}EchoServiceImplPortamp;dataFormat=MESSAGE;
/
/loadBalance
/route
When failover kicks in because my first endpoint (TO) is down:
1 - I would like to receive an email when my system uses the failover
2 - I shouldn't be spammed everytime it fails over, just furst time would be
nice
3 - If also my second endpoints (at 8183) fails, I would like to send a
different message.
I have looked in to onException and doTry but some guidence would be verry
helpfull.
What is the way to go when I would like to implement this in my
camelContext.xml (spring) file ?
have fun,
Raymond Domingo
Telecats
--
View this message in context:
http://camel.465427.n5.nabble.com/error-handling-during-failover-tp510440p510440.html
Sent from the Camel - Users mailing list archive at Nabble.com.
CAMEL-CXF, PHP and the ?xml ...? header
Hello I have routes that use CAMEL-CXF. When I call these routes via SoapUI, JAX-WS, JAX-RPC or even Microsoft C# these work perfectly. BUT, when I try with PHP (whether NuSOAP or the new SoapClient), I have a PHP error like: Error:sendSms: SoapFault exception: [Client] looks like we got no XML document in [...] If I look at the HTTP response generated by CAMEL-CXF, its response looks like: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: multipart/related; type=application/xop+xml; boundary=uuid:7de96b4c-37f3-4835-9519-7adad8ce8114; start=root.mess...@cxf.apache.org; start-info=text/xml Content-Length: 1235 Date: Mon, 21 Jun 2010 15:32:15 GMT --uuid:7de96b4c-37f3-4835-9519-7adad8ce8114 Content-Type: application/xop+xml; charset=UTF-8; type=text/xml; Content-Transfer-Encoding: binary Content-ID: root.mess...@cxf.apache.org soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Body[...]/soap:Body/soap:Envelope --uuid:7de96b4c-37f3-4835-9519-7adad8ce8114-- As a result, the SOAP content doesn't start with: ?xml version=1.0 encoding=utf-8? ... and I think that's what making PHP fail. Any ideas on putting the XML header in front of the SOAP response? Cheers -- S. Ali Tokmen savas-ali.tok...@bull.net Office: +33 4 76 29 76 19 GSM:+33 66 43 00 555 Bull, Architect of an Open World TM http://www.bull.com
Spring route config involving custom components
Hi, I try to setup a Camel (version 2.3.0) route involving custom components using Spring. My Spring xml looks like this: camelContext id=camel xmlns=http://camel.apache.org/schema/spring; route from uri=direct://x/ to uri=foo://x/ /route /camelContext where foo is referring to a custom component which is auto-registered using the META-INF/services... approach. The custom component is rather simple and basically just extends DefaultComponent by creating the correct type of endpoint. When starting the context I get an exception [1] saying that the camelContext must be specified. With a default component (say, mock) things are working. What could I be missing? Thanks in advance for your help, and best regards, Bernd. [1] stack trace: org.apache.camel.RuntimeCamelException: org.apache.camel.FailedToCreateRouteException: Failed to create route route1 at: To[foo://x] in route: Route[[From[direct://x]] - [To[foo://x because of camelContext must be specified at org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException(ObjectHelper.java:) at org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:103) at org.apache.camel.spring.CamelContextFactoryBean.onApplicationEvent(CamelContextFactoryBean.java:665) at org.springframework.context.event.SimpleApplicationEventMulticaster$1.run(SimpleApplicationEventMulticaster.java:78) at org.springframework.core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:49) at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:76) at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:274) at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:736) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:383) at org.springframework.context.support.FileSystemXmlApplicationContext.init(FileSystemXmlApplicationContext.java:140) at org.springframework.context.support.FileSystemXmlApplicationContext.init(FileSystemXmlApplicationContext.java:84) at wisnetgrid.adapter.connectors.unicore.TestSpringConfig.test1(TestSpringConfig.java:28) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:599) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: org.apache.camel.FailedToCreateRouteException: Failed to create route route1 at: To[foo://x] in route: Route[[From[direct://x]] - [To[foo://x because of camelContext must be specified at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:720) at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:138) at org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:545) at org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:1209) at org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1107) at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1037) at org.apache.camel.spring.SpringCamelContext.doStart(SpringCamelContext.java:164) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:56) at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:912) at org.apache.camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java:203) at
Re: Problem with maintaining a JMS subscription after waking from sleep
OK, upgrading to AMQ 5.3.2 didn't help either. Help! -- View this message in context: http://camel.465427.n5.nabble.com/Problem-with-maintaining-a-JMS-subscription-after-waking-from-sleep-tp510193p510536.html Sent from the Camel - Users mailing list archive at Nabble.com.
