ActiveMQ - Bipin Jethwani's Homepage

emptyslowInternet και Εφαρμογές Web

12 Νοε 2013 (πριν από 3 χρόνια και 7 μήνες)

68 εμφανίσεις

Apache ActiveMQ

Bipin Jethwani

Apache ActiveMQ



Apache ActiveMQ



Leading Open Source messaging platform


Supported Java Standards:

o
JMS,
JavaEE
, JCA and XA






Reliable, high performance messaging



Out
-
performs many legacy proprietary message queues


Configurable for many different deployments






Multi
-
Protocol/Multi
-
Language Support

Background




ActiveMQ started in
2005 at CodeHaus




Moved to
Apache Software Foundation in 2006




Now the most widely used open source messaging system on the planet

JMS Basics

Request/Reply with JMS using temp queues

Now comes the interesting part

to demonstrate how this architecture can be highly scalable. Imagine that a single worker isn’t e
nough
to handle the load of incoming requests. No problem: just add additional workers to handle the load.


Those workers can even be distributed across multiple hosts

this is the most important aspect of scaling this design. Because th
e
workers aren’t contending for the same resources on the same host, the only limit is the maximum throughput of messages throu
gh
the
broker, which is much higher than you can achieve with any classic client server setup.

Persistent Messaging

Non
-
Persistent Messaging



Non
-
persistent delivery is significantly faster



Message Producer sends message to the Broker asynchronously


Message is held in temporary storage


20x improvement in performance

Non
-
Persistent Reliability



Non
-
persistent may be reliable enough



Messages are cached for resending on the Producer


Broker can filter out duplicates


Consumer can filter out duplicates

ActiveMQ Basics

ActiveMQ Connectors

Creating broker using configuration XML


<broker
xmlns
="http://activemq.apache.org/schema/core"


xmlns:xsi
="http://www.w3.org/2001/XMLSchema
-
instance"


xsi:schemaLocation
="http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq
-
core.xsd"


useJmx
="false"


persistent="false">


<
transportConnectors
>



<
transportConnector


name="
tcp
"
uri
="
tcp://localhost:61616
" />


<
transportConnector


name="
nio
"
uri
="
nio:localhost:61618
"/>


</
transportConnectors
>

</broker>

Creating broker using pure Java


BrokerService

broker

= new
BrokerService
();

broker.
addConnector
("
tcp://localhost:61616
");

broker.
addConnector
(“
nio:localhost:61618
”);

broker
.start
();

broker.
waitUntilStarted
();

Transport connectors

For embedded brokers



Since ActiveMQ is written in Java, it can naturally be integrated in another Java application.



As you see, you can configure the broker using either Java code or XML (via the Spring Framework).



A fully configured broker can serve clients from the same application (using the
VM protocol
) as well as clients from
remote applications to exchange messages over the network.

Transport connectors
(continued…)

The transport connector URI is used to create a connection to the broker in order to send and receive messages

Transport connectors
(continued…)

From the client’s perspective

<
transportConnectors
>


<
transportConnector

name="
openwire
"

uri
="
tcp
://localhost:61616"
discoveryUri
="multicast://default"/>


<
transportConnector

name="
ssl
"

uri
="ssl://localhost:61617"/>


<
transportConnector

name="
stomp
"

uri
="stomp://localhost:61613"/>


<
transportConnector

name="
xmpp
"

uri
="xmpp://localhost:61222"/>

</
transportConnectors
>

Wire protocols

Transport connectors


The overall functionality of this setup remains unchanged and both the publisher and the consumer behave the same as the
previous single broker setups. The only difference is that the publisher and the consumer are now connecting to different
brokers that are networked using the static protocol.


Using this setup, messages are published to BrokerA.

These messages are then forwarded to BrokerB, where they’re received by the consumer.


From this simple setup you can conclude that this particular configuration can help you in situations when you need your
distributed clients to benefit from the performance advantages of communicating with the local broker instead of a remote
one. Not only will this minimize the number of network connections between the remote host and the local host, but it’ll all
ow
the client applications in the remote host to operate more efficiently. The removal of the long haul connection over the wide

area network means less latency and therefore less waiting for the client application.


Network connectors

A network connector is a unidirectional channel by default.

A given broker communicates in one direction by only forwarding
messages it receives to the brokers on the other side of the
connection.


This setup is commonly referred to as a
forwarding bridge.

In some situations, you may want to create a bidirectional communication
channel between brokers

a channel that communicates not only outward
to the brokers on the other side of the connection, but also receives
messages from other brokers on that same channel.


This setup is commonly referred to as a
duplex connector
.

Network connectors

Network connectors

Client Failover


Java and C++ clients support seamless failover

Embedded Broker

Often it makes sense to deploy a broker within your JVM. This allows you to
optimise away a network hop; making the networking of JMS as efficient as
pure RMI, but with all the usual JMS features of location independence,
reliability, load balancing etc.

Using explicit Java code

The following Java code will create an embedded broker

If you want to lazily bind the transport connector as part of start(), useful when start() will block
pending a store lock (as in a slave start), you can use the following code

In the same JVM clients can then use the

vm:// transport

to connect to
the embedded broker
-

whilst external clients can use the
tcp:// protocol

If you have more than one embedded broker, ensure that you give
them a unique name and
-

e.g.

Then if you want to connect to the broker named 'fred' from within the
same JVM, you can by using the uri

vm://fred

Embedded Broker (continued…)

Using ActiveMQConnectionFactory

An embedded broker can also be created using an ActiveMQConnectionFactory and using a vm connector as a uri.
e.g. The broker will be created upon creation of a connection.


You can turn off auto creation by setting the create property on the VM Transport to false:


ActiveMQConnectionFactory

cf =
new

ActiveMQConnectionFactory
("
vm://localhost
?create=false");



ActiveMQConnectionFactory

cf =
new

ActiveMQConnectionFactory
("
vm://localhost
?broker.persistent=false");


Embedded Broker (continued…)

OpenWire clients



Efficient binary implementation




Network outage detection




Client failover




Java, C++ and C# clients.

Stomp



Designed and implemented by ActiveMQ team




Designed to be easy to use and implement




Lots of client implementations:



Ruby,


C, C++, C#, .Net,


Delphi,


Flash,


hx,


Perl,


PHP, Pike, Python, Smalltalk


to name a few.

JMX

service:jmx:rmi
:///
jndi
/
rmi
://localhost:2011/
jmxrmi

Monitoring ActiveMQ with advisory messages

Advisory messages are delivered to topics whose names use the prefix
ActiveMQ.Advisory
. For example, if you’re interested in knowing
when connections to the broker are started and stopped, you can see this activity by subscribing to the
ActiveMQ.Advisory.Connection

topic.

A variety of advisory topics are available

depending on what broker events interest you. Basic events such as starting and stopping

consumers, producers, and connections trigger advisory messages by default. But

for more complex events, such as sending messages to a destination without a consumer,

advisory messages must be explicitly enabled as shown next.

ActiveMQ supports advisory messages which allows you to
watch the system
using regular JMS
messages.


consumers, producers and connections starting and stopping



temporary destinations being created and destroyed



messages expiring on topics and queues



brokers sending messages to destinations with no consumers.



connections starting and stopping

Prefetch Limit

Networks of brokers

ActiveMQ supports

networks of brokers

which allows
us to support

distributed queues and topics

across a
network of brokers.

There are two different types of broker to broker communication

Master/Slave for High Availability

A

Store and Forward Network of Brokers

means
the messages travel from broker to broker until
they reach a consumer; with each message being
owned by a single broker at any point in time.
When a JMS producer sends a message to a JMS
consumer, it may travel through several brokers to
reach its final destination

In general, discovery is a process of detecting

remote broker services. Clients usually want to
discover all available brokers. Brokers,

on the other hand, usually want to find other
available brokers so they can establish a

network of brokers.

Networks of brokers

Networks of brokers

By default, network connectors are initiated serially as part of the broker start up sequence. When
some networks are slow, they prevent other networks from starting in a timely manner. Version 5.5
supports the broker attribute
networkConnectorStartAsync="true"

which will cause the broker to
use an executor to start network connectors in parallel, asynchronous to a broker start.

<networkConnectors>


<networkConnector name="local network“





uri="
static
://(tcp://remotehost1:61616,tcp://remotehost2:61616)"/>

</networkConnectors>

INFO DiscoveryNetworkConnector
-

Establishing network connection between


from vm://localhost to tcp://remotehost1:61616

INFO TransportConnector
-

Connector vm://localhost Started

INFO DiscoveryNetworkConnector
-

Establishing network connection between


from vm://localhost to tcp://remotehost2:61616

INFO DemandForwardingBridge
-

Network connection between vm://localhost#0


and tcp://remotehost1:61616 has been established.

INFO DemandForwardingBridge
-

Network connection between vm://localhost#2


and tcp://remotehost2:61616 has been established.

The output indicates that the broker on the localhost has successfully configured a
forwarding bridge with two other
brokers running on two remote hosts. In other words,
messages sent to the local broker will be forwarded to brokers
running on remotehost1 and remotehost2, but only if there’s demand for those messages from a consumer.

How ActiveMQ passes messages across a network of brokers

Networks of brokers

Store and forward (unidirectional)


When a network is established from a local broker to a remote
broker, the
remote broker

will pass information containing all its
durable and active
consumers
’ destinations to the local broker.


The
local broker
uses this information to determine what
messages the remote broker is interested in and
forward

them to
the remote broker.


If you want networks to be bidirectional, you can either configure
the remote broker with
a network connector
to point to the local

broker, or configure a network connector to be
duplex

so it sends
messages in both directions

Networks of brokers

How ActiveMQ passes messages across a network of brokers

The diagram of the supermarket broker in figure requires that the network connector be configured in duplex mode. The single
network connection, established from the supermarket broker to the back office, would be able to pass messages in both direct
ion
s
and would behave in the same way as if the back office broker had established a normal network connection back to the superma
rke
t
broker.

Suppose you have a deployment scenario where you have many supermarkets that need to connect to a back office order system.

It would be hard to configure new supermarkets and inflexible for the broker(s) at the back office to be aware of all the rem
ote

brokers in each new supermarket. Typically the back office brokers would be located behind a firewall with only a limited num
ber

of ports open to accept connections inward

Networks of brokers

How ActiveMQ passes messages across a network of brokers

Networks of brokers

How ActiveMQ passes messages across a network of brokers

Networks of brokers

Network Discovery

Dynamic


Using multicast discovery to create network connections is straightforward.


When you start an ActiveMQ broker with a multicast transport on a network
connector, it will search for another broker using IP multicast and establish a
connection.

There are a couple of limitations with multicast discovery, including the ability to

control which brokers are discovered, and the fact that it’s usually restricted to
the discovery of brokers on the local network segment. This is because IP
multicast doesn’t extend through routers.