![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a JMS Introduction
Similar a JMS Introduction (20)
Más de Alex Su
Último
Último (20)
JMS Introduction
- 1. JMS Introduction Alex Su 10/12/11
- 4. Basic JMS API Concepts
- 8. The JMS API Programming Model
- 15. Topologies
- 31. Live Demo
- 32. Q & A
Notas del editor
- illustrates the way these parts interact. Administrative tools allow you to bind destinations(D) and connection factories(CF) into a Java Naming and Directory InterfaceTM (JNDI) API namespace. A JMS client can then look up the administered objects in the namespace and then establish a logical connection to the same objects through the JMS provider.
- Separate different clients by selector supports load balance
- supports fail-over
- A " persistent message " is a message that defines the relationship between a "Message Producer" and the "JMS Server". This can be established for both point-to-point and publish/subscribe. This has to do with the guaranteed once only delivery of the message by persisting the message after it has been recieved from the message producer.
- A " durable message " is a message where the JMS server will hold on to a message if the subscriber is temporarily unavaliable. So the durability is defined by the relationship between a "Topc Subscriber" and the "JMS Server". Durability is applicable only to publish/Subscribe paradigm. For this to happen subscribers need to register themselves with a unique " client id ".
- using rollback function for load balance purpose
- http://activemq.apache.org/version-5-topologies.html
- http://activemq.apache.org/amq-message-store.html Backup amq.dir
- http://activemq.apache.org/amq-message-store.html Backup amq.dir
- http://activemq.apache.org/jdbc-support.html
- http://activemq.apache.org/configuring-version-5-transports.html The VM transport allows clients to connect to each other inside the VM without the overhead of the network communication. The connection used is not that of a socket connection but instead uses direct method invocations to enable a high performance embedded messaging system. The first client to use the VM connection will boot an embedded broker. Subsequent connections will attach that the same broker. Once all VM connections to the broker have been closed, the embedded broker will automatically shutdown. The failover transport uses random by default which lets you to load balance clients over a number of brokers. If you would rather connect to a primary first and only connect to a secondary backup broker if the primary is unavailable, turn of randomizing using something like failover:(tcp://primary:61616,tcp://secondary:61616)?randomize=false
- http://activemq.apache.org/pure-master-slave.html http://activemq.apache.org/shared-file-system-master-slave.html http://activemq.apache.org/jdbc-master-slave.html
- http://activemq.apache.org/version-5-performance-tuning.html Async publishing First some background: When an ActiveMQ message producer sends a non-persistent message, its dispatched asynchronously (fire and forget) - but for persistent messages, the publisher will block until it gets a notification that the message has been processed (saved to the store - queued to be dispatched to any active consumers etc) by the broker. messages are dispatched with delivery mode set to be persistent by default (which is required by the JMS spec). So if you are sending messages on a Topic, the publisher will block by default (even if there are no durable subscribers on the topic) until the broker has returned a notification. So if you looking for good performance with topic messages, either set the delivery mode on the publisher to be non-persistent, or set the useAsyncSend property on the ActiveMQ ConnectionFactory to be true . Pre-fetch sizes for Consumers ActiveMQ will push as many messages to the consumer as fast as possible, where they will be queued for processing by an ActiveMQ Session. The maximum number of messages that ActiveMQ will push to a Consumer without the Consumer processing a message is set by the pre-fetch size. You can improve throughput by running ActiveMQ with larger pre-fetch sizes. Pre-fetch sizes are determined by the ActiveMQPrefetchPolicy bean, which is set on the ActiveMQ ConnectionFactory. Straight through Session Consumption By default, a Consumer's session will dispatch messages to the consumer in a separate thread. If you are using Consumers with auto acknowledge, you can increase throughput by passing messages straight through the Session to the Consumer by setting the alwaysSessionAsync property on the ActiveMQ ConnectionFactory to be true
- ActiveMQ optimized : Kaha persistence, async is true, topic : 65532, message prefetch : 2000 http://hi.baidu.com/wuweido/blog/item/1f42e4034d94c2733912bb94.html another performance benchmark http://www.codeproject.com/KB/showcase/PerformanceBenchmarks.aspx
- The number means the message count per second The higher the number, the higher the performance