You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by "steven.marcus" <st...@gmail.com> on 2008/02/15 22:26:43 UTC
seda broken in latest snapshot
I'm seeing
Exception in thread "pool-3-thread-38"
org.apache.camel.RuntimeCamelException: java.lang.IllegalStateException:
Queue full
at org.apache.camel.util.ProducerCache.send(ProducerCache.java:86)
at org.apache.camel.CamelTemplate.send(CamelTemplate.java:119)
at org.apache.camel.CamelTemplate.sendBody(CamelTemplate.java:170)
at org.apache.camel.CamelTemplate.sendBody(CamelTemplate.java:379)
in code that used to work until the latest snapshot.
Perhaps I'm using the seda queues incorrectly?
Here's my route:
from("direct:ticks").to(//
"seda:ticks", //
b("barFactory", "onTick")//
);
from("seda:ticks").to(//
b("tickArchive", "onTick")//
);
and
static String b(String beanName, String methodName) {
return "bean:" + beanName + "?methodName=" + methodName;
}
Any suggestions? Am I using them incorrectly? Or did they break in the
recent refactoring?
Any suggestions on camel dsl "style" appreciated too!
thanks in advance,
Steven Marcus
--
View this message in context: http://www.nabble.com/seda-broken-in-latest-snapshot-tp15510480s22882p15510480.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: seda consumer thread robustness (was Re: seda broken in latest snapshot?)
Posted by James Strachan <ja...@gmail.com>.
Patch applied Steven, many thanks!
On 22/02/2008, steven.marcus <st...@gmail.com> wrote:
>
> I was concerned about a broken seda queue thread. Turns out the problem was a
> deadlock unrelated to Camel, but the changes to SedaConsumer are probably
> worthwhile:
>
> public void run() {
>
> while (isRunAllowed()) {
>
> final Exchange exchange;
> try {
>
> exchange = endpoint.getQueue()
> .poll(1000, TimeUnit.MILLISECONDS);
>
> } catch (InterruptedException e) {
>
> if (isRunAllowed())
> LOG.warn("spurious interrupt?!");
> continue;
>
> }
>
> if (exchange != null && isRunAllowed()) {
>
> try {
>
> processor.process(exchange, new AsyncCallback() {
> public void done(boolean sync) {
> }
> });
>
> } catch (RuntimeException rte) {
>
> LOG.error(rte);
> }
> }
> }
> }
>
> Thanks to team Camel,
> Steven Marcus
>
> --
> View this message in context: http://www.nabble.com/seda-broken-in-latest-snapshot-tp15510480s22882p15641995.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
seda consumer thread robustness (was Re: seda broken in latest
snapshot?)
Posted by "steven.marcus" <st...@gmail.com>.
I was concerned about a broken seda queue thread. Turns out the problem was a
deadlock unrelated to Camel, but the changes to SedaConsumer are probably
worthwhile:
public void run() {
while (isRunAllowed()) {
final Exchange exchange;
try {
exchange = endpoint.getQueue()
.poll(1000, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
if (isRunAllowed())
LOG.warn("spurious interrupt?!");
continue;
}
if (exchange != null && isRunAllowed()) {
try {
processor.process(exchange, new AsyncCallback() {
public void done(boolean sync) {
}
});
} catch (RuntimeException rte) {
LOG.error(rte);
}
}
}
}
Thanks to team Camel,
Steven Marcus
--
View this message in context: http://www.nabble.com/seda-broken-in-latest-snapshot-tp15510480s22882p15641995.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: seda broken in latest snapshot?
Posted by "steven.marcus" <st...@gmail.com>.
There was supposed to be a ? at the end of the subject!
It might be that the execution dynamics of the seda client have changed at
the default queue size of 1000 is now no longer sufficient.
However, a couple of questions about SedaConsumer:
public void run() {
while (isRunAllowed()) {
final Exchange exchange;
try {
exchange = endpoint.getQueue().poll(1000,
TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
break;
}
if (exchange != null && isRunAllowed()) {
processor.process(exchange, new AsyncCallback() {
public void done(boolean sync) {
}
});
}
}
}
Is there a need to be concerned about abnormal consumer thread termination?
The code in processor.process might throw an exception and kill the seda
queue.
Logging might be useful at a minimum.
Also, are "spurious interrupts" still a concern? If so, continue would be
better than break to exit only if isRunAllowed() says so to do...
catch (InterruptedException e) {
continue; // break;
}
thanks again for camel!
--
View this message in context: http://www.nabble.com/seda-broken-in-latest-snapshot-tp15510480s22882p15513400.html
Sent from the Camel - Users mailing list archive at Nabble.com.