You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (JIRA)" <ji...@apache.org> on 2012/06/15 14:03:43 UTC
[jira] [Commented] (CAMEL-5370) New simple component for
synchronous, cross-context messaging
[ https://issues.apache.org/jira/browse/CAMEL-5370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295611#comment-13295611 ]
Claus Ibsen commented on CAMEL-5370:
------------------------------------
Chat history
[09:44:58] <gnodet> cibsen: you don't think we can have a vm:// component which is synchronous ? doesn't that make sense to support transactions ?
[09:47:07] <cibsen> gnodet there has been a JIRA to support TX async
[09:47:21] <cibsen> so that would have been the solution we wanted really
[09:47:25] <cibsen> but not developed
[09:47:26] <gnodet> yeah, but that's a major change
[09:47:42] <gnodet> having a synchronous vm component is way easier and without much impact
[09:47:59] <cibsen> the vm works in osgi as well (but not intended)
[09:48:16] <cibsen> but you want to use current thread
[09:48:28] <gnodet> yeah, i know, but it's async to does not support transactions, hence the jira issue
[09:48:42] <cibsen> well the jira ticket is poorly named
[09:48:47] <gnodet> definitely
[09:48:54] <gnodet> i agree
[09:49:13] <gnodet> but the use case is still here
[09:49:36] <gnodet> that's why i added a comment because i don't think direct should be the same as vm
[09:50:00] <cibsen> yeah direct should be the light weight intra in the same camelcontext
[09:50:01] <gnodet> it needs to be either an option on vm (though that may be a bit weird too), or just a new component which would be sync and global
[09:50:24] <cibsen> yeah i think a new is better
[09:50:29] <cibsen> as the vm is on top of seda
[09:50:37] <cibsen> and the async stuff is then baked in
[09:50:45] <cibsen> would complicate the code base a bit to make it sync
[09:50:53] <gnodet> yes, i agree
[09:50:54] <cibsen> although you can possible cheat with a sync thread pool executor
[09:51:04] <cibsen> but the code still reads as if its async
[09:51:28] <cibsen> so a new simple component for sync messaging, and a way to do that across camel contexts
[09:51:40] <cibsen> and some way of plugging the lookup of the other camel contexts
[09:51:53] <cibsen> for osgi maybe we can lookup in the registry or some way?
[09:52:05] <cibsen> the vm component in camel-core is a bit cheating with the static queue
[09:52:14] <cibsen> fell free to log a JIRA
[09:53:47] geaaru (~geaaru@host170-152-static.43-88-b.business.telecomitalia.it) joined the channel.
[09:56:30] <gnodet> i don't think we expose the endpoints in the osgi registry
[09:56:38] rbalent (~rbalent@91.148.6.91) joined the channel.
[09:56:42] <gnodet> though we know about all the camel contexts, so we could look them up
[09:56:50] <gnodet> but i'm not even sure we need to make it specific to osgi at all
[09:59:26] <cibsen> wouldn't the idea be to call a route in another bundle
[09:59:34] <cibsen> from X to Y (bundle A)
[09:59:45] <gnodet> yeah, but there's not need for it to be osgi specific
[09:59:46] <cibsen> from Y to Z (bundle B)
[10:00:00] <cibsen> yeah if that can be generic
[10:00:12] <gnodet> vm works well in osgi just because it uses a static list of queues
[10:00:19] <gnodet> which is all what is needed
[10:00:30] <gnodet> CAMEL-5370
[10:00:37] <gnodet> cibsen: chm007 ^^^
[10:00:58] <cibsen> yeah
[10:01:15] <cibsen> for the same camel-core version
[10:01:50] <cibsen> then if the consumer uses a "synchronous thread pool" then we can cheat and use the same thread
[10:02:06] <cibsen> and it would work in osgi and outside as well
[10:03:48] <gnodet> yeah, if you need multiple camel-core versions to interoperate you need an external protocol, nmr http, jms or whatever
[10:03:49] <chm007> I agree. This modification should not be specific to OSGI as camel routes deployed in different WAR files should also be able to use his feature
[10:04:46] <cibsen> org.apache.camel.util.concurrent.SynchronousExecutorService
[10:04:52] <cibsen> we got a sync thread pool
[10:05:25] <cibsen> and use this camel api to get one, to be consistent
[10:05:26] <cibsen> org.apache.camel.spi.ExecutorServiceStrategy#newSynchronousThreadPool
[10:06:07] <cibsen> yes it would work for tomcat users as well, if they do the camel-core trick in the boot classpath
[10:06:30] <cibsen> albeith it may introduce other issues, but life is pro/cons
[10:10:39] <gnodet> yeah
[10:19:39] <cibsen> so what would be a good name for such a component?
[10:22:56] <cibsen> direct-vm
[10:22:57] <cibsen> directvm
[10:23:01] <cibsen> vmdirect
[10:23:02] <cibsen> vmsync
[10:23:23] <cibsen> direct-other-side-of-the-fence
[10:32:24] <cibsen> and it can only be a 1:1 invocation right? we should not try to support multiple consumers?
[10:36:43] <cibsen> we could consider if we could link to direct endpoint from the other bundle
[10:36:45] <cibsen> so you can do
[10:36:50] <cibsen> from jms:foo
[10:36:55] <cibsen> to direct-vm:bar
[10:36:57] <cibsen> and in bundle B
[10:37:02] <cibsen> from direct:bar
[10:37:04] <cibsen> to jms:bar
[10:37:36] <cibsen> and then direct-vm:bar will "somehow" figure out that it should use the consumer "direct:bar"
[10:37:39] <cibsen> but that could be tricky
[10:39:20] <cibsen> i guess just using direct-vm makes it explicit that its a vm like endpoint
[10:39:27] <cibsen> so maybe just stick to that
[10:39:38] <cibsen> then direct is always only intra camel context
[10:46:36] <gnodet> yeah, not sure between direct-vm or vmsync, both looks good to me anyway
[10:46:48] <cibsen> going for direct-vm
[10:47:31] rajdavies (~rajdavie@host86-160-139-239.range86-160.btcentralplus.com) joined the channel.
[10:51:19] jgoodyear (~jgoodyea@142.162.119.36) joined the channel.
[11:42:11] <cibsen> okay got a prototype up and running
[11:42:15] <cibsen> with 2 different camel context
[11:42:16] <cibsen> 2012-06-15 11:41:13,424 [main ] INFO route2 - Running on Camel camel-2 on thread main with message Hello World
[11:42:16] <cibsen> 2012-06-15 11:41:20,662 [main ] INFO route1 - Running on Camel camel-1 on thread main with message Bye World
[11:42:24] <cibsen> using the main thread to process
[13:05:15] dkulp (~dkulp@c-24-91-72-253.hsd1.ma.comcast.net) joined the channel.
> New simple component for synchronous, cross-context messaging
> -------------------------------------------------------------
>
> Key: CAMEL-5370
> URL: https://issues.apache.org/jira/browse/CAMEL-5370
> Project: Camel
> Issue Type: New Feature
> Reporter: Guillaume Nodet
> Assignee: Claus Ibsen
> Fix For: 2.10.0
>
>
> The vm:// component is nice but does not support synchronous calls (which is currently required for transactions) and the direct:// component does not support cross-context calls.
> A new hybrid component would be handy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira