I don't have the stacktraces just now. I simply made scalaz-camel's method
that creates endpoints synchronous. If needed I can undo that and create
some traces.
While there are lots of mutable collections in DefaultCamelContext, the only
one I ran into issues with was lifecycleStrategies.
--
Vi
Looking at DefaultCamelContext a bit its seem clear that its not intended for
multi-threaded access. Fortunately, since I use scalaz-camel to define all
my routes/endpoints I have a very small api to protect. A quick spike in
synchronizing the creation of endpoints -- the only CamelContext mutation
Still an issue with 2.8.1. When routes are added from multiple threads any
place that iterates on context.lifeCycleStrategies (typically within camel
itself) can throw ConcurrentModificationException.
I can write a test for this, but first I would like to know if its supported
to add routes from m
(I'm updating to 2.8.1 now to check things out. But I may need to compile
some other packages, so it could take a bit.)
--
View this message in context:
http://camel.465427.n5.nabble.com/ConcurrentModificationException-added-routes-from-multiple-threads-tp4831653p4831660.html
Sent from the Camel
The problem is due to the variable DefaultCamelContext.lifecycleStrategies
One thread can be adding to that list via addLifecycleStrategy while another
thread can be iterating thru the collection. For me I'm adding routes from
multiple threads.
I saw a jira issue for this quite a ways back but it
I see it was removed in revision 1067441. Yet the web site docs still how it
as an option. Also I could not find any indication in the release notes that
it was removed and why.
--
View this message in context:
http://camel.465427.n5.nabble.com/FYI-JmsEndpoint-consumerType-removed-but-still-in-do
I'm only using one smtp endpoint. I also send email via logback via the same
smtp server with the same credentials and that never fails. I was looking at
how logback uses javamail vs spring and its quite different. Logback sets up
an authenticator with the transport, where passes the u/p with each
I am sending emails from a server. The emails get sent fine for some hours
(up to 24) but then I start getting exceptions that are ultimately:
Caused by: javax.mail.AuthenticationFailedException: null
I am using the default javaMailSender and sending via gmail. The jvm is
started with Dmail.smt
I'm trying to test a component that sends email via smtp. But I'm not able to
configure mock endpoint because it contains parameters that don't get
resolved.
ccontext.addComponent("smtp", new MockComponent)
val uri = "smtp://host:?username=smtpusername&password=smtppassword"
ccontext.getEnd
It appears the real culprit is akka-camel. When akka camel actors are
stopped, akka-camel stops the route for the actor. This is done
asynchronously. Also it seems that akka also is (at least partially)
asynchronous in its shutdown. So while all the akka camel actors get stopped
long before camel,
Well, thats not it. I'm still getting NPEs for routes I don't explicitly stop
(I think ;-).
--
View this message in context:
http://camel.465427.n5.nabble.com/NPE-on-JmsConsumer-shutdown-tp3386582p3386650.html
Sent from the Camel - Users mailing list archive at Nabble.com.
I think I see what is happening, but not why yet.
I have a component that stops its route explicitly. This is needed because
these components are dynamically created and destroyed. This done via:
ccontext.stopRoute(deviceContext.scheduleRouteId)
But then later when the CamelContext itse
I'm having problems getting a clean shutdown of my jms routes. I am seeing
messages like:
Route: caef5400-393f-11e0-96f5-001bfc9b4a1b suspended and shutdown deferred,
was consuming from:
Endpoint[jms://topic:utilization.device.*.timeline.lifecycle]
And then later on getting:
:18:39,967 WARN o.
Why does the parameter need to be tied to anything? It simply needs to be
passed on to activemq, which itself will ensure (in this case) the policy
gets the parameter.
Maybe something much simpler, like a passthru prefix, eg
?passthru.query=.
I haven't looked closely yet at how the exception
from("jms:topic:mytopic?query='from=today'") .process { ... }
Its really that simple, although the value for query can be any string.
For that topic I have defined a custom QueryBasedSubscriptionRecoveryPolicy
to which activemq will provide the query parameter value when a client
subscribes, gi
Looking at the jms and activemq docs (haven't yet looked at the code) it
appears that there are a whole set of parameters that cannot be passed thru
to activemq. Specifically I have a custom
QueryBasedSubscriptionRecoveryPolicy and need to pass the 'query' parameter.
Is there some back door mech
In trying to implement a very simple camel route in scala and have run into a
dead-end. First consider this java version:
public class CamelJavaTyperTest {
private DefaultCamelContext camel = new DefaultCamelContext();
private Processor p1 = new Processor() {
@Override public vo
Claus Ibsen-2 wrote:
>
> BTW What would the API of the Clock be?
>
The only api that would be "needed" for current code could simply mirror
System.*, eg:
interface CamelClock {
public long currentTimeMillis();
public long nanoTime();
}
Of course this won't help with timers and the
James.Strachan wrote:
>
> I guess it could be injected via Ioc? Or available on the CamelContext I
> guess?
>
But there is no camel wide IOC in place, is there? I look if the
CamelContext is available in the places where the CamelClock is need. (Now
if only I didn't have play "find my non-publ
Looking thru 2.1, there really aren't too many places where System.* time
methods are used. Would Camel be interesting in patch that provides a clock
abstraction (with just the two System.* time methods) where the default
implementation would be System.*?
If so, what would be the camel way of pr
Am I missing the abstraction of a camel clock? I've tried to start using the
new Sampling Throttle and notice that it uses java.lang.System.nanoTime()
directly. So I'm guessing all other camel components go right to System for
time...
What I'm looking for (needing) is something like in Drools, w
I added the following proxies to my nexus and now I can build trunk:
- http://repo.fusesource.com/maven2-all/
- http://gaejtools.sourceforge.jp/maven/repository.
Maybe (your/required) nexus proxies should be listed on on the wiki
somewhere?
--
View this message in context:
http://old.nabble.com
Hmm, ok. I do use nexus, and assumed you did as well. But I have about a
dozen proxy repositories setup so I wondered if the nexus that cemel is
built against has some proxies that I do not. But if it should build
straight out of the box, I'll look into each missing dep. Thanks.
--
View this mess
Are some of the repositories used by the development team contained in a
repository defined in a settings.xml? I get numerous missing dependencies
when I try to compile trunk.
--
View this message in context:
http://old.nabble.com/Building-camel-trunk%3A-resolving-dependencies--tp26499933p264999
Its a bit painful to have to generate and install the source jars everyday.
Would it be possible to publish them to the repository?
--
View this message in context:
http://old.nabble.com/Are-sources-not-published-for-snapshot-builds-by-design--tp26499928p26499928.html
Sent from the Camel - Users
I'm trying to reason out an application design.
I have a "service" that I want to make available to "clients" via various
protocols (http, jms, mina, etc). I will need some adapter layers on the
"service" side to, eg, populate the http response code.
I would like remote clients to access to acce
Works perfect. Thanks very much Claus!
--
View this message in context:
http://www.nabble.com/camel-jetty-to-handle-%22prefix%22-uri--tp25919650p25926725.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Is there any way to use a partial uri with camel-jetty? eg,
from("jetty:http://host/";) where "http://host/foobar"; would be handled (and
the processor would decide what to do given the full uri)?
-barry
--
View this message in context:
http://www.nabble.com/camel-jetty-to-handle-%22prefix%22-u
28 matches
Mail list logo
