Announcement Announcement Module
No announcement yet.
Standlone Spring Integration in the back end - Single process or multiple processes ? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Standlone Spring Integration in the back end - Single process or multiple processes ?


    i'am relatively new to Spring Integration.

    We are planning to use Spring Integration in the back end and the Communication from front end is based on AMQP queues. We will be using in the SI in the back-end. We don't have a application server and we will be running a main program to initialize the context and then it will start listening to the queues configured in the inbound adapter.

    <si-amqp:inbound-channel-adapter queue-names="create_event_queue" channel="convertJson" connection-factory="amqpConnectionFactory" acknowledge-mode="AUTO" concurrent-consumers="10"/>
    We will have 5 to 10 queues(and corresponding adapters) with the similar configuration as mentioned above.

    Apart from that, we also have few polling components/jobs (some are batch) that will query the database on a periodic basis

    <si:inbound-channel-adapter ref="purgeService" method="isEditable" channel="modifyChannel">
    		<si:poller fixed-delay="1000" max-messages-per-poll="1"/>
    Currently for the POC, I have written different main programs for each of these listeners/jobs and hence all will run as separate back end processes. The other option to have one bootstrap program that will load all the spring configurations, and it looks like much easier to manage. What is the recommended practice in this scenarios? What are the pros and cons of these approaches ?

    Thanks and regards,
    Last edited by antonypulicken; Apr 1st, 2013, 09:19 PM.

  • #2

    Appreciate if some one can respond to my queries. Please let me know in case I need to provide any additional details.



    • #3

      We are actually working on a few things for Spring Integration 3.0 that will be directly relevant. For example, we will support parameterizable flow definitions (modules) that can be composed into distributed flows with a channel registry for the connections between modular flows. That channel registry could be backed by different Spring Integration adapters (rabbit, jms, redis, tcp, ...)

      The first commits with that functionality should be available in the 3.0 git branch (current master) within a few weeks.

      In the meantime, this sample might be relevant:

      Hope that helps,


      • #4
        Thanks Mark. I looked at the sample you mentioned.

        But looks like I haven't explained my question correctly ! Let me try to re-phrase the question. In my project I have multiple jobs, multiple independent AMQP listeners (each of this listener have concurrency set to 10) listening to different queues etc.

        I have separate spring configuration files and separate main programs for initializing each of these..functionally, this is fine as each of these process communicate using queues.....But I will end up having multiple java processes running .... obviously, this makes it difficult to manage and it creates lot of overhead as these processes cannot share anything.....

        So, my question is whether we can have a single main program/process that will initialize all these configuration files ? In other words, what are the pros and cons of having single spring container over multiple spring containers ?



        • #5
          Well, as with all these types of questions... it depends...

          Certainly, a single process (main) is easier to manage, but then you have to consider issues such as dependencies.

          If you have multiple apps in the same JVM you, typically, need to have them use the same version of, say, Spring. You can deal with that, but it means getting involved with complex concepts such as class loaders.

          If you can live with all your apps using the same version of libraries etc, then that's what I'd do.

          You might want to consider having each app in its own context (so you can bounce them independently of the JVM - perhaps using JMX),


          • #6
            Thanks Gary ! I got it..

            By the way, will it make any difference from a performance perspective ? Will a single process/context make it any slower compared to having separate process/context for each app ?



            • #7
              ...Will a single process/context make it any slower...
              Generally, not, but there are likely to be some corner cases. For example if one of your "apps" causes a lot of garbage collection, it could impact other threads in the same JVM.