Added: websites/production/activemq/content/artemis/docs/latest/core-bridges.html ============================================================================== --- websites/production/activemq/content/artemis/docs/latest/core-bridges.html (added) +++ websites/production/activemq/content/artemis/docs/latest/core-bridges.html Thu Sep 14 19:48:11 2017 @@ -0,0 +1,1254 @@ + + + + + Core Bridges · ActiveMQ Artemis Documentation + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ + + + + + + + +
+ +
+ +
+ + + + + + + + +
+
+ +
+
+ +
+ +

Core Bridges

+

The function of a bridge is to consume messages from a source queue, and +forward them to a target address, typically on a different Apache ActiveMQ Artemis +server.

+

The source and target servers do not have to be in the same cluster +which makes bridging suitable for reliably sending messages from one +cluster to another, for instance across a WAN, or internet and where the +connection may be unreliable.

+

The bridge has built in resilience to failure so if the target server +connection is lost, e.g. due to network failure, the bridge will retry +connecting to the target until it comes back online. When it comes back +online it will resume operation as normal.

+

In summary, bridges are a way to reliably connect two separate Apache ActiveMQ Artemis +servers together. With a core bridge both source and target servers must +be Apache ActiveMQ Artemis servers.

+

Bridges can be configured to provide once and only once delivery +guarantees even in the event of the failure of the source or the target +server. They do this by using duplicate detection (described in Duplicate Detection).

+
+

Note

+

Although they have similar function, don't confuse core bridges with +JMS bridges!

+

Core bridges are for linking an Apache ActiveMQ Artemis node with another Apache ActiveMQ Artemis +node and do not use the JMS API. A JMS Bridge is used for linking any +two JMS 1.1 compliant JMS providers. So, a JMS Bridge could be used +for bridging to or from different JMS compliant messaging system. It's +always preferable to use a core bridge if you can. Core bridges use +duplicate detection to provide once and only once guarantees. To +provide the same guarantee using a JMS bridge you would have to use XA +which has a higher overhead and is more complex to configure.

+
+

Configuring Bridges

+

Bridges are configured in broker.xml. Let's kick off +with an example (this is actually from the bridge example):

+
<bridge name="my-bridge">
+   <queue-name>sausage-factory</queue-name>
+   <forwarding-address>mincing-machine</forwarding-address>
+   <filter string="name='aardvark'"/>
+   <transformer-class-name>
+      org.apache.activemq.artemis.jms.example.HatColourChangeTransformer
+   </transformer-class-name>
+   <retry-interval>1000</retry-interval>
+   <ha>true</ha>
+   <retry-interval-multiplier>1.0</retry-interval-multiplier>
+   <initial-connect-attempts>-1</initial-connect-attempts>
+   <reconnect-attempts>-1</reconnect-attempts>
+   <failover-on-server-shutdown>false</failover-on-server-shutdown>
+   <use-duplicate-detection>true</use-duplicate-detection>
+   <confirmation-window-size>10000000</confirmation-window-size>
+   <user>foouser</user>
+   <password>foopassword</password>
+   <static-connectors>
+      <connector-ref>remote-connector</connector-ref>
+   </static-connectors>
+   <!-- alternative to static-connectors
+   <discovery-group-ref discovery-group-name="bridge-discovery-group"/>
+   -->
+</bridge>
+

In the above example we have shown all the parameters its possible to +configure for a bridge. In practice you might use many of the defaults +so it won't be necessary to specify them all explicitly.

+

Let's take a look at all the parameters in turn:

+
    +
  • name attribute. All bridges must have a unique name in the server.

    +
  • +
  • queue-name. This is the unique name of the local queue that the +bridge consumes from, it's a mandatory parameter.

    +

    The queue must already exist by the time the bridge is instantiated +at start-up.

    +
  • +
  • forwarding-address. This is the address on the target server that +the message will be forwarded to. If a forwarding address is not +specified, then the original address of the message will be +retained.

    +
  • +
  • filter-string. An optional filter string can be supplied. If +specified then only messages which match the filter expression +specified in the filter string will be forwarded. The filter string +follows the ActiveMQ Artemis filter expression syntax described in Filter Expressions.

    +
  • +
  • transformer-class-name. An optional transformer-class-name can be +specified. This is the name of a user-defined class which implements +the org.apache.activemq.artemis.core.server.cluster.Transformer interface.

    +

    If this is specified then the transformer's transform() method +will be invoked with the message before it is forwarded. This gives +you the opportunity to transform the message's header or body before +forwarding it.

    +
  • +
  • ha. This optional parameter determines whether or not this bridge +should support high availability. True means it will connect to any +available server in a cluster and support failover. The default +value is false.

    +
  • +
  • retry-interval. This optional parameter determines the period in +milliseconds between subsequent reconnection attempts, if the +connection to the target server has failed. The default value is +2000milliseconds.

    +
  • +
  • retry-interval-multiplier. This optional parameter determines +determines a multiplier to apply to the time since the last retry to +compute the time to the next retry.

    +

    This allows you to implement an exponential backoff between retry +attempts.

    +

    Let's take an example:

    +

    If we set retry-intervalto 1000 ms and we set +retry-interval-multiplier to 2.0, then, if the first reconnect +attempt fails, we will wait 1000 ms then 2000 ms then 4000 ms +between subsequent reconnection attempts.

    +

    The default value is 1.0 meaning each reconnect attempt is spaced +at equal intervals.

    +
  • +
  • initial-connect-attempts. This optional parameter determines the +total number of initial connect attempts the bridge will make before +giving up and shutting down. A value of -1 signifies an unlimited +number of attempts. The default value is -1.

    +
  • +
  • reconnect-attempts. This optional parameter determines the total +number of reconnect attempts the bridge will make before giving up +and shutting down. A value of -1 signifies an unlimited number of +attempts. The default value is -1.

    +
  • +
  • failover-on-server-shutdown. This optional parameter determines +whether the bridge will attempt to failover onto a backup server (if +specified) when the target server is cleanly shutdown rather than +crashed.

    +

    The bridge connector can specify both a live and a backup server, if +it specifies a backup server and this parameter is set to true +then if the target server is cleanly shutdown the bridge +connection will attempt to failover onto its backup. If the bridge +connector has no backup server configured then this parameter has no +effect.

    +

    Sometimes you want a bridge configured with a live and a backup +target server, but you don't want to failover to the backup if the +live server is simply taken down temporarily for maintenance, this +is when this parameter comes in handy.

    +

    The default value for this parameter is false.

    +
  • +
  • use-duplicate-detection. This optional parameter determines +whether the bridge will automatically insert a duplicate id property +into each message that it forwards.

    +

    Doing so, allows the target server to perform duplicate detection on +messages it receives from the source server. If the connection fails +or server crashes, then, when the bridge resumes it will resend +unacknowledged messages. This might result in duplicate messages +being sent to the target server. By enabling duplicate detection +allows these duplicates to be screened out and ignored.

    +

    This allows the bridge to provide a once and only once delivery +guarantee without using heavyweight methods such as XA (see Duplicate Detection for +more information).

    +

    The default value for this parameter is true.

    +
  • +
  • confirmation-window-size. This optional parameter determines the +confirmation-window-size to use for the connection used to forward +messages to the target node. This attribute is described in section +Reconnection and Session Reattachment

    +
    +

    Warning

    +

    When using the bridge to forward messages to an address which uses +the BLOCK address-full-policy from a queue which has a +max-size-bytes set it's important that +confirmation-window-size is less than or equal to +max-size-bytes to prevent the flow of messages from ceasing.

    +
    +
  • +
  • producer-window-size. This optional parameter determines the +producer flow control through the bridge. You usually leave this off +unless you are dealing with huge large messages.

    +

    Default=-1 (disabled)

    +
  • +
  • user. This optional parameter determines the user name to use when +creating the bridge connection to the remote server. If it is not +specified the default cluster user specified by cluster-user in +broker.xml will be used.

    +
  • +
  • password. This optional parameter determines the password to use +when creating the bridge connection to the remote server. If it is +not specified the default cluster password specified by +cluster-password in broker.xml will be used.

    +
  • +
  • static-connectors or discovery-group-ref. Pick either of these +options to connect the bridge to the target server.

    +

    The static-connectors is a list of connector-ref elements +pointing to connector elements defined elsewhere. A connector +encapsulates knowledge of what transport to use (TCP, SSL, HTTP etc) +as well as the server connection parameters (host, port etc). For +more information about what connectors are and how to configure +them, please see Configuring the Transport.

    +

    The discovery-group-ref element has one attribute - +discovery-group-name. This attribute points to a discovery-group +defined elsewhere. For more information about what discovery-groups +are and how to configure them, please see Discovery Groups.

    +
  • +
+ + +
+ +
+
+
+ +

results matching ""

+
    + +
    +
    + +

    No results matching ""

    + +
    +
    +
    + +
    +
    + +
    + + + + + + + + + + + + + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Added: websites/production/activemq/content/artemis/docs/latest/critical-analysis.html ============================================================================== --- websites/production/activemq/content/artemis/docs/latest/critical-analysis.html (added) +++ websites/production/activemq/content/artemis/docs/latest/critical-analysis.html Thu Sep 14 19:48:11 2017 @@ -0,0 +1,1147 @@ + + + + + Detecting Broker Issues (Critical Analysis) · ActiveMQ Artemis Documentation + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    +
    + + + + + + + + +
    + +
    + +
    + + + + + + + + +
    +
    + +
    +
    + +
    + +

    Critical Analysis of the broker

    +

    There are a few things that can go wrong on a production environment:

    +
      +
    • Bugs, for more than we try they still happen! We always try to correct them, but that's the only constant in software development.
    • +
    • IO Errors, disks and hardware can go bad
    • +
    • Memory issues, the CPU can go crazy by another process
    • +
    +

    For cases like this, we added a protection to the broker to shut itself down when bad things happen.

    +

    This is a feature I hope you won't need it, think it as a safeguard:

    +

    We measure time response in places like:

    +
      +
    • Queue delivery (add to the queue)
    • +
    • Journal storage
    • +
    • Paging operations
    • +
    +

    If the response time goes beyond a configured timeout, the broker is considered unstable and an action will be taken to either shutdown the broker or halt the VM.

    +

    You can use these following configuration options on broker.xml to configure how the critical analysis is performed.

    + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameDescription
    critical-analyzerEnable or disable the critical analysis (default true)
    critical-analyzer-timeoutTimeout used to do the critical analysis (default 120000 milliseconds)
    critical-analyzer-check-periodTime used to check the response times (default half of critical-analyzer-timeout)
    critical-analyzer-policyShould the server log, be halted or shutdown upon failures (default LOG)
    +

    The default for critical-analyzer-policy is LOG, however the generated broker.xml will have it set to HALT. That is because we cannot halt the VM if you are embedding ActiveMQ Artemis into an application server or on a multi tenant environment.

    +

    The broker on the distribution will then have it set to HALT, but if you use it in any other way the default will be LOG.

    +

    What would you expect

    +
      +
    • You will see some logs
    • +
    +

    If you have critical-analyzer-policy=HALT

    +
    [Artemis Critical Analyzer] 18:10:00,831 ERROR [org.apache.activemq.artemis.core.server] AMQ224079: The process for the virtual machine will be killed, as component org.apache.activemq.artemis.tests.integration.critical.CriticalSimpleTest$2@5af97850 is not responsive
    +

    While if you have critical-analyzer-policy=SHUTDOWN

    +
    [Artemis Critical Analyzer] 18:07:53,475 ERROR [org.apache.activemq.artemis.core.server] AMQ224080: The server process will now be stopped, as component org.apache.activemq.artemis.tests.integration.critical.CriticalSimpleTest$2@5af97850 is not responsive
    +

    Or if you have critical-analyzer-policy=LOG

    +
    [Artemis Critical Analyzer] 18:11:52,145 WARN [org.apache.activemq.artemis.core.server] AMQ224081: The component org.apache.activemq.artemis.tests.integration.critical.CriticalSimpleTest$2@5af97850 is not responsive
    +

    You will see a simple thread dump of the server

    +
    [Artemis Critical Analyzer] 18:10:00,836 WARN  [org.apache.activemq.artemis.core.server] AMQ222199: Thread dump: AMQ119001: Generating thread dump
    +*******************************************************************************
    +===============================================================================
    +AMQ119002: Thread Thread[Thread-1 (ActiveMQ-scheduled-threads),5,main] name = Thread-1 (ActiveMQ-scheduled-threads) id = 19 group = java.lang.ThreadGroup[name=main,maxpri=10]
    +
    +sun.misc.Unsafe.park(Native Method)
    +java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    +java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
    +java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
    +java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
    +java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
    +java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
    +java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    +java.lang.Thread.run(Thread.java:745)
    +===============================================================================
    +
    +
    +..... blablablablaba ..........
    +
    +
    +===============================================================================
    +AMQ119003: End Thread dump
    +*******************************************************************************
    +
      +
    • The Server will be halted if configured to HALT

      +
    • +
    • The system will be stopped if SHUTDOWN is used:

      +
    • +
    • Notice that if the system is not behaving well, there is no guarantees the stop will work.
    • +
    + + +
    + +
    +
    +
    + +

    results matching ""

    +
      + +
      +
      + +

      No results matching ""

      + +
      +
      +
      + +
      +
      + +
      + + + + + + + + + + + + + + +
      + + +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Added: websites/production/activemq/content/artemis/docs/latest/diagrams/architecture-diagrams.odg ============================================================================== Binary file - no diff available. Propchange: websites/production/activemq/content/artemis/docs/latest/diagrams/architecture-diagrams.odg ------------------------------------------------------------------------------ svn:mime-type = application/octet-stream Added: websites/production/activemq/content/artemis/docs/latest/diagrams/ha-colocated.odg ============================================================================== Binary file - no diff available. Propchange: websites/production/activemq/content/artemis/docs/latest/diagrams/ha-colocated.odg ------------------------------------------------------------------------------ svn:mime-type = application/octet-stream Added: websites/production/activemq/content/artemis/docs/latest/diagrams/ha-replicated-store.odg ============================================================================== Binary file - no diff available. Propchange: websites/production/activemq/content/artemis/docs/latest/diagrams/ha-replicated-store.odg ------------------------------------------------------------------------------ svn:mime-type = application/octet-stream Added: websites/production/activemq/content/artemis/docs/latest/diagrams/ha-scaledown.odg ============================================================================== Binary file - no diff available. Propchange: websites/production/activemq/content/artemis/docs/latest/diagrams/ha-scaledown.odg ------------------------------------------------------------------------------ svn:mime-type = application/octet-stream Added: websites/production/activemq/content/artemis/docs/latest/diagrams/ha-shared-store.odg ============================================================================== Binary file - no diff available. Propchange: websites/production/activemq/content/artemis/docs/latest/diagrams/ha-shared-store.odg ------------------------------------------------------------------------------ svn:mime-type = application/octet-stream