Why it is not recommended to have full repository queue manager in a cluster as multi-instance?
Recommendation is from the in webcast presentation "Implementation Considerations for Multi-Instance Queue Managers in WebSphere MQ Cluster Environment".
The webcast presentation "Implementation Considerations for Multi-Instance Queue Managers in WebSphere MQ Cluster Environment" referenced was from 2010.
Two limitations that contribute to the recommendation are given earlier in the presentation:
Page 16:
Pre - 7.0.1 repositories will have to have a channel to both machines that Multi-Instance queue manager is using
Stuck messages on SYSTEM.CLUSTER.TRANSMIT.QUEUE
Page 17:
z/OS
CONNAME attribute 48 character limit
Long hostnames may not fit
Given that the last version of MQ prior to 7.0.1 went out of support September 30th 2012, the first limitation above should no longer be a consideration however at the time the presentation was given there was still more than two years of support left for v6.
The second limitation above would only be a concern if you have z/OS (Mainframe) MQ partial repositories connecting to a distributed full repository.
While those two limitations above may not apply to you now, there may be no reason to make them MI since you already have redundancy with the recommended two Full repositories for a cluster.
Related
We have an application that can use only one MQ queue manager to put/get messages, so to get High availability we are using an active/passive cluster with IP & File system sharing between 2 linux servers and veritas service taking care of failing over the resources. While this is a working soulution we are running into multiple issues and being limited to using physical servers over a VM.
I'm looking for a solution that can replace Veritas, something that can be run on VM and takes care of moving filesystem/IP between servers seamlessly.
There is a service in MQ Advanced that can do this but is considerably expensive than base, so not really interested.
Anyone with similar MQ architecture or know a product that can do such failover please share any details.
Thanks!
I am new to Tibco EMS. We are currently using EMS 8 and are looking for a HA/DR option for it. I have heard of using Veritas for this purpose but that might not be our option for now.
So am looking for a open source alternative for veritas. I have also seen a few discussions where people suggested using rdbms/mysql for this but not sure how to do it.
Can someone please put me in the right direction?
For High Availability of EMS there are two modes you could consider. The first mode is called "Unshared State" and means that while two servers act as a fault-tolerant pair, their state (and thus the messages) are not shared between the two. The other mode is called "Shared State" in which the secondary server has access to the state in case the primary server goes down. I've seen both being used for different types of use cases, so you'll have to judge yourself which fits best.
If you want to go with a shared state, you'll have to make sure that both servers can access the state and generally speaking you'll have two options to do so:
Filesystem
Database
For the database option, there are a few databases that are supported by TIBCO. Please refer to the EMS User Guide, page 343 for more details on the supported databases as well as how to set up the data stores.
For the filesystem option, you'll have to make sure that your filesystem (either software or hardware) supports the four main characteristics that EMS needs:
Write Order
Synchronous Write Persistence
Distributed File Locking
Unique Write Ownership
Source: EMS User Guide, page 520
I've seen Veritas being used a lot, though I've also seen people use a clustered file system (like RedHat GFS or Oracle OCFS). Please be aware that depending on which option you choose, you want to properly test your scenarios and potentially reach out to TIBCO Support.
I am trying to understand the persistence model of IBM MQ. I realize that the messages are stored in file based system but is there a way I can store the files in DB. I have come across article that states that the messages can be stored in the DB2 database, but I would like to know if I can store in other databases such as Oracle DB or SQLite or No-SQL Db's.
You may be misinterpreting the article. (A link would be nice.) Early versions of MQ were closely intertwined with IBM's database at the time and much of the product retains traces of that heritage in names, sizes of data structures, and some functional constraints.
However modern MQ's primary use of database is in the coupling facility in support of shared queues, and this is z/OS only. However that's the exception and for the vast majority of MQ versions and platforms you don't have the ability to select the queue persistence mechanism.
Remember that IBM's MQ was never intended to be a queueing front-end database client. MQ was invented to address problems of synchronous communication in which the outage of a single component caused entire systems to fail. The purpose of MQ was so that the application could treat the network as if it was 100% reliable (which was far from the case back in the 1980's). In order to achieve that MQ kept all critical operations local to the host on which it was installed and minimized external dependencies to things that were the most reliable: POSIX IPC and locally-mounted filesystems.
Some more recent message transports, especially JMS providers, give you the option of selecting a persistence store and even allowing it to be remote. Some are barely more than a JMS API over a database client. Though each of these approaches has valid use cases, IBM MQ has retained its focus on ultimate speed and enterprise-grade reliability.
Other IBM products such as the WAS Messaging Engine, MQTT, MQ Light, Sterling and others exist to fill some of the other requirement spaces. As for MQ, no there's no option to pick your persistence store other than the on the z/OS platform where your options are mostly related to the coupling facility.
I was browsing for an open source messaging software and after some good bit of research I came across these three products. I've taken these out for a preliminary test drive, having had them handle messages for queues and topics, and from what I've read all three of these products are good picks for an Open Source messaging solution for most companies. What I was wondering was what are the advantages that these products may have over one another? What I'm particularly interested in is messaging throughput, including persistent messaging throughput, security, scalability, reliability, support, routing capabilities, administrative options such as metrics and monitoring, and generally just how well each program runs in a large business environment.
Check out http://queues.io/
From their site:
The goal is to create a quality list of queues with a collection of articles, blog posts, slides, and videos about them. After reading the linked articles, you should have a good idea about: the pros and cons of each queue, a basic understanding of how the queue works, and what each queue is trying to achieve. Basically, you should have all the information you need to decide which queue will best fit your needs.
'messaging' covers a lot of options - and there must be at least a dozen different types of technologies that could be the right answer - having built many production messaging environments, using a variety of technologies/approaches, having a better understanding your requirements would help.
are you needing subject-based subscriptions? do you need multicast delivery? do you need dynamic subscribers/listeners? would your listeners be requerying for best sources even after finding an acceptable publisher/feed?
do you need guaranteed delivery? delivery confirmation? is you publisher storing any undelivered messages, or do you need the messaging system to do that for you automagically? how often does your feed data go stale - e.g. email-ish alerts can be store-and-forward but real-time pricing data is only valid for a short interval (and then probably needs to go away rather than cause confusion)
how volatile is your network topology? are your subscribers (or publishers) expecting to live at a fixed address? or are they mobile devices? could they appear to you over more complex internetwork topologies requiring registration and possibly imposing routing restrictions? if so any idea the frequency of these topology changes?
do you only need a java interface? are any of your subscribers to be integrated into windows components (like feeds into excel)?
if you're only interested in experience comparing the similar products you named then perhaps you have already thought through these topics.
as to products, in my experience Tibco is still the leader in throughput and scalability, especially in a real-time environment. ibm MQ would be next, especially in a store-and-forward architecture. with both of those products you get a level of support on which you can justify betting a fundamental part of your business systems. there's a reason both of those have been around for a couple of decades.
another often overlooked option is Tuxedo - it provides not only messaging but a proven transactional capability that remains unparalleled. Oracle continue to be committed to this product and, again, the level of support available is second to none.
i love open sourced solutions and am always glad to find production quality software for free - but if you are creating a fundamental part of your business infrastructure then an active community still might not indicate whether a particular voluntary project is the best bet.
my 2c worth. hope it helps.
First, I am no expert in this, but maybe I can give you some thought hints.
ActiveMQ and Qpid are both under the Apache umbrella and are message queues. But Qpid is an implementation of the AMQP specification.
AMQP is a protocol specification, on the wire level, so messages can be exchanged with other AMQP message queues (e.g RabbitMQ).
ActiveMQ and HornetQ are queues that you can use with a JMS API. The Java Message Service is a specification on an API level.
But you have the option to access Qpid via a JMS API, too.
I think performance is a secondary thought. To have an active community is more important.
http://x-aeon.com/wp/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/
Benchmark includes some performance numbers for you to decide, with both persistent and transient results.
Oracle purchased BEA and their WebLogic suite of tools. They still have a competing product in their own 10gAS Application Server. Both are Java EE, enterprise grade, servers. While it make take some time due to maintenance agreements, it would be unusual for them to continue to produce two products within the same architectural space. So...
Will they retire their previous application server in favor of WebLogic?
Is WebLogic the one that will be retired?
How long of a process is this likely to be? Years?
What have they done with PeopleSoft vs. Oracle Applications? Likely the same pattern will be followed.
You can go through a (rather long) PDF strategy briefing from Oracle. The key slide, though, is probably #48. Oracle has put BEA Weblogic on the "Strategic Products" list and the Oracle Application Server on the "Continue and Converge" list. So Oracle has indicated that the Oracle App Server will be going away (in marketing-ese that it will be converged with the BEA products) and that BEA Weblogic is the strategic direction going forward.
As to question 3, I'm sure it'll be at least a few years depending on your definition of "retired".
Yes. They have already announced their position. OC4J/Orion will continue to be supported however the weblogic release is the future of the platform.
In Oracle terms, the product "Oracle Application Server" contains much more than just the J2EE server. One component is the J2EE server, which used to be OC4J. Oracle has announced that their new strategic J2EE server is WebLogic.
There will therefore still be a product called "Oracle Application Server", but from version 11g onwards, the J2EE server will be WebLogic.
Oracle will release a 11g version oc4j, but after that Oracle WebLogic Server (WLS) will be the preferred Java EE server. WLS is much better with clustering and has a lot of JMS / JDBC options.
Yes, that is a fact. Oracle explained it in the product road map earlier in this year. The "new" product is called Oracle Weblogic Server, and that's what all sales men should offer to new customers from now on. The PDF file posted by Justin shows that.
Take a look to Oracle Weblogic 10g :S :S
alt text http://img266.imageshack.us/img266/2200/oracleweblogic10guk4.png
As you say, it would be unusual for them to maintain two products within the same architectural space. I don't know Java application servers, but given the climate of financial markets, and that it would probably take lots of money to maintain two such application servers, I would say it's a foregone conclusion that one of the products will be cut, and sooner rather than later at that (as soon as the cost of settling breach of maintenance contracts falls below what it costs to maintain the outgoing product). As for which one will go, my bet will be on WebLogic because it "wasn't invented here"...