I use the "camel-ftp:2.17.2" component, which internally uses "jsch:0.1.53".
I need to change the default key exchange algorithm. I know from the JSCH documentation that this can be done through a properties file.
How can I achieve this using JSCH indirectly through Camel FTP? Does it support changing this configuration?
It's currently not possible out of the box with Apache Camel. I have created a Jira ticket to allow to specify this on the component in a future Camel release.
By default, the Jsch key exchange includes several algorithms which are sent to the server, which responds with the ones it supports. Then one of those is chosen.
The issue in the post mentioned by Martin Prikryl was that even though diffie-hellman-group-exchange-sha256 was chosen, the server closed the connection. The logfile shows that the jsch client sent a maximum keysize of 1024 bits "SSH_MSG_KEX_DH_GEX_REQUEST(1024<1024<1024)". Possibly the server required 2048?
According to the JSCH changelog, since version 0.1.53 the maximum keysize should be 2048 on Java8.
If the reason for wanting to explicitly set the key exchange algorithm is to force use of a less secure one such as "diffie-hellman-group1-sha1", it would be useful to understand the reason why the algorithm negotiated by default is not working.
Related
I've seen that Jetty now supports HTTP/2. Spent some time researching and can't see a way of implementing this in Apache Camel-Jetty. Any idea whether this is something that Camel will need to implement? Or is it configurable using their RestConfigurationDefinition?
Thanks in advance.
I'm afraid you need to do some extra work to enable the HTTP/2 feature. Camel-Jetty Components has two parts, one is Consumer (Jetty Server) and the other is Producer (Jetty Client). If you want to enable the HTTP/2 feature, you need to make sure the Http module is loaded by modifying some code. I don't think you can do it by doing some configuration with the RestConfigurationDefinition.
Please send a feature request by creating a JIRA for it.
We are trying to preserve TimeToLive/JMSExpiration in our messages during moving them from AMQ queue to IBM MQ Series queue, currently we use: jmsBridgeConnectors in AMQ to move the messages but the expiration is not preserved.
I know that AMQ suggests to rather use Camel instead of jmsBridgeConnectors to bridge AMQ to external messaging systems, but I have no experience with Camel.
Did anyone face similar issue and have some working solution, either with jmsBridgeConnectors or Camel?
Many thanks in advance
Best Regards
Lukasz
If you use Camel and its JMS component, then you can turn on preserveMessageQos which will then transfer the expiration detail. See more details in the Camel documentation (see the table of the option): http://camel.apache.org/jms
In terms of the JMS bridge, I assume you refer to the AMQ JMS bridge? http://activemq.apache.org/jms-to-jms-bridge.html - I am not sure if you can configure to keep the expiration or not. Others here at SO may know, or you can dive into the source code, or try to ask on the ActiveMQ user mailing list.
Does Camel routing work with Kafka?
My use case requires that routes/workflows be assembled at runtime, because they are highly dependent on message context, and not fully known at configuration time. I am thinking about using Camel's Routing Slip pattern which seems to rely on message header (aRoutingSlipHeader) to carry the pipeline end-points. Kafka does not support JMS format and has very limited support for headers. Is the RoutingSlip-based route still going to work when combined with Kafka?
Thanks in advance for any wisdom!
I've got client server application, with JBossAS7 and client which uses remote EJB provided by the server. I have to pass file from client to server, where it will be further processed via InputStream. Also have to pass file from server to client, where on server i get OutputStream. File size is not limited, it might be even 5GB. What can I do to implement solution to this case? Passing byte[] array seems not to be a good solution, RMI limits size what I've read. RMIIO is GPL (i need solution free for commercial use). Is http transfer the only reasonable way to do this?
edit: it seems that RMIIO was always LGPL!
You might consider setting up a Netty Server running on JBoss AS as showed in this Netty Tutorial and pass data using bare sockets.
Another option is HTTP by means of a simple HTTP Transfer using a Servlet for example.
I'd exclude EJB since they are transactional component, and admitted you managed to pass this data through RMI-IIOP, you still have to set up a huge Transactional timeout.
Hope it helps.
RMIIO is LGPL (different from just GPL), which is free for commercial use and is not viral (assuming you have not modified the rmiio library).
I am creating a POC when I have a server that takes requests from clients. Then puts those requests in a pool which another thread pool processes those request and put them back into an output pool. The server should take a response from the pool and send it back to the original requester. I know how to code this with using netty but I would really like to use netty for this POC. I've got through the examples but have not found anything similar.
Is this possible using netty?
Thanks
I'm not 100% sure but I think you are looking for the ExecutionHandler. You can use the ExecutionHandler to build some SEDA like architecture. In current master branch (upcomming 4.0) we are currently working on making it even more flexible by allowing to use different ExecutionHandlers for different kind of events.