>>> Its the Camel routing engine underneath that adds in behavior to >>> control the routing, and deal with interceptors, tracing, error >>> handling, asynchronous non-blocking routing and whatnot. >> >> Ya I understand that. I'm still not sure how all of the async* bits come in >> to play. Perhaps those are the same bits which would be used if it was >> async or not? >> >> Just wasn't sure from looking at the stack that perhaps I missed some >> configuration to optimize messaging handling these very simple routes. >> > > The class names which indicate AsyncXXX but they are part of the > asynchronous non-blocking routing engine, which supports regular > synchronous routing as well. So Camel will by default uses these > AsyncXXX classes for routing to support both async and sync. > > And mind that the behavior can change during routing, in case a > component leverages async non blocking processing, such as CXF, Jetty, > JMS etc. So a message could have been picked up from a file component > which is sync, and then the routing goes async because the file is > send to a CXF endpoint, etc.
Thank you for the clarification :-) --jason
