Announcement Announcement Module
No announcement yet.
ActiveMQ - Spring bean injection Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • ActiveMQ - Spring bean injection

    I am trying to understand more about ActiveMQ (JMS implementation) and the integration with 'Spring integration' framework .

    <bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFacto ry">
    <property name="brokerURL" value="tcp://localhost:61616" />

    When we instantiate a bean like that - do we expect any other process running on that particular host / port listed above ( may be a broker process ? ) .

    ( if not - Is there any way we can integrate the same with the spring config. so that when the spring application context is loaded from the .xml file, the broker is already up and running on the requisite name / port . )

  • #2
    When you use the tcp-based broker URL, you are in fact expecting the ActiveMQ process to be running (the default port is 61616). To accomplish that you can call the start script (batch or shell depending on your platform).

    If you only want to use ActiveMQ for a single Java process, you can use the embedded broker option. For more info about the various URI options in ActiveMQ, see:


    • #3
      Thanks Mark for the clarification.

      For the vm uri - the broker seems to be created if we instantiate the ActiveConnectionFactory though. More details available at the end of the page at - how-do-i-embed-a-broker-inside-a-connection .


      • #4
        Yes, the embedded broker is created upon instantiation. Can you explain exactly what you want to happen?


        • #5
          I am new to Spring Integration (and Active MQ ) as well.

          The problem statement is:

          * Single channel with 2 end-points ( 1 producer , 1 consumer )
          * When a spring config. is loaded - the broker is available in the same local vm as the consumer - and so when the consumer spring applicationContext is initialized then that should guarantee the availability of the broker as well.

          * Producer wants to talk via a single channel to the consumer by means of a pre-agreed message format.

          [ I was thinking along the lines of the producer initiating the connection factory ( tcp to end point as in the consumer, same host and same port) and sending message on the same queue ] .

          Let me know some pseudo-code to get started on the same.


          • #6
            If I understand, then you have the Producer and Consumer in separate VMs?


            • #7
              Oh yes- absolutely . in separate physical nodes in different VMs ( no distributed JVM etc.).


              • #8
                Generally, it's good to have the JMS provider running as a separate process so that either your Producer VM or Consumer VM may be unavailable without causing failures to cascade to the other. For example, start ActiveMQ (with the default TCP broker), and then have the same connection-factory settings for both the Producer and Consumer VMs to connect to that. Is there a specific reason that you want to tie the broker directly to the Consumer VM?


                • #9
                  Originally posted by Mark Fisher View Post
                  ...Is there a specific reason that you want to tie the broker directly to the Consumer VM?
                  Actually no - that was more from a convenience perspective . But probably from a deployment perspective - the consumer and the broker might be in the same machine , while the producer might live in another. But the communication would still be via tcp (openwire for ActiveMQ).


                  • #10
                    If you want an example for getting started with this approach, you can use the sample included in 'org.springframework.integration.samples.jms'. In the 'common.xml' file, you can simply modify the "brokerURL" value (e.g. "tcp://[your-host]:61616").

                    Does that help?


                    • #11
                      Thanks Mark . That is exactly what I was looking for.