[jira] [Created] (CAMEL-8084) PGP Data Format: file name parameter
Franz Forsthofer created CAMEL-8084: --- Summary: PGP Data Format: file name parameter Key: CAMEL-8084 URL: https://issues.apache.org/jira/browse/CAMEL-8084 Project: Camel Issue Type: Improvement Components: camel-crypto Reporter: Franz Forsthofer Fix For: 2.15.0 Currently, the PGP Data Format marshaler sets the file name of the PGP Literal Packet to _CONSOLE by default; and you can overwrite the file name via the header CamelFileName. The attached patch introduces the parameter fileName so that you can set the file name during configuration time. The default value is still _CONSOLE. Now it is also possible to use an empty string as file name, which was not possible before. We should allow an empty string value because the Open PGP specification (https://tools.ietf.org/html/rfc4880) explicitly mentions that the file name may be a zero-length string (see chapter 5.9. Literal Data Packet (Tag 11). The spec says about the _CONSOLE value: _CONSOLE is used to indicate that the message is considered to be 'for your eyes only'. This advises that the message data is unusually sensitive, and the receiving program should process it more carefully, perhaps avoiding storing the received data to disk, for example. There are some PGP programs available which will break of the processing of PGP messages which contain the value _CONSOLE as file name. In order to avoid such kind of break-ofs, it makes sense to allow the configuration of the file name via a parameter so that you must not use a header. Regards Franz -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8084) PGP Data Format: file name parameter
[ https://issues.apache.org/jira/browse/CAMEL-8084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-8084: Attachment: 0001-pgp-file-name-for-Literal-Packet.patch PGP Data Format: file name parameter Key: CAMEL-8084 URL: https://issues.apache.org/jira/browse/CAMEL-8084 Project: Camel Issue Type: Improvement Components: camel-crypto Reporter: Franz Forsthofer Fix For: 2.15.0 Attachments: 0001-pgp-file-name-for-Literal-Packet.patch Currently, the PGP Data Format marshaler sets the file name of the PGP Literal Packet to _CONSOLE by default; and you can overwrite the file name via the header CamelFileName. The attached patch introduces the parameter fileName so that you can set the file name during configuration time. The default value is still _CONSOLE. Now it is also possible to use an empty string as file name, which was not possible before. We should allow an empty string value because the Open PGP specification (https://tools.ietf.org/html/rfc4880) explicitly mentions that the file name may be a zero-length string (see chapter 5.9. Literal Data Packet (Tag 11). The spec says about the _CONSOLE value: _CONSOLE is used to indicate that the message is considered to be 'for your eyes only'. This advises that the message data is unusually sensitive, and the receiving program should process it more carefully, perhaps avoiding storing the received data to disk, for example. There are some PGP programs available which will break of the processing of PGP messages which contain the value _CONSOLE as file name. In order to avoid such kind of break-ofs, it makes sense to allow the configuration of the file name via a parameter so that you must not use a header. Regards Franz -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7997) New modules: camel-scr, camel-archetype-scr
[ https://issues.apache.org/jira/browse/CAMEL-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227632#comment-14227632 ] Jyrki Ruuskanen commented on CAMEL-7997: Initial version of the user guide published at https://camel.apache.org/camel-and-scr.html. New modules: camel-scr, camel-archetype-scr --- Key: CAMEL-7997 URL: https://issues.apache.org/jira/browse/CAMEL-7997 Project: Camel Issue Type: New Feature Components: camel-scr Reporter: Jyrki Ruuskanen Fix For: 2.15.0 Support module and archetype for running Camel in Service Component Runtime (OSGi Declarative Services) bundles. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8085) Add handling of offset in case of auto commit is disabled to prevent data loss
[ https://issues.apache.org/jira/browse/CAMEL-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Vasyliev updated CAMEL-8085: - Priority: Critical (was: Major) Add handling of offset in case of auto commit is disabled to prevent data loss -- Key: CAMEL-8085 URL: https://issues.apache.org/jira/browse/CAMEL-8085 Project: Camel Issue Type: Improvement Components: camel-kafka Affects Versions: 2.14.0 Reporter: Ivan Vasyliev Priority: Critical Fix For: 2.15.0 In order to prevent data loss kafka client allows to manually handle consumer offset. According to this lady: http://ingest.tips/2014/10/12/kafka-high-level-consumer-frequently-missing-pieces/ Kafka consumer commitOffset is committing offset for each consumer and for all streams of this consumer. I've made changes in camel-kafka in order to support handling of offset in case of auto-commit option is disabled. Will provide pull request and update description -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8085) Add handling of offset in case of auto commit is disabled to prevent data loss
[ https://issues.apache.org/jira/browse/CAMEL-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227670#comment-14227670 ] ASF GitHub Bot commented on CAMEL-8085: --- GitHub user vasilievip opened a pull request: https://github.com/apache/camel/pull/342 https://issues.apache.org/jira/browse/CAMEL-8085 - add handling of offset if auto commit of offset is disabled - add embedded kafka into unit tests You can merge this pull request into a Git repository by running: $ git pull https://github.com/vasilievip/camel CAMEL-8085 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/342.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #342 commit b8d5b31688c0aed3b5101f2c45557afe518d18be Author: Ivan Vasylyev ivasyl...@playtika.com.ua Date: 2014-11-27T13:44:09Z https://issues.apache.org/jira/browse/CAMEL-8085 - add handling of offset if auto commit of offset is disabled - add embedded kafka into unit tests Add handling of offset in case of auto commit is disabled to prevent data loss -- Key: CAMEL-8085 URL: https://issues.apache.org/jira/browse/CAMEL-8085 Project: Camel Issue Type: Improvement Components: camel-kafka Affects Versions: 2.14.0 Reporter: Ivan Vasyliev Priority: Critical Fix For: 2.15.0 In order to prevent data loss kafka client allows to manually handle consumer offset. According to this lady: http://ingest.tips/2014/10/12/kafka-high-level-consumer-frequently-missing-pieces/ Kafka consumer commitOffset is committing offset for each consumer and for all streams of this consumer. I've made changes in camel-kafka in order to support handling of offset in case of auto-commit option is disabled. Will provide pull request and update description -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8085) Add handling of offset in case of auto commit is disabled to prevent data loss
[ https://issues.apache.org/jira/browse/CAMEL-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Vasyliev updated CAMEL-8085: - Description: In order to prevent data loss kafka client allows to manually handle consumer offset. According to this lady: http://ingest.tips/2014/10/12/kafka-high-level-consumer-frequently-missing-pieces/ Kafka consumer commitOffset is committing offset for each consumer and for all streams of this consumer. I've made changes in camel-kafka in order to support handling of offset in case of auto-commit option is disabled. https://github.com/apache/camel/pull/342 was: In order to prevent data loss kafka client allows to manually handle consumer offset. According to this lady: http://ingest.tips/2014/10/12/kafka-high-level-consumer-frequently-missing-pieces/ Kafka consumer commitOffset is committing offset for each consumer and for all streams of this consumer. I've made changes in camel-kafka in order to support handling of offset in case of auto-commit option is disabled. Will provide pull request and update description Add handling of offset in case of auto commit is disabled to prevent data loss -- Key: CAMEL-8085 URL: https://issues.apache.org/jira/browse/CAMEL-8085 Project: Camel Issue Type: Improvement Components: camel-kafka Affects Versions: 2.14.0 Reporter: Ivan Vasyliev Priority: Critical Fix For: 2.15.0 In order to prevent data loss kafka client allows to manually handle consumer offset. According to this lady: http://ingest.tips/2014/10/12/kafka-high-level-consumer-frequently-missing-pieces/ Kafka consumer commitOffset is committing offset for each consumer and for all streams of this consumer. I've made changes in camel-kafka in order to support handling of offset in case of auto-commit option is disabled. https://github.com/apache/camel/pull/342 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8086) Possible memoryleak when convertBodyTo is used in a dynamicRouter
Bjørn Hilstad created CAMEL-8086: Summary: Possible memoryleak when convertBodyTo is used in a dynamicRouter Key: CAMEL-8086 URL: https://issues.apache.org/jira/browse/CAMEL-8086 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.13.2 Reporter: Bjørn Hilstad Priority: Minor We have implemented a while loop using a dynamicRouter. The dynamicRouter looks like this: dynamicRouter headersomeheadername/header /dynamicRouter where someheadername refers to another route using direct:routename The route that handles direct:routename looks like this: bean ref=someref/ convertBodyTo type=java.lang.String/ The someref-bean just puts some data in the body and header and would also be responsible to set the value of someheadername=null to exit the dynamicRouter. During execution of these routes we see that heapusage increases until OOM if the dynamicRouter does not exit before OOM. The number of instances of DefaultMessage also keeps increasing. If we remove the convertBodyTo from the route we do not get OOM and the number of instances of DefaultMessage is stable and low. The same also happens if we replace convertBodyTo with a transform. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8087) missing dependency for camel-example-restlet-jdbc example
Sandy Meier created CAMEL-8087:
--
Summary: missing dependency for camel-example-restlet-jdbc
example
Key: CAMEL-8087
URL: https://issues.apache.org/jira/browse/CAMEL-8087
Project: Camel
Issue Type: Bug
Components: examples
Affects Versions: 2.14.0
Environment: xubuntu 12.04, maven 3.0.3
Reporter: Sandy Meier
Priority: Minor
after mvn clean install mvn jetty:run following exception appears and REST
services doesn't work.
{code}
on completed in 2405 ms
2014-11-27 17:24:03.534:WARN:oejs.Holder:
java.lang.ClassNotFoundException: org.restlet.ext.spring.SpringServerServlet
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
at
org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:430)
at
org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:383)
at org.eclipse.jetty.util.Loader.loadClass(Loader.java:100)
at org.eclipse.jetty.util.Loader.loadClass(Loader.java:79)
at org.eclipse.jetty.servlet.Holder.doStart(Holder.java:107)
at
org.eclipse.jetty.servlet.ServletHolder.doStart(ServletHolder.java:298)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:791)
at
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265)
at
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1242)
at
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:717)
at
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
at
org.mortbay.jetty.plugin.JettyWebAppContext.doStart(JettyWebAppContext.java:298)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:229)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:172)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:229)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
at org.eclipse.jetty.server.Server.doStart(Server.java:282)
at org.mortbay.jetty.plugin.JettyServer.doStart(JettyServer.java:65)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:520)
at
org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:365)
at org.mortbay.jetty.plugin.JettyRunMojo.execute(JettyRunMojo.java:523)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
[jira] [Created] (CAMEL-8088) FTP can wait indefinitely when connection timeout occurs during connect
Bob Browning created CAMEL-8088:
---
Summary: FTP can wait indefinitely when connection timeout occurs
during connect
Key: CAMEL-8088
URL: https://issues.apache.org/jira/browse/CAMEL-8088
Project: Camel
Issue Type: Bug
Components: camel-ftp
Affects Versions: 2.13.3
Reporter: Bob Browning
Priority: Minor
In our production system we have seen cases where the FTP thread is waiting for
a response indefinitely despite having set _soTimeout_ on the connection. On
investigation this is due to a condition that can occur where a socket is able
to connect yet a firewall or the ilk then blocks further traffic.
This can be over come by setting the property _ftpClient.defaultTimeout_ to a
non-zero value.
It should be the case where if upon initial socket connection no response
occurs that the socket should be deemed dead, however this is not the case.
When the following exception is thrown during initial connect to an FTP server,
after the socket has connected but whilst awaiting the inital reply it can
leave the RemoteFileProducer in a state where it is connected but not logged in
and no attempt reconnect is attempted, if the soTimeout as set by
_ftpClient.defaultTimeout_ is set to zero then it can cause a subsequent
command will wait for a reply indefinitely.
{pre}
Caused by: java.io.IOException: Timed out waiting for initial connect reply
at org.apache.commons.net.ftp.FTP._connectAction_(FTP.java:389)
~[commons-net-3.1.jar:3.1]
at
org.apache.commons.net.ftp.FTPClient._connectAction_(FTPClient.java:796)
~[commons-net-3.1.jar:3.1]
at org.apache.commons.net.SocketClient.connect(SocketClient.java:172)
~[commons-net-3.1.jar:3.1]
at org.apache.commons.net.SocketClient.connect(SocketClient.java:192)
~[commons-net-3.1.jar:3.1]
at
org.apache.camel.component.file.remote.FtpOperations.connect(FtpOperations.java:95)
~[camel-ftp-2.13.1.jar:2.13.1]
{pre}
The RemoteFileProducer will enter this block as the loggedIn state has not yet
been reached, however the existing broken socket is reused.
{code}
// recover by re-creating operations which should most likely be able
to recover
if (!loggedIn) {
log.debug(Trying to recover connection to: {} with a fresh
client., getEndpoint());
setOperations(getEndpoint().createRemoteFileOperations());
connectIfNecessary();
}
{code}
Yet the _connectIfNecessary()_ method will return immediately since the check
condition is based on socket connection and takes no account of whether login
was achieved so the 'dead' socket is reused.
{code}
protected void connectIfNecessary() throws
GenericFileOperationFailedException {
// This will be skipped when loggedIn = false and the socket is
connected
if (!getOperations().isConnected()) {
log.debug(Not already connected/logged in. Connecting to: {},
getEndpoint());
RemoteFileConfiguration config = getEndpoint().getConfiguration();
loggedIn = getOperations().connect(config);
if (!loggedIn) {
return;
}
log.info(Connected and logged in to: + getEndpoint());
}
}
{code}
A dirty test that blocks of this blocking condition:
{code}
package ftp;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.impl.JndiRegistry;
import org.apache.camel.test.junit4.CamelTestSupport;
import org.apache.commons.net.ftp.FTPClient;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.mockftpserver.fake.FakeFtpServer;
import org.mockito.Mockito;
import org.mockito.invocation.InvocationOnMock;
import org.mockito.stubbing.Answer;
import java.io.IOException;
import java.io.InputStream;
import java.net.Socket;
import java.net.SocketException;
import java.net.SocketTimeoutException;
import java.util.concurrent.atomic.AtomicBoolean;
import javax.net.SocketFactory;
import static org.mockito.Matchers.anyInt;
import static org.mockito.Mockito.doAnswer;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;
public class FtpInitialConnectTimeoutTest extends CamelTestSupport {
private static final int CONNECT_TIMEOUT = 11223;
/**
* Create the answer for the socket factory that causes a
SocketTimeoutException to occur in connect.
*/
private static class SocketAnswer implements AnswerSocket {
@Override
public Socket answer(InvocationOnMock invocation) throws Throwable {
final Socket socket = Mockito.spy(new Socket());
final AtomicBoolean timeout = new AtomicBoolean();
try {
doAnswer(new AnswerInputStream() {
@Override
public InputStream answer(InvocationOnMock invocation) throws
Throwable {
final InputStream stream = (InputStream)
[jira] [Updated] (CAMEL-8088) FTP can wait indefinitely when connection timeout occurs during connect
[
https://issues.apache.org/jira/browse/CAMEL-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bob Browning updated CAMEL-8088:
Description:
In our production system we have seen cases where the FTP thread is waiting for
a response indefinitely despite having set _soTimeout_ on the connection. On
investigation this is due to a condition that can occur where a socket is able
to connect yet a firewall or the ilk then blocks further traffic.
This can be over come by setting the property _ftpClient.defaultTimeout_ to a
non-zero value.
It should be the case where if upon initial socket connection no response
occurs that the socket should be deemed dead, however this is not the case.
When the following exception is thrown during initial connect to an FTP server,
after the socket has connected but whilst awaiting the inital reply it can
leave the RemoteFileProducer in a state where it is connected but not logged in
and no attempt reconnect is attempted, if the soTimeout as set by
_ftpClient.defaultTimeout_ is set to zero then it can cause a subsequent
command will wait for a reply indefinitely.
{noformat}
Caused by: java.io.IOException: Timed out waiting for initial connect reply
at org.apache.commons.net.ftp.FTP._connectAction_(FTP.java:389)
~[commons-net-3.1.jar:3.1]
at
org.apache.commons.net.ftp.FTPClient._connectAction_(FTPClient.java:796)
~[commons-net-3.1.jar:3.1]
at org.apache.commons.net.SocketClient.connect(SocketClient.java:172)
~[commons-net-3.1.jar:3.1]
at org.apache.commons.net.SocketClient.connect(SocketClient.java:192)
~[commons-net-3.1.jar:3.1]
at
org.apache.camel.component.file.remote.FtpOperations.connect(FtpOperations.java:95)
~[camel-ftp-2.13.1.jar:2.13.1]
{noformat}
The RemoteFileProducer will enter this block as the loggedIn state has not yet
been reached, however the existing broken socket is reused.
{code}
// recover by re-creating operations which should most likely be able
to recover
if (!loggedIn) {
log.debug(Trying to recover connection to: {} with a fresh
client., getEndpoint());
setOperations(getEndpoint().createRemoteFileOperations());
connectIfNecessary();
}
{code}
Yet the _connectIfNecessary()_ method will return immediately since the check
condition is based on socket connection and takes no account of whether login
was achieved so the 'dead' socket is reused.
{code}
protected void connectIfNecessary() throws
GenericFileOperationFailedException {
// This will be skipped when loggedIn = false and the socket is
connected
if (!getOperations().isConnected()) {
log.debug(Not already connected/logged in. Connecting to: {},
getEndpoint());
RemoteFileConfiguration config = getEndpoint().getConfiguration();
loggedIn = getOperations().connect(config);
if (!loggedIn) {
return;
}
log.info(Connected and logged in to: + getEndpoint());
}
}
{code}
A dirty test that blocks of this blocking condition:
{code}
package ftp;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.impl.JndiRegistry;
import org.apache.camel.test.junit4.CamelTestSupport;
import org.apache.commons.net.ftp.FTPClient;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.mockftpserver.fake.FakeFtpServer;
import org.mockito.Mockito;
import org.mockito.invocation.InvocationOnMock;
import org.mockito.stubbing.Answer;
import java.io.IOException;
import java.io.InputStream;
import java.net.Socket;
import java.net.SocketException;
import java.net.SocketTimeoutException;
import java.util.concurrent.atomic.AtomicBoolean;
import javax.net.SocketFactory;
import static org.mockito.Matchers.anyInt;
import static org.mockito.Mockito.doAnswer;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;
public class FtpInitialConnectTimeoutTest extends CamelTestSupport {
private static final int CONNECT_TIMEOUT = 11223;
/**
* Create the answer for the socket factory that causes a
SocketTimeoutException to occur in connect.
*/
private static class SocketAnswer implements AnswerSocket {
@Override
public Socket answer(InvocationOnMock invocation) throws Throwable {
final Socket socket = Mockito.spy(new Socket());
final AtomicBoolean timeout = new AtomicBoolean();
try {
doAnswer(new AnswerInputStream() {
@Override
public InputStream answer(InvocationOnMock invocation) throws
Throwable {
final InputStream stream = (InputStream)
invocation.callRealMethod();
InputStream inputStream = new InputStream() {
@Override
public int read() throws IOException {
if (timeout.get()) {
// emulate a timeout
[jira] [Created] (CAMEL-8089) Support paging and restricting results from google drive
Jonathan Anstey created CAMEL-8089: -- Summary: Support paging and restricting results from google drive Key: CAMEL-8089 URL: https://issues.apache.org/jira/browse/CAMEL-8089 Project: Camel Issue Type: Improvement Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.14.1, 2.15.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8089) Support paging and restricting results from google drive
[ https://issues.apache.org/jira/browse/CAMEL-8089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-8089. Resolution: Fixed http://git-wip-us.apache.org/repos/asf/camel/commit/94898489 Support paging and restricting results from google drive Key: CAMEL-8089 URL: https://issues.apache.org/jira/browse/CAMEL-8089 Project: Camel Issue Type: Improvement Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.14.1, 2.15.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7997) New modules: camel-scr, camel-archetype-scr
[ https://issues.apache.org/jira/browse/CAMEL-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227885#comment-14227885 ] ASF GitHub Bot commented on CAMEL-7997: --- GitHub user yuruki opened a pull request: https://github.com/apache/camel/pull/343 CAMEL-7997 Working on camel-scr Working on camel-scr and camel-archetype-scr. You can merge this pull request into a Git repository by running: $ git pull https://github.com/yuruki/camel camel-scr-work Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/343.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #343 commit 7c52e7e2fccd3d3da172448ef1d0813a2a6b8612 Author: Jyrki Ruuskanen yur...@kotikone.fi Date: 2014-11-27T18:30:13Z Align code with the wiki New modules: camel-scr, camel-archetype-scr --- Key: CAMEL-7997 URL: https://issues.apache.org/jira/browse/CAMEL-7997 Project: Camel Issue Type: New Feature Components: camel-scr Reporter: Jyrki Ruuskanen Fix For: 2.15.0 Support module and archetype for running Camel in Service Component Runtime (OSGi Declarative Services) bundles. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8086) Possible memoryleak when convertBodyTo is used in a dynamicRouter
[ https://issues.apache.org/jira/browse/CAMEL-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227951#comment-14227951 ] Bjørn Hilstad commented on CAMEL-8086: -- I'm not quite sure that we could use a recipient list in this case. What we are trying to do is to make a while-loop, where we in the bean get one message from an external service and process that. If there are no more messages the bean will return null to exit from the dynamic router. Possible memoryleak when convertBodyTo is used in a dynamicRouter - Key: CAMEL-8086 URL: https://issues.apache.org/jira/browse/CAMEL-8086 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.13.2 Reporter: Bjørn Hilstad Priority: Minor We have implemented a while loop using a dynamicRouter. The dynamicRouter looks like this: dynamicRouter headersomeheadername/header /dynamicRouter where someheadername refers to another route using direct:routename The route that handles direct:routename looks like this: bean ref=someref/ convertBodyTo type=java.lang.String/ The someref-bean just puts some data in the body and header and would also be responsible to set the value of someheadername=null to exit the dynamicRouter. During execution of these routes we see that heapusage increases until OOM if the dynamicRouter does not exit before OOM. The number of instances of DefaultMessage also keeps increasing. If we remove the convertBodyTo from the route we do not get OOM and the number of instances of DefaultMessage is stable and low. The same also happens if we replace convertBodyTo with a transform. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8086) Possible memoryleak when convertBodyTo is used in a dynamicRouter
[ https://issues.apache.org/jira/browse/CAMEL-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14227956#comment-14227956 ] Claus Ibsen commented on CAMEL-8086: You are doing it wrong as the expression in the dynamic router is a header, not a method call expression. Please use the mailing list for help this is not a Camel bug Possible memoryleak when convertBodyTo is used in a dynamicRouter - Key: CAMEL-8086 URL: https://issues.apache.org/jira/browse/CAMEL-8086 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.13.2 Reporter: Bjørn Hilstad Priority: Minor We have implemented a while loop using a dynamicRouter. The dynamicRouter looks like this: dynamicRouter headersomeheadername/header /dynamicRouter where someheadername refers to another route using direct:routename The route that handles direct:routename looks like this: bean ref=someref/ convertBodyTo type=java.lang.String/ The someref-bean just puts some data in the body and header and would also be responsible to set the value of someheadername=null to exit the dynamicRouter. During execution of these routes we see that heapusage increases until OOM if the dynamicRouter does not exit before OOM. The number of instances of DefaultMessage also keeps increasing. If we remove the convertBodyTo from the route we do not get OOM and the number of instances of DefaultMessage is stable and low. The same also happens if we replace convertBodyTo with a transform. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8086) Possible memoryleak when convertBodyTo is used in a dynamicRouter
[ https://issues.apache.org/jira/browse/CAMEL-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8086. Resolution: Not a Problem Possible memoryleak when convertBodyTo is used in a dynamicRouter - Key: CAMEL-8086 URL: https://issues.apache.org/jira/browse/CAMEL-8086 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.13.2 Reporter: Bjørn Hilstad Priority: Minor We have implemented a while loop using a dynamicRouter. The dynamicRouter looks like this: dynamicRouter headersomeheadername/header /dynamicRouter where someheadername refers to another route using direct:routename The route that handles direct:routename looks like this: bean ref=someref/ convertBodyTo type=java.lang.String/ The someref-bean just puts some data in the body and header and would also be responsible to set the value of someheadername=null to exit the dynamicRouter. During execution of these routes we see that heapusage increases until OOM if the dynamicRouter does not exit before OOM. The number of instances of DefaultMessage also keeps increasing. If we remove the convertBodyTo from the route we do not get OOM and the number of instances of DefaultMessage is stable and low. The same also happens if we replace convertBodyTo with a transform. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8090) Camel-chunk component
Andrea Cosentino created CAMEL-8090: --- Summary: Camel-chunk component Key: CAMEL-8090 URL: https://issues.apache.org/jira/browse/CAMEL-8090 Project: Camel Issue Type: New Feature Affects Versions: 2.15.0 Reporter: Andrea Cosentino Priority: Minor Hi all, I'm currently working on this new Camel component: https://github.com/oscerd/camel-chunk This component allows for processing a message using a Chunk template. Chunk is a templating Java library released under Apache License 2.0. You can find more information here: http://www.x5software.com/chunk/examples/ChunkExample Looking at the results of some tests Chunk seems to be very fast and I think it might be another solution to be added to existing components (Mustache, Velocity, FreeMarker etc.). I'd like to have some feedbacks from the developers community and from the Committers before submitting a pull request on the Camel master branch. Thanks in advance and let me know your opinion. If you think is ready to be integrated, I'll do a PR in the next days. Bye, Andrea -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8090) Camel-chunk component
[ https://issues.apache.org/jira/browse/CAMEL-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino updated CAMEL-8090: Labels: components (was: ) Camel-chunk component - Key: CAMEL-8090 URL: https://issues.apache.org/jira/browse/CAMEL-8090 Project: Camel Issue Type: New Feature Affects Versions: 2.15.0 Reporter: Andrea Cosentino Priority: Minor Labels: components Hi all, I'm currently working on this new Camel component: https://github.com/oscerd/camel-chunk This component allows for processing a message using a Chunk template. Chunk is a templating Java library released under Apache License 2.0. You can find more information here: http://www.x5software.com/chunk/examples/ChunkExample Looking at the results of some tests Chunk seems to be very fast and I think it might be another solution to be added to existing components (Mustache, Velocity, FreeMarker etc.). I'd like to have some feedbacks from the developers community and from the Committers before submitting a pull request on the Camel master branch. Thanks in advance and let me know your opinion. If you think is ready to be integrated, I'll do a PR in the next days. Bye, Andrea -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7905) New option to ignore missing consumers on direct endpoints
[
https://issues.apache.org/jira/browse/CAMEL-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14228079#comment-14228079
]
Ben O'Day commented on CAMEL-7905:
--
[~dpr] - would should happen to the message that was sent...just throw it away?
a seda producer can create a blocking queue on demand to hold the message
until a consumer comes along. this doesn't work for direct however given the
need to make a synchronous call...hence the block option, etc.
New option to ignore missing consumers on direct endpoints
--
Key: CAMEL-7905
URL: https://issues.apache.org/jira/browse/CAMEL-7905
Project: Camel
Issue Type: Improvement
Affects Versions: 2.14.0
Reporter: Daniel
Currently a {{DirectConsumerNotAvailableException}} or
{{DirectVmConsumerNotAvailableException}} is thrown when a message is send
via a direct endoint and no consumer has been set up for this endpoint.
In a current scenario I want to use camel to loosely couple two components
using direct endpoints that _might_ be consumed by some bean. Especially
there should be no dependency from the producing component to the consuming
component. However, if there is a consumer, messages send from the producer
must be consumed synchronously in the same thread to preserve the transaction
context of the producer. That why I chose {{direct}} for the producer's
endpoint.
What is meant by the messages might be consumed is that the consuming
component might not be deployed, when the consumer produces the first
messages, or perhaps will never be deployed. I know there is the {{block}}
option for the {{direct}} component but I don't want the producer to wait for
the consumer as it might take some time (possibly forever) for the consumer
to be available.
I think this is a very common scenario for a messaging system and I was
surprised not to find an easy out-of-the-box way to handle this with camel.
That's why I think an additional option {{failIfNoConsumers}} (similar to the
option for the seda component) for the {{direct}} and {{direct-vm}} component
would be very handy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
