Message Queue Products judgement

Hi all,
We are a developer firm in process of a message queue application project which we have no experience. Could anyone give us your experience with SUN/Microsoft Mesasge queue product, your judgement and recomendation etc.
Your opinion is highly appreciated.

While I'm not in a position to compare the Sun ONE
Message Queue product against Microsoft's offering
I would like to point out that the Platform Edition
of Sun ONE Message Queue is free for production use.
The Platform Edition offers a complete, JMS 1.1 compliant
implementation. The Sun ONE Message Queue product is
fairly mature having been on the market for several
years now - just by different names (Java Message Queue,
iPlanet Message Queue for Java, now Sun ONE Message Queue).
Chris

Similar Messages

Where do I find 'MQ Cluster Monitor' and 'Message Queue Universal Client' ?

This video on mq.dev.java.net uses two utilities called the 'MQ Cluster Monitor' and the 'Message Queue Universal Client'. The narrator says that these are 'shipped with the Message Queue product'.
I dont see the utilities in my Open MQ installation. What am I missing ?
- Hemant Bedekar
RedSeal Solutions

Cluster Monitor can be launched by typing these commands -
     cd /MessageQueue/mq/examples/jmx
     java -classpath /MessageQueue/mq/lib/imqjmx.jar:. MQClusterMonitor
Universal Client can be launched by typing these commands -
     cd /MessageQueue/mq/examples/applications/uclient
     java -classpath /MessageQueue/mq/lib/imqjmx.jar:. UniversalClient
- Hemant Bedekar
RedSeal Solutions

Revised product name: "Oracle GlassFish Enterprise Message Queue"

Hello,
the release notes for OpenMQ 4.5 build 16 include a note about a revised product name, "Oracle GlassFish Enterprise Message Queue". Is this planned to be the future product name for the commercial product (the product formerly known as Java System Message Queue), or is this meant to be the name for both versions?
Many thanks in advance,
Michael Justin
Edited by: 801285 on 10.10.2010 01:49

Hi all,
I have finally solved the problem, it seems somehow on my windows home premium I can't run the install script (on H:\ ) from the command line. I manually ran the batch script by double clicking on it, it ran fine and I was finally able to install ORE (server + supported + client) on my laptop. Now the connection -- followed through the manual, created user and granted all the roles. Now that I want to test the connection, I open R console and below are the input and output error message though it seems I can connect to the database:
R>
R> library(ORE)
Loading required package: OREbase
Attaching package: ‘OREbase’
The following object(s) are masked from ‘package:base’:
cbind, data.frame, eval, interaction, order, paste, pmax, pmin, rbind, table
Loading required package: OREstats
Loading required package: MASS
Loading required package: OREgraphics
Loading required package: OREeda
Loading required package: OREdm
Loading required package: lattice
Loading required package: OREpredict
Loading required package: ORExml
R>
R>
R>
R> ore.connect(user = 'scott', sid = 'sinha', host = 'win7', password = 'tiger', port = 1521, all = T)
Error in .oci.GetQuery(conn, statement, data = data, prefetch = prefetch, :
ORA-06520: PL/SQL: Error loading external library
ORA-06522: Unable to load DLL
ORA-06512: at "RQSYS.RQEVALIMPL", line 17
ORA-06512: at "RQSYS.RQEVALIMPL", line 14
ORA-06512: at line 4
R>
R>
R> ore.is.connected()
[1] TRUE
R> I get the exact same error when I try to use even the ORE user "rquser". Any suggestion how to resolve this error?
Thanks,
Sourabh

Message Queue Blocking / MSGMNI Setting

Hi All,
Firstly, many thanks to all that can assists. I am currently getting Message Queue
Blocking messages in my ULOG files in my Tuxedo Application. (Tux ver 7.1 in Unix).
I am not sure what is causing this, but started to look into the Tux Config (UBB.MP)
and System message queue setting. Detailed as follows:
1)
Listed below is the system message queue setting:
set msgsys:msginfo_msgmni=2000
set msgsys:msginfo_msgmax=128000
set msgsys:msginfo_msgmnb=100000
set msgsys:msginfo_msgssz=256
set msgsys:msginfo_msgseg=25088
set msgsys:msginfo_msgtql=1550
set msgsys:msginfo_msgmap=1000
According to the BEA site, the MSGMNI is determined by this formula:
MSGMNI = MAXACCESSERS + 7 + (no. of servers with REPLYQ) + (no. MSSQ sets) - (no.
of servers with MSSQ sets)
The following is my current Tux. Config (UBB.MP) is set as :
- MAXACCESSERS = 2300
- Each servers (4 types in total) has its own REPLYQ and RQADDR.
- The same type of servers are set the same across 4 application servers.
Hence, my MSGMNI should be a minimum 2339 (ie. MSGMNI = 2300 + 16 + 16 - 0 = 2339).
But my current MSGMNI is 2000.
Would this contribute to my Message Queue Blocking?
Is my understanding correct and is this something I should change to avoid Message
Queue Blocking? Any helps and advice is much appreciated.

Malcolm,
Your information and explanations behind these error messages are very useful.
It allow me to further understand Tuxedo internal processing and at the same time
give me a chance to start analysing these fields.
I am reluctant to ask further questions at the mean time. I will use your suggestions
as a starting point.
I will certainly keep you posted of the outcome when I have made the changes in
my UBB config and machine parameters.
Many thanks with your help/explanations Malcolm. It helps alot!
Cheers.
David.
"Malcolm Freeman" <[email protected]> wrote:
>
Hi David,
The MSGTQL reference you give (Solution S-00488) refers to the BEA MessageQ
product
and is not relevant to Tuxedo.
The error messages indicate that the queue buildup is probably due to
a restartable
server failing. What happens is this:
When a restartable server fails its IPC queue remains in place and continues
to
receive messages (which will be processed when the server restarts).
Depending
on the time taken to restart, the queue could become full and unable
to receive
any more messages, and this is probably why you got the message CMDTUX_CAT:1380
indicating that the BRIDGE process was unable to put a message on the
server's
queue.
A server is only restarted when the BBL does a SANITYSCAN check. If,
for example,
your SANITYSCAN interval is 300 seconds and your server fails immediately
after
the previous scan, then there will be a delay of almost 5 minutes before
the failure
is detected and the server restarted - plenty of time for the queue to
fill up.
There are a few things you could do:
The key thing would be to find out why the server is failing, and fix
the problem.
If this is not possible immediately, consider some of the other ideas
below.
Have several servers form an MSSQ to service this queue; then if one
fails the
others will continue processing the messages while the failed server
restarts
(this assumes, of course, that your application does not require the
messages
to be processed in strict order through the server).
Reduce the SANITYSCAN interval (but don't make it too small). This would
reduce
the average time taken to restart the server.
Increase the size of the IPC queue (MSGMNB) so that it can hold more
messages.
I'm not sure why you got a LIBTUX_CAT:1485 message, but this could be
due to a
BRIDGE failure as a result of the congestion.
The NETLOAD parameter would reduce the number of messages going to the
remote
machine, but only if the local machine offers the same service. If the
remote
machine is the only source of the service then NETLOAD will have no effect.
I
recommend you do a search of this newsgroup for postings on "load balancing"
there's some good stuff which will explain how load balancing works.
Depending how things go, it might not be a bad idea to open a case with
BEA Support
and ask for guidance (remember to submit your ubbconfig (or preferably
do a tmunloadcf)
together with the complete ULOGs from both the master and the slave machine).
Hope this helps some.
Regards,
Malcolm.
"Dave" <[email protected]> wrote:
Hi Malcolm,
Thank you for your reply. Interesting point you have made about theMSGTQL
value.
Based on your suggestion I went hunting around the BEA site and found
the following
snipplet:
"- The MSGTQL parameter must be set to a value greater than or
equal to the MSGMNI setting."
(http://support.bea.com/application?namespace=askbea&origin=ask_bea_answer.jsp&event=link.view_answer_page_solution&answerpage=solution&page=msq/S-00488.htm)
If the above point is valid, then my MSGTQL is definitely way too low.
IF this
be the case, would you know of a method to work out what my MSGTQL bytes
value
should be?
Additionally, I have looked at other parameters which I could tune,and
would
adding a NETLOAD parameter in the *MACHINES section will reduce remote
servers
call? Which potentially, maybe reduce message queue blocking?
FYI:
The error messages I am seeing in my ULOG file are:
"LIBTUX_CAT: 1477 : ERROR .SysServerDied
LIBTUX_CAT: 1476 : ERROR: .SysServerRestarting"
Which then leads to message queue blocking
"CMDTUX_CAT: 1380 : ERROR: Message queue blocking prevented delivery,
Qaddr=..."
and potentially "LIBTUX_CAT: 1485 .SysNetworkDropped."
Many Thanks. Hope to hear from you (Malcolm) or other parties out there
that can
assists.
Thanks.
David

Message Queue 4.4 doesn't know "jms.properties" ?

Sun JMS Tutorial illustrates using a properties file to supply context properties. You define a System property "jms.properties" to point to the location of the properties file:
java -Djms.properties=%J2EE_HOME%\config\jms_client.propertiesInside of said file is the properties in question (these are a surmise; the contents are nowhere documented).
java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory
java.naming.provider.url=file:///C:/TempThen a call to InitialContext() will succeed.
But the Tutorial assumes you're running under J2EE, and I'm not. I'm using the stand-alone Message Queue 4.4. If I define the properties on the command line,
java -Djava.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory -Djava.naming.provider.url=file:///C:/Tempthen InitialContext() succeeds.
If I explicitly dump the contents of the file into System.properties,
       String
       prop = System.getProperty( "jms.properties" );
       Properties props = System.getProperties();
       try {
           java.io.File pf = new java.io.File( prop );
           props.load( new java.io.FileInputStream(pf) );
       catch( Exception ex ) { ex.printStackTrace(); }Then they get defined and InitialContext() tries to use them. But if I don't then they never get defined. Obviously the Tutorial expects that someone will do that, but who? AFAIK, both environments use the same naming library.
Has the behavior of MQ changed since version 1.3 of the tutorial? Or is J2EE doing something that the standalone product doesn't?

This is all about JNDI configuration. Before you can look up an object in a JNDI repository you need to tell the JNDI runtime which JNDI provider to use. This means you need to set the system properties java.naming.factory.initial and java.naming.provider.url to specify which JNDI provider to use and where the data is located. There's a bit about this in the JNDI tutorial [http://java.sun.com/products/jndi/tutorial/basics/prepare/initial.html|http://java.sun.com/products/jndi/tutorial/basics/prepare/initial.html] .
The tutorial you are running uses the simple file-based JNDI provider known as "fscontext" and included in fscontext.jar.
That tutorial seems to be reading the jms.properties property and importing its contents, though I can't see where that is supposed to happen and so am not surprised it doesn't work. jms.properties is not, as far as I can see, a standard property name.
The MQ 4.4 documentation describes how to configure an InitialContext to use fscontext by configuring those properties directly. This would definitely work!
[http://docs.sun.com/app/docs/doc/821-0029/aeqbb?a=view|http://docs.sun.com/app/docs/doc/821-0029/aeqbb?a=view]
Note that your JNDI datastore (which you've defined to be in C:\Temp) will start off empty, so any lookups will fail unless you've inserted connection factories or destinations in there yourself. I see that is covered elsewhere in the JMS tutorial you were following. There's also a simple MQ GUI tool that can do this. [http://docs.sun.com/app/docs/doc/821-0027/aeoaz?a=view|http://docs.sun.com/app/docs/doc/821-0027/aeoaz?a=view]
Finally, if you're simply trying to learn about JMS and MQ you can skip the use of JNDI completely and simply instantiate the underlying connection factories explicitly. This wouldn't be appropriate in a production environment (where it is recommended to store such objects in a central store) but for developmeht purposes would work just fine.
Nigel
http://docs.sun.com/app/docs/doc/821-0029/aeqbb?a=view

Java Message Queue 3.7 Update 2

Hi,
I am looking for an older version of the Java Message Queue Version 3.7 Update 2. I amunable to find thiss on the download site.
Can any one direct me as to where I could get this from?
Thanks,
Ashwin

Hi Ashwin,
I'm afraid this isn't the forum for Java Message Queue. It is the forum for Oracle MessageQ, a different product altogether. I'm not sure which forum covers Java Message Queue.
Regards,
Todd Little
Oracle Tuxedo Chief Architect

NoClassDefFoundError in Java client after Message Queue upgrade

Hi,
I upgraded from version 3.5 SP1 to Message Queue 3 2005Q1.
The Java client I was using from a remote client seems to be throwing a NoClassDefFound error when I use the new imq.jar .
java.lang.NoClassDefFoundError: com/sun/messaging/jmq/Version at com.sun.messaging.jmq.jmsclient.ConnectionImpl.<clinit>(ConnectionImpl.java:83) at com.sun.messaging.BasicConnectionFactory.createConnection(BasicConnectionFactory.java:110)
Any ideas about this ?
Thanks,
Rini

Looks like you've run into a bug where com/sun/messing/jmq/Version.class is missing from imq.jar .
A workaround is to add imqxm.jar to your client CLASSPATH. I've logged bug 6237112 to track this.
http://wwws.sun.com/software/products/message_queue/

LIBTUX_CAT:681Failure ro create message queue

Hi,
We get this error when we start more than 3 Appserver.
(Solaris 8 + Oracle)
Any information would be appreciated. Thanks.
It's my /etc/system file...
set maxusers=80
set shmsys:shminfo_shmmax=8589934590
set shmsys:shminfo_shmmni=100
set shmsys:shminfo_shmseg=15
set semsys:seminfo_semume=500
set semsys:seminfo_semmns=500
set semsys:seminfo_semmnu=500
set semsys:seminfo_semmsl=70
set semsys:seminfo_semmap=500
set semsys:seminfo_semmni=32
set semsys:seminfo_semopm=100
set semsys:seminfo_semvmx=32767
set semsys:seminfo_msgmap=780
set semsys:seminfo_msgmax=4096
set semsys:seminfo_msgmnb=8192
set semsys:seminfo_msgmni=500
set semsys:seminfo_msgssz=8
set semsys:seminfo_msgtql=40
set semsys:seminfo_msgseg=1024

And just to add to $0.02,
Oracle doesn't use message queues, only shared memory and semaphores. Here is the
/etc/system I use on my Solaris 7 system for development work:
* IPC Tunables - Shared memory
* max shared memory segment size (SHMMAX)
set shmsys:shminfo_shmmax=4294967295
* min shared memory segment size (SHMMIN)
set shmsys:shminfo_shmmin=1
* max attached shm segments per process (SHMSEG)
set shmsys:shminfo_shmseg=100
* shared memory identifiers (SHMMNI)
set shmsys:shminfo_shmmni=100
* IPC Tunables - Semaphores
* semaphores in system (SEMMNS)
set semsys:seminfo_semmns=4096
* semaphore identifiers (SEMMNI)
set semsys:seminfo_semmni=128
* entries in semaphore map (SEMMAP)
set semsys:seminfo_semmap=4096
* undo structures in system (SEMMNU)
set semsys:seminfo_semmnu=4096
* max semaphores per id (SEMMSL)
set semsys:seminfo_semmsl=2048
* max operations per semop call (SEMOPM)
set semsys:seminfo_semopm=256
* max undo entries per process (SEMUME)
set semsys:seminfo_semume=1024
* semaphore maximum value (SEMVMX)
set semsys:seminfo_semvmx=32767
* IPC Tunables - Messages - For Tuxedo
* entries in msg map (MSGMAP)
* set msgsys:msginfo_msgmap=2048
* max message size (MSGMAX)
* set msgsys:msginfo_msgmax=262144
* max bytes on queue (MSGMNB)
* set msgsys:msginfo_msgmnb=262144
* message queue identifiers (MSGMNI)
* set msgsys:msginfo_msgmni=1024
* message segment size (MSGSSZ)
* set msgsys:msginfo_msgssz=1024
* system message headers (MSGTQL)
* set msgsys:msginfo_msgtql=2048
* message segments (MSGSEG)
* set msgsys:msginfo_msgseg=2048
* Workstation Settings
* IPC Tunables - Messages - For Tuxedo
* entries in msg map (MSGMAP)
set msgsys:msginfo_msgmap=2048
* max message size (MSGMAX)
set msgsys:msginfo_msgmax=65535
* max bytes on queue (MSGMNB)
set msgsys:msginfo_msgmnb=512000
* message queue identifiers (MSGMNI)
set msgsys:msginfo_msgmni=1024
* message segment size (MSGSSZ)
set msgsys:msginfo_msgssz=1024
* system message headers (MSGTQL)
set msgsys:msginfo_msgtql=2048
* message segments (MSGSEG)
set msgsys:msginfo_msgseg=2048
Mervin Calverley wrote:
Fabrice:
The error implies that msgmni is set too low. msgmni is the total number of message
queues allowed in the system. Getting an error here implies that oracle or some
other process is consuming them.
For Tuxedo Classes we use the listed values as minimum for the kernel parameters
to perform the labs. In these classes the machine is only running Tuxedo. This
means the values are probably lower than those required by a production system or
one hosting Oracle as well as Tuxedo.
Message Queue Parameters:
MSGMAP 800
MSGMAX 32769
MSGMNB 42000
MSGMNI 400
MSGSSZ 64
MSGTQL 400
MSGSEG 2048
Semaphore Parameters:
SEMMAP 800
SEMMNI 800
SEMMNS 800
SEMMNU 800
SEMMSL 800
SEMOPM 64
SEMUME 64
SEMVMX 32769
SEMAEM 16384
Shared Memory Parameters:
SHMMAX 2097152
SHMMIN 1
SHMMNI 100
SHMSEG 64
SHMALL 2048
**Note: Some UNIX kernels do not support all of the above parameters or have additional
parameters not listed.
Hope this helps!
mervin
"Fabrice Poulard" <[email protected]> wrote:
Hi,
We get this error when we start more than 3 Appserver.
(Solaris 8 + Oracle)
Any information would be appreciated. Thanks.
It's my /etc/system file...
set maxusers=80
set shmsys:shminfo_shmmax=8589934590
set shmsys:shminfo_shmmni=100
set shmsys:shminfo_shmseg=15
set semsys:seminfo_semume=500
set semsys:seminfo_semmns=500
set semsys:seminfo_semmnu=500
set semsys:seminfo_semmsl=70
set semsys:seminfo_semmap=500
set semsys:seminfo_semmni=32
set semsys:seminfo_semopm=100
set semsys:seminfo_semvmx=32767
set semsys:seminfo_msgmap=780
set semsys:seminfo_msgmax=4096
set semsys:seminfo_msgmnb=8192
set semsys:seminfo_msgmni=500
set semsys:seminfo_msgssz=8
set semsys:seminfo_msgtql=40
set semsys:seminfo_msgseg=1024
Brian Douglass
Transaction Processing Solutions, Inc.
8555 W. Sahara
Suite 112
Las Vegas, NV 89117
Voice: 702-254-5485
Fax: 702-254-9449
e-mail: [email protected]

CMDTUX_CAT:1380: ERROR: Message queue blocking prevented delivery

Today, I changed a Tuxedo application (server) to the product systems(One master and two slaves). Only a small changes in code. But after a period of running, there are many errors in ULOG:
CMDTUX_CAT:1380: ERROR: Message queue blocking prevented delivery, Qaddr = 583902
And then, the server is died. After restart the server, this will happen again later.
I don't know why this happens? Thx.

Hi Bill,
This is happening because the BRIDGE process received a message from the network and was unable to place the message on the intended IPC queue. This could be because the server handling that message is backed up, or the system IPC resource settings are too low. Please check the recommended actions in:
http://download.oracle.com/docs/cd/E18050_01/tuxedo/docs11gr1/messages/cdtux/cdtux013.html
Regards,
Todd Little
Oracle Tuxedo Chief Architect

HTTP transport and Sun ONE Message Queue

How do I get the HTTP transport to work? The docs don't seem to be correct.

There are a couple of errors in the Sun ONE Message Queue docs that shipped with
the product.
The following are corrections for those errors.
Servlet configuration
Please note the following correction in the Sun ONE Message Queue 2.0
Administration Guide, Appendix B -
The class name of the HTTP Servlet in Step 4 of the "Configuring the Tunnel Servlet"
section is given as:
com.sun.messging.jmq.transport.httptunnel.servlet.HTTPTunnelServlet
The correct class name is :
com.sun.messaging.jmq.transport.httptunnel.servlet.HttpTunnelServlet
Client setup for HTTP support
1.The following connection factory attributes must be specified to use the HTTP
tunnel connection support.
JMQConnectionType :
Set this attribute to "HTTP".
JMQConnectionURL :
Set this attribute to the URL that will be used to connect to the Sun ONE
Message Queue message service (i.e. the URL for the HTTP tunnel servlet).
Note that there is no need to specify the JMQConnectionHandler attribute as
mentioned in the Sun ONE Message Queue 2.0 Administration Guide -
Appendix B.
2.Before running the client application, set the CLASSPATH variable to include
jmqutil.jar in addition to the standard Sun ONE Message Queue jar files.
This file is located at "/opt/SUNWjmq/lib/jmqutil.jar".
If the "jmqutil.jar" file is not included in the CLASSPATH, the client will get a
"java.lang.NoClassDefFoundError" exception for the class
"com/sun/messaging/jmq/util/JMQTimerTask".
3.If you are using an HTTP proxy, set "http.proxyHost" to the proxy server host
name, and "http.proxyPort" to the proxy server port number using the -D
command line option.
An example command line would look like this:
java -classpath
/opt/SUNWjmq/lib/jms.jar:/opt/SUNWjmq/lib/jmq.jar:
/opt/SUNWjmq/lib/jndi.jar:.:/opt/SUNWjmq/lib/jmqutil.jar
-DJMQConnectionType=HTTP
-DJMQConnectionURL=http://webserver:80/imq/servlet ClientApplicaiton

Configure/Access remote Message Queue (Open MQ)

Hi,
I am new to JMS and Message Queue. I have installed Sun's Open Message Queue on my system.I have created ObjectStore and Destination(Queue) and using java program to insert and fetch messages.
Following are the details:
1. Created ObjectStore MyObjectStore with following properties:-
java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory
java.naming.provider.url=file:///c:/tmp
2. Created ConnectionFactory MyConnectionFactory and Destination MyQueue
3. Code to access above queue:
Hashtable env;
    Context     ctx = null;
    env = new Hashtable();
    env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.fscontext.RefFSContextFactory");
    env.put(Context.PROVIDER_URL, "file:///c:/tmp");
    ConnectionFactory cf=(javax.jms.ConnectionFactory) ctx.lookup("MyConnectionFactory");
    Queue queue=(javax.jms.Queue)ctx.lookup("MyQueue");
    Connection connection = cf.createConnection();
    Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
    MessageProducer msgProducer = session.createProducer(queue);
    MessageConsumer msgConsumer = session.createConsumer(queue);
    ....................My problem is that I am able to access Message Queue on local machine only. I don't know how i can configure my MQ to be accessed on network or/and how to look up for MQ from a remote machine in network.
Can anybody help me on this.
Regards
Edited by: Arpit.Purohit on Apr 8, 2009 4:49 AM
Edited by: Arpit.Purohit on Apr 8, 2009 4:49 AM

Arpit,
Yes, this is because you have chosen to use com.sun.jndi.fscontext.RefFSContextFactory as the JNDI provider in which to store your destination and connection factory objects.
The Sun Java System Message Queue 4.3 Administration Guide has a section [File-System Object Stores|http://docs.sun.com/app/docs/doc/820-6740/aeogx?a=view] about this:
+"Message Queue ... supports the use of a directory in the local file system as an object store for administered objects. While this approach is not recommended for production systems, it has the advantage of being very easy to use in development environments. Note, however, that for a directory to be used as a centralized object store for clients deployed across multiple computer nodes, all of those clients must have access to the directory. In addition, any user with access to the directory can use Message Queue administration tools to create and manage administered objects"+
So if you place your JNDI store in a shared directory visible to other machines rather than C:/tmp you will be able to access it from other machines.
The ideal solution is to use an LDAP JNDI provider. See the section [LDAP Server Object Stores|http://docs.sun.com/app/docs/doc/820-6740/aeogw?a=view] in the Administration Guide.
Note that this issue relates to the administered objects used by MQ only. The MQ broker itself will be available from anywhere on the network and the messages themselves will stored in the broker's own message store.
Nigel

Can you talk to WebLogic Message Queues with C/C++

          Just curious, can you talk to message queues in WebLogic with C/C++, or do you jave
          to use the JMS API to get to it?
          We have some existing C/C++ code we need to communicate with and we are considering
          using message queues to do it. We have tried it with MQSeries and it works fine,
          but could we do the same thing with WebLogic. We already have WebLogic in production
          and would like to avoid having to also buy MQSeries just to integrate to the C/C++
          code and messaging is a lot easier than dealing with JNI.
          Any advise would be greatly appreciated!!!


Hi Chuck,
          Here are some options:
          www.codemesh.com provides a C++ JMS wrapper (via JNI), one customer has instead
          recommended "Jace" http://sourceforge.net/projects/jace/
          Alternatively use RMI over IIOP to invoke an EJB that in turn calls JMS (WebLogic
          understands IIOP).
          Alternatively use HTTP/WebServices/SOAP.
          Personally, I think RMI/IIOP is an interesting option, post to the rmi-iiop newsgroup.
          Tom
          Chuck wrote:
          > Just curious, can you talk to message queues in WebLogic with C/C++, or do you jave
          > to use the JMS API to get to it?
          >
          > We have some existing C/C++ code we need to communicate with and we are considering
          > using message queues to do it. We have tried it with MQSeries and it works fine,
          > but could we do the same thing with WebLogic. We already have WebLogic in production
          > and would like to avoid having to also buy MQSeries just to integrate to the C/C++
          > code and messaging is a lot easier than dealing with JNI.
          >
          > Any advise would be greatly appreciated!!!

Message Queue Enterprise Edition

I have Sun One Directory server Service pack 4 installed and configured in a multi-master configuration. I want to install identity sync to sync up with a 2003 server to support windows clients with single point of maintenance for accounts and passwords. The release notes for the identity sync tool 1 2004Q3 SP1 say I need Message Queue Enterprise Edition. I have a bunch of message queue packages already installed and need to know if what I have is enough, or what I need to download (and where) to make this thing work.
I have : SUNWiqdoc, SUNWiqfs, SUNiqjx, SUNWiqr, SUNWiqu, SUNWiquc, SUNWiqum
Thanks
...MJW

Customers who purchased the iPlanet Message Queue for Java version 2.0
Enterprise Edition, or the iPlanet Java Message Queue version 1.1 Business Edition,
who also have a current maintenance contract for this product, are entitled to a free
upgrade. Sun customers should use their normal support channels to request the
upgrade. All corporate customers with Sun Software Support contracts should be
automatically notified of the upgrade via the ProductTracker by SubscribeNet
program. If you haven't, please contact Sun Customer Service online or by phone at
888-786-8111. Parties interested in upgrading will be required to provide
proof-of-purchase. Customers of previous versions of the free Developer Editions, or
customers without a current maintenance contract on this product, can not upgrade
for free, they must buy the Sun ONE Message Queue 3.0 Enterprise Edition product,
or they can download the Sun ONE Message Queue 3.0 Platform Edition product for
free from: http://wwws.sun.com/software/download/download/5275.html

Sun ONE Message Queue 3.0.1 is now available

Sun One Message Queue 3.0.1 is now available. Sun ONE Message Queue 3.0.1
is an implementation of the Java Message Service version 1.1 specification.
It comes in two editions; a free Platform Edition as well as an Enterprise
Edition for full-scale, enterprise deployments.
Noteworthy changes in 3.0.1 (compared to 3.0):
* Substantial performance boost
MQ 3.0.1 provides message delivery throughput up to double that
attained with MQ 3.0, a performance boost that is especially important
under heavy load conditions.
* Certified for use with the Sun ONE Application Server 7.0
MQ 3.0.1 is certified for Sun ONE Application Server 7.0, and is used as
its native JMS provider. MQ has been integrated with the Application
Server, providing JMS messaging support in an Application Server
environment. You can configure the system for an internal MQ message
server managed with Application Server administration tools, or an
external MQ message server requiring MQ administration tools.
* Support for Linux Red Hat 7.2 (JDK 1.4.1)
MQ 3.0.1 is now certified for JDK 1.4.1 on Linux Red Hat 7.2 (and still
supported on Linux Red Hat 7.1).
* Bundled on Solaris
MQ 3.0.1 Platform Edition will be bundled with Solaris 9 Update 2 when
it ships in early 2003.
For more specific details about 3.0.1 please see the product Release Notes
at: http://docs.sun.com/source/816-6454-10/index.html
The two editions of Sun ONE Message Queue 3.0.1 are:
* The Platform Edition provides a free commercial grade JMS implementation,
ideal for small-scale deployments and development environments on various
operating environments.
* The Enterprise Edition delivers maximum scalability and security features
necessary for larger full-scale deployments.
For specific details about the editions see the Administration Guide at:
http://docs.sun.com/source/817-0354-10/overview.html#20864
For more information about the product or to download the current version
please visit:
http://www.sun.com/software/products/message_queue
Receiving feedback from current and potential customers is important to the
product team. If you have questions, thoughts for additional features or
think you have found a bug, we encourage you to send the team feedback.
Please send mail to [email protected]. If appropriate, be sure to
include the product version, information on the platform you are using and
steps to duplicate the problem you are experiencing. If you are interested
in purchasing the product and have a sales related question send mail to
[email protected]
Thank you for your interest in Sun ONE Message Queue!

Customers who purchased the iPlanet Message Queue for Java version 2.0
Enterprise Edition, or the iPlanet Java Message Queue version 1.1 Business Edition,
who also have a current maintenance contract for this product, are entitled to a free
upgrade. Sun customers should use their normal support channels to request the
upgrade. All corporate customers with Sun Software Support contracts should be
automatically notified of the upgrade via the ProductTracker by SubscribeNet
program. If you haven't, please contact Sun Customer Service online or by phone at
888-786-8111. Parties interested in upgrading will be required to provide
proof-of-purchase. Customers of previous versions of the free Developer Editions, or
customers without a current maintenance contract on this product, can not upgrade
for free, they must buy the Sun ONE Message Queue 3.0 Enterprise Edition product,
or they can download the Sun ONE Message Queue 3.0 Platform Edition product for
free from: http://wwws.sun.com/software/download/download/5275.html

Strange, I think - Tuxedo 6.5 message queues have different owner, creator

All -
I realize that version 6.5 is ancient software now, but it's what we're running. I'm also a very inexperienced Tuxedo user, but I have worked with Unix and databases for many years now.
We have the occasional LIBTUX_CAT:476 (lost message)
and LIBTUX_CAT:477 (server died)
errors now, and they've been occurring every few minutes
since last Thursday for no apparent reason. These errors
in the ULOG are accompanied by a restart of the dead
server. Our users, however, complain of massive waits in
their applications, and we can't go on like this in our
production system.
Checking the tuxedo message queues, we see a few lines
like this when doing "ipcs -qa":
T ID KEY MODE OWNER GROUP CREATOR CGROUP <snip>
q 134853 0 --rw-rw-rw- tuxedo admin oraGCMN dba <snip>
I've edited this slightly to eliminate confusion.
My concern is that the OWNER and CREATOR values are different. I've never seen that before. The STIME
and RTIME values for these errant queues (not shown above)
correspond to the "server died" entries in the ULOG, and
this is surely not coincidental.
The queues should be owned and created by the "tuxedo"
user, I think. Our oraGCMN user is an Oracle user
that owns the application server and makes a user-defined
exit to the Tuxedo application. Frankly, I don't see
how this OS user could possibly ever create a tuxedo
queue.
Do you have any suggestions on how I should proceed?

You may want to compare the IDs of these queues against the IDs of all
Tuxedo server and client queues to see if these are Tuxedo queues or if they
are queues used by Oracle or some other application. You can get the IDs of
all Tuxedo queues using the command
tmadmin <<!
verbose
psr
pclt
(It is also possible to get the same information using the MIB if you plan
on doing this frequently and need to parse the output programatically.)
<Tom Gaines> wrote in message news:[email protected]..
All -
I realize that version 6.5 is ancient software now, but it's what we'rerunning. I'm also a very inexperienced Tuxedo user, but I have worked with
Unix and databases for many years now.
>
We have the occasional LIBTUX_CAT:476 (lost message)
and LIBTUX_CAT:477 (server died)
errors now, and they've been occurring every few minutes
since last Thursday for no apparent reason. These errors
in the ULOG are accompanied by a restart of the dead
server. Our users, however, complain of massive waits in
their applications, and we can't go on like this in our
production system.
Checking the tuxedo message queues, we see a few lines
like this when doing "ipcs -qa":
T ID KEY MODE OWNER GROUP CREATOR CGROUP <snip>
q 134853 0 --rw-rw-rw- tuxedo admin oraGCMN dba <snip>
I've edited this slightly to eliminate confusion.
My concern is that the OWNER and CREATOR values are different. I've neverseen that before. The STIME
and RTIME values for these errant queues (not shown above)
correspond to the "server died" entries in the ULOG, and
this is surely not coincidental.
The queues should be owned and created by the "tuxedo"
user, I think. Our oraGCMN user is an Oracle user
that owns the application server and makes a user-defined
exit to the Tuxedo application. Frankly, I don't see
how this OS user could possibly ever create a tuxedo
queue.
Do you have any suggestions on how I should proceed?

Message Queue Products judgement

Similar Messages

Maybe you are looking for