Search:

I suggest you open up a Spring Framework JIRA 'Documentation' Issue suggesting additions to the JavaDoc and/or a warning in the reference documentation and/or emit a WARN log if a caching connection...

Bingo!

Yes, of course; the consumer is cached and the broker doesn't know there's not actually someone really receive()ing from it, so he sends a message to it and nobody's home.

Duh -...

Let's take a step back - what makes you think that messages are not being committed?

Like we have discussed, the commit is done much further up the stack.

If you turn on debug logging you...

ftp inbound channel adapter -> header enricher -> resequencer -> custom splitter.

The header enricher should populate correlationId, sequenceNumber and sequenceSize headers based on the file name....

By default, the consumer will be cached (and reused by a future thread); but it shouldn't have any impact on whether transactions are committed or not.

You can set cacheConsumers to false.

invokeListener() is also invoked from executeOngoingLoop(); if you drill up the stack you'll see (when using local transactions) the commit is done in doExecuteListener().

The management of the...

I suspect you have some thread-safety issues in your down stream components.

The RMI gateways are really a special case. The general idea (much like RMI in general) is if there is a remote exception, it gets propagated back to the caller and the general expectation is that...

That is the default behavior as long as you use the default 'acknowledge-mode="AUTO"', as long as you don't set 'requeue-rejected' to false on the underlying listener container (it defaults to...

That sounds like the "stuck" threads are in user code and never returned to the container.

The transform() method needs to be public.

This forum is for the Spring Integration Project not general integration issues; you should ask your question on one of the web forum.

I am not familiar with that article but it looks like you are...

Try the UserCredentialsConnectionFactoryAdapter.

Your SpEL expression is not valid for a String payload "payload[cpu]", "payload[server]" implies the payload is a Map (which is what the error message is telling you).

You can't just pull some...

The inbound adapter has a message converter; by default it's a SimpleMessageConverter. It needs some clues as to how to interpret the bytes that comprise the payload of the AMQP message. The...

I don't necessarily disagree with you; I am just trying to suggest a clean mechanism, given the current architecture.

I suggested an error-channel on the poller because that's what your post #1...

If you don't mind exposing your code the messaging infrastructure, you could do this...



@Autowired
private MessageChannel channel2;

public void deDup(Message<?> message) {
// preSend...

This change was made a long time ago to avoid unexpected silently dropping messages.

It does seem that the documentation can be improved but, in most cases, the calling code would want to be...

It would be difficult to partition the thread pool across multiple dispatchers.

If you are worried about idle threads, use a range in the pool size, e.g. "1-5", or even "0-5"; then, threads will...

Just be sure that you don't include it in the war; your app server already has its own instance.

Use <scope>provided</scope>.

Well, that is definitely a bug; the adapter should allow a <polller/> child element. Please open a JIRA issue: https://jira.springsource.org/browse/INT

Is there any particular reason you are using...

Add the servlet API to your pom...



<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.0.1</version>
...

Your unit tests either must not use the Servlet API or you need to provide it on the classpath.

There's nothing more explicit than Caused by: java.lang.ClassNotFoundException:...

See this thread for avoiding bogus validation warnings in STS.

Aside from this, when using a queue channel, you will either need a <poller/> child element on the adapter, or a global default...

Thanks.

I do understand your motivation here; I just haven't considered a chain in this context; it just seems "wrong" to me at first glance.

As an aside I, personally, am not a big fan of...