Index content of a message queue

Hi,
Is it possible to index the content of the message queue. Do we use Correlation ID to reference to some messages?

Hi,
Is it possible to index the content of the message
queue. Do we use Correlation ID to reference to some
messages?This would diverge from the principles of the JMS spec. Better to offload your messages into a DB table where you can index, prioritize, etc to a much greater degree than you could in a classic MOM.

Similar Messages

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

Exchange 2010 - PerfMon - Messages Queued for Delivery = 2,147,483,649

Our monitoring system is alerting Messages Queued for Delivery as 2 Billion messages and the value returned by PerfMon > MSExchangeTransport Queues > Messages Queued for Delivery also matches this number during some samples.
I was wondering, what's going on here. When checking queues using Get-Queue cmdlet it doesn't show more than couple of messages in the queue.
How do I get this fixed? This seems to be a known issue from thread http://social.technet.microsoft.com/Forums/en-US/ac121f02-4359-4d18-b86a-9c9c78b320a9/perfmon-messages-queued-for-delivery-2147483764?forum=exchange2010
Any assistance would be greatly appreciated.

Hi ChaituNanl,
Thank you for your question.
By our search, I suggest we update Exchange to Exchange 2010 CU6 or later, because problem also seem to appear to Exchange CU5 or former.
We could download the CU by the following link:
http://social.technet.microsoft.com/wiki/contents/articles/240.exchange-server-and-update-rollups-build-numbers.aspx
Notice: please note the version of Exchange Service Pack
If there are any questions regarding this issue, please be free to let me know.
Best Regard,
Jim

Message Queue vs RFC Queue

Can anyone tell me what's the difference between Message Que and RFC Queue?
Thanks
Mark

Dear,
Connectionless programming involves using a queue to hold user input to another application or server. Here, we may not have a permanent connection to the application or server. Instead you log your input in a queue and the other application or server then takes it from the queue, processes it, and sometimes it may put the result back to the same queue or to a different queue. Unlike UDP, here there is no chance of message or data loss once you log it into queues.
The Connection oriented is different from the aforementioned and talks about any standard database system (DBMS, RDBMS, OODBMS and ORDBMS) available these days. Presumably, I don't think that there should be an explanation required for connection oriented programming. Unlike TCP/IP, there is no chance of data packet loss and it will bring the data packet to the required destination.
In short, message queue is purely connectionless and gives an assurance that it won't lose any data which is in the queue.
Message queue will be used :
a.Storing insignificant information in the message queue while your database server is busy with other real time processing.
b.Process user input which is given by the user after getting supporting information from other source or applications that are not active or ready at this stage.
c.Because of database server outage, you might require keeping user input in the message queue and processing it as and when the database comes online.
d.Exchanging data with a mainframe system like SAP. Personally, the real time communication with SAP is often a problem. In such cases, the SAP system uses message queue for storing and forwarding information where real time communication is not possible at that time.
RFC Queue:
Communication between applications in different systems in the SAP environment includes connections between SAP systems as well as between SAP systems and non-SAP systems. Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. RFC calls a function to be executed in a remote system.
In short, essentially application infrastructure and business requirements determine whether you should use a message queue or not. Personally, I would suggest that itu2019s a good idea to work with a tool for a while so that you can get to the solution in which you should use it.
http://help.sap.com/SAPhelp_nw04/helpdata/en/6f/1bd5b6a85b11d6b28500508b5d5211/content.htm
Regards,
Syed Hussain.

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

MDB read message queue too slow

For some reason only a small number of MDB in the pool are accessing the message queue. The queue is growing rather fast and I wish to know how I can increase the read rate of my MDB's. Should I create another bean type to read the same queue. This does not seem like the ideal solution.
          Thank you
          bea user


The JMS Performance Guide white-paper contains information
          on how to configure an MDB to run more instances concurrently.
          One thing to realize is that the number of instances is limited
          by the size of the thread pool that the MDB is running in.
          You can find a link to the white-paper here:
          http://dev2dev.bea.com/technologies/jms/index.jsp
          Tom
          bea user wrote:
          > For some reason only a small number of MDB in the pool are accessing the message queue. The queue is growing rather fast and I wish to know how I can increase the read rate of my MDB's. Should I create another bean type to read the same queue. This does not seem like the ideal solution.
          >
          > Thank you
          > bea user

PerfMon - Messages Queued for Delivery = 2,147,483,764

Environment - Exchange 2010, DAG 2 X Server 2008 R2.
Hi there, we have noticed that a monitor is reporting there are 2,147,483,764 messages queued for delivery when running this powershell command: get-wmiobject -query "select MessagesQueuedForDelivery from Win32_PerfFormattedData_MSExchangeTransportQueues_MSExchangeTransportQueues"
The value returned by this also matches what we see in the PerfMon > MSExchangeTransport Queues > Messages Queued for Delivery. the number does not increment as messages are sent, in fact it's only showing 2 more today than it was yesterday.
We are wondering just whats going on here, when checking queues in the GUI there are only a couple of messages showing up.
Is this counter just broken? If so how could we fix it?
Thanks for any assistance, regards Peter.

Hi,
According to your description, it seems that the value is the total number of messages that were queued for delivery since server started.
I recommend you refer to the following article:
http://pic.dhe.ibm.com/infocenter/tivihelp/v30r1/index.jsp?topic=%2Fcom.ibm.itmmc.doc%2Fmain_xc85.htm
Messages Queued For Delivery
The number of messages queued to be delivered when sample was taken. The value
format is a 4-byte integer.
Messages Queued For Delivery/sec The rate messages are queued for delivery since the server
was started per second. The value format is a decimal.
Messages Queued For Delivery Total
The total number of messages that were queued for delivery since
server started. The value format is a 4-byte integer.
Hope this helps!
Thanks.
Niko Cheng
TechNet Community Support

Ability of BAM to Monitor XML Message Queues

Hello,
Does BAM have the ability to monitor XML message queues.
Thank you,
Jason

Hi,
You can do this using:
1. Runtime Workbench
The adapters can be checked using Component Montoring>Display ALL button>Adapter Engine--> Communication channel
http://help.sap.com/saphelp_nw04/helpdata/en/25/9c2f3ffed33d67e10000000a114084/content.htm
Or message monitoring
http://help.sap.com/saphelp_nw04/helpdata/en/2f/4e313f8815d036e10000000a114084/content.htm
2. Transaction SXMB_MONI in the ABAP Stack
Regards
Vijaya

Problem with GlassFish and Sun Java System Message Queue

Hi,
I used application server PE.8 and I upgraded to Sun Java System Application Server Platform Edition 9.0 Update 1 Patch 1, and I changed all my CLASSPATH and everything. My system is working fine, but the Sun Java System Message Queue that I used before is still showing the queues and physical queues of the previous application server, not the new one. Do you know if there is way to change that and link it to the new version?
thanks

Use an ESB like ServiceMix to bridge JMS providers
http://servicemix.org/
Or write your own MessageListener to consume from one JMS and publish on another one. Be careful with queues to avoid loosing the ordering - so you probably want to use a single MessageListener per subscription/queue - or to take advantage of Tibco's exclusive queues to ensure ordering is preserved. If ordering doesn't matter then don't worry too much about it and maybe have a pool of consumers to improve throughput
James
http://logicblaze.com/

Ile system or message queue is no longer available

Hi All,
We are using DB2 and AIX. We getting below error message in db2 log file.Please advise on this issue.
2014-08-13-05.09.08.624033+060 I12752832A1291     LEVEL: Error (OS)
PID     : 25756258             TID : 1           PROC : db2fmp (168768) 0
INSTANCE: db2fdf               NODE : 000
APPID   : 10.144.69.239.57155.140801190410
EDUID   : 1                    EDUNAME: db2fmp (168768) 0
FUNCTION: DB2 Common, OSSe, OSSMountListing::getNext, probe:90
MESSAGE : ECF=0x90000034=-1879048140=ECF_FILE_REMOTE_SYSTEM_NOT_ACTIVE
          File is on a remote system and the link to that system is not active
CALLED : OS, -, statvfs
OSERR   : ESTALE (52) "A file, file system or message queue is no longer available."
CALLSTCK: (Static functions may not be resolved correctly, as they are resolved to the nearest symbol)
[0] 0x09000000074F5548 pdOSSeLoggingCallback + 0x34
[1] 0x0900000008F0A6C4 oss_log__FP9OSSLogFacUiN32UlN26iPPc + 0x1C4
[2] 0x0900000008F0AB70 ossLogSysRC + 0x70
[3] 0x0900000008F2EB90 getNext__15OSSMountListingFCPC23OSSMountListingGetParamCP12OSSMountInfo + 0x4B0
[4] 0x09000000020314A4 db2sap_mount_info + 0x3C4
[5] 0x0900000007760EE4 sqloInvokeFnArgs + 0xB4
[6] 0x0900000007760D44 @76@sqlerRunRoutine__FP13sqleInvokerCBPi + 0x168
[7] 0x0900000007760AD0 sqlerDyload + 0x140
[8] 0x090000000774AA40 sqlerFmpListener + 0x154
[9] 0x0000000100001230 main + 0x910
Regards,
Raj

Hi,
I have checked with AIX team filesyetm every thing fine.Please tell me which filesystem caused thi issue.
Reagrds,
Raj

Oracle tuxedo and Oracle tuxedo message queue on top of a virtual machine.

Hi buddies.
how is it going?
A quick question.
So we are going to go live using Oracle Tuxedo 12.1.1.0 with Distinguished Bulletin Board Liaison and Oracle Tuxedo Message Queue 12.1.1.0 on top of a Virtual Machine (VMWARE) running Oracle Linux 6.2. However we want to know if there are any recommendations or mishaps in which we may face ahead by running Oracle Tuxedo on a virtual machine?
I mean, I am wondering if I have to worry about kernel parameters, virtual machine parameters or any other thing from which could mess up everything.
Another question.
Does oracle also provide virtual machines certification where Oracle tuxedo would run on top of ?
Todd Little-Oracle
Maurice G

Hi Bruno,
I'm not sure what you mean with Distinguished Bulletin Board Liaison. I'm guessing you mean a clustered or MP configuration? And is it truly a clustered configuration or just a single machine MP configuration?
Regarding configuration, are you using Tuxedo services as well or just Tuxedo Message Queue? The biggest issue related to OS configuration is around IPC resources. If you do a tmloadcf -c on your UBBCONFIG file, it will help you determine the minimum IPC resources required. In general I suggest configuring significantly more resources than the minimum to allow for future changes and for some of the parameters for heavier loads. In particular IPC message queue parameters are heavily dependent upon load. So make sure the maximum message size and queue size are large enough for your anticipated workload. You can monitor them under load using the ipcs command.
We don't certify virtual machine environment but support them as long as the VM vendor assures compatibility, which obviously VMware and Oracle VM both do.
Regards,
Todd Little
Oracle Tuxedo Chief Architect

App Server Install fails - due to incompatible Message Queue

I had JES 2005 q1 installed in one of the test machines...now I am trying to set up JES 2005q4 on that. I cud install a Web Server on that ut when I tried to set up the App Server it throws up a msg stating that there is an incompatible version of Message Queue installed and hence installation cannot go ahead.
I am not able to find any instance of Message Queu setup....how do I detect and uninstall old versions of Message Queue??
thx
anand

I assume you are talking about appserver install on Solaris. Message Queue on Solaris is a package based install. The easiest way to uninstall the old version of MQ is: "pkginfo -i | grep Message" ---> "pkgrm all MQ packages".

Clearing JAVA Message Queue in PI 7.1

Hi Experts
I am working on a file to File Scenario, and file has been picked up on the sender CC and mesaages have been sent to JAVA queues, But the messages are stuck on the JAVA queues,
Java Queue name: File_http://sap.com/xi/XI/SystemRecv
How can I clear the JAVA message queue in PI 7.1
Thanks
PR

If the messages are on the queue, usually one of the actions must be performed: a) Fix the related scenario and restart the messages or b) Manually cancel the messages. This is also advised on the note below under item "3. Troubleshooting Archiving / Deletion in the Adapter Framework"
[Note 872388 - Troubleshooting Archiving and Deletion in PI|https://service.sap.com/sap/support/notes/872388]
If you are having performance problems, please check if the messages are taking long time in TBDL/Holding status. Let us know if this is the case.

Get/set message Queue ID in PI 7.1 Adapter module

Hello,
I have a special requirment to get and set message Queue ID in PI 7.1 adapter module.
I tried to use the method setConversationID for the Message Class, but this doest seem to available any more.
Any pointers to which class and method can be used.
Thanks in advance
Regards,
Abhishek

Hi, try [setSequenceId|http://help.sap.com/javadocs/pi/pi711sp03/com/sap/engine/interfaces/messaging/api/Message.html#setSequenceId(java.lang.String)]. Maybe you have to use setDeliverySemantics before in order to set EOIO.
regards, Martin

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

Index content of a message queue

Similar Messages

Maybe you are looking for