I'd like to use JMeter test that I can send a message to a JBossMQ (JBoss 4.2.3 JMS Queue). If I get that far then I will be able to build some load and other tests.
JBoss is pretty much straight out of the box and is a server called servername. Since there are some queues set up by default, lets use Queue A which according to ${JBOSS_HOME}/server/default/deploy/jms/jbossmq-destinations-service.xml has the values
<mbean code="org.jboss.mq.server.jmx.Queue"
name="jboss.mq.destination:service=Queue,name=A">
<depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
</mbean>
JMeter wants to know:
QueueConnectionFactory
JNDIname Request queue
any JMS properties
any JNDI properties
a provider URL
can you please help me fill in the boxes?
You can find the desired values from the JBoss MQ client examples: http://www.jboss.org/community/wiki/QueueExample.
Related
I am working on a small project in which I want to consume the messages from the Jboss JMS Queue using IIB Tool kit. Apologize me that I am a learner in IIB.
The scenario is as below.
The Linux server is where the JBOSS is running and the messages are available in a particular JMS queue. I got IBM Toolkit installed on my laptop/machine and created an application and a flow. I placed the JMSInput from the pallet and got confused on where to configure the connection properties like IP Address, port number, Jboss user, password etc...
The idea is to consume the messages that are available in Linux server using IIB. Request some expert help on how to configure and achieve this requirement.
The jnp based Initial Context Factory seems like not supported in JBOSS 7 anymore. I would use the one described in Remote JNDI Lookup.
I never did an IIB integration with a JMS provider in JBoss, but I did it with a standalone ActiveMQ. There I created a JMSProviders configurable service, where I could configure IP address and port in the jndiBindingsLocation property like this:
mqsicreateconfigurableservice <BROKER> -c JMSProviders -o ActiveMQ \
-n initialContextFactory,jarsURL,jndiBindingsLocation,connectionFactoryName \
-v org.apache.activemq.jndi.ActiveMQInitialContextFactory,c:\Users\daniel\apache-activemq-5.11.1\lib,tcp://localhost:61616,ConnectionFactory
See Securing JMS connections and JNDI lookups how to enter user id and password.
I am trying to connect to Queue Manager using MQ api and I am able to connect to queue manager
MQQueueManager queueManager=new MQQueueManager(qmgrName);
queueManager.accessQueue(qName,MQOO_OUTPUT);
But when I try to connect to the same queue manager using JMS it fails with 2058 code.Not sure if I am missing something with JMS
MQQueueConnectionFactory qcf=new MQQueueConnectionFactory();
qcf.setQueueManager(qmgrName);
qcf.setPort(1414);
qcf.setHostname("localhost");
qcf.createQueueConnection();
You have two or more queue managers on the local host. In your first example you connect in bindings mode so the queue manager is selected by name and you get the right one. In the second example the connection is being made over a client connection and so is received by the QMgr listening on 1414 which is not the one that you intend so the connection is rejected.
Please note that if both QMgrs have a listener on 1414 the connection will succeed or fail depending on which QMgr was started first. Only one can bind to that port so the first one started on it gets to use it. This might lead to what appears to be inconsistent behavior.
Please see Connection modes for IBM MQ classes for JMS which advises "To change the connection options used by the IBM MQ classes for JMS, modify the Connection Factory property CONNOPT." The acceptable values are provided on the page but you almost always want it to set for Standard Bindings (MQCNO_STANDARD_BINDING).
As documented here, MQRC 2058 means an invalid queue manager name or the queue manager name is unknown. But as you mention, bindings mode connection using MQ Base Java is successful, the queue manager name appears valid.
Update:
Sorry, I was mislead by your code and thought you are trying to do client mode connection using JMS. You don't need to set host and port for bindings mode connection.
Since the transport type is not set, default, WMQ_CM_BINDINGS is used. Suggest you to verify the queue manager name.
To connect with "BINDINGS", the queue manager needs to be local. Are you trying to connect to a remote queue manager? If so you would need to connect as "CLIENT". Also, check to be sure the qmgr is listening on the port you specified.
Recently I need to develop JBOSS application which receives IBM MQ Message.
It seems like use wmq.jmsra.rar and Message Driven Bean is a most common solution.
But I'm a little bit uncertain who is responsible of this Resouce.
IBM? or Redhat?
I'd rather develop my own queue connector daemon which read message from IBM MQ and send to JBOSS MDB using JMS.
In this case, I need 2 phase commit, to commit simultaneously both IBM MQ side and JBOSS side. Can I use something like XATransaction on this process? Is there any example on Web if it's possible.
Sorry, I couldn't find any example so far.
Many thanks.
wmq.jmsa.rar is released by IBM. Its found as part of the product. Go with the latest release WMQ 7.5 if possible.
WMQ supports XA transaction. It can participate as a resource manager in a 2 phase transaction coordinated by an external transaction monitor/application server.
Sample programs for Java XA transaction are not found with the installation. (I know I have seen C and Cobol XA samples).
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/index.jsp?topic=%2Fcom.ibm.mq.dev.doc%2Fq023590_.htm
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/index.jsp?topic=%2Fcom.ibm.mq.dev.doc%2Fq031500_.htm
You will require a local qmgr (application should run on the same server as qmgr to connect in bindings mode) or extended transactional client to connect to a remote qmgr using XA transactions.
I need to create a proxy service that will listen from MSMQ (Microsoft Messaging Queue ) .May I know what transport protocol/ adapter should i use to make this possible ?
Is that Oracle Service Bus? You would need an MSMQ adaptor - MSMQ uses it's own transport protocol (plus HTTP/S & RPC). It looks like OSB only has a Websphere MQ adaptor.
I need to implement a TCP server with a web interface included for management.
Basically, the tcp server will be listening to new connections and keeping current ones active while the web interface allow me to see information regarding these connections and to interact with them (e.g. send messages and seeing received ones)...
My concerns resides in the "TCP Server" integration with the web application.
For received messages I could simple use a shared DB, but I need to send messages to the peers connected into the TCP server.
My best bet is currently on JCA. Some research pointed me to a nice sample: http://code.google.com/p/jca-sockets.
The sample uses an Message Driven Bean to deal with messages received over port 9000, acting as an echo server.
I am new in the Java EE 6 world. I trying to figure out why things were done in one way or another in the sample (e.g. why MDB?).
JCA has a fairly complicated spec. So I am trying at first to adapt the sample above to keep the connections active to exchange data. My next step will be adapt it to accept a string over a servlet to forward it to a given peer.
Can someone help me out on this?
Well, first of all, using Java EE with TCP is not the best approach you may use. If you just need a simple TCP service with Web UI you'd better consider using Java SE with some web container attached (undertow works well).
In other hand, if you need your application to integrate into existing Java EE infrastructure your company has, JCA would be the best approach. While it's not designed for such kind of things, JCA is the only EE subsystem liberal enough for that kind of thread management you would need for TCP networking to work.
JCA-Socket you're referring above is not the best example of a JCA app. It uses plain Java's blocking sockets by blocking WorkManager thread, this is not very effective. Things got much better now and we have Java NIO and Netty for highly effective raw networking to work upon. I have a JCA connector for TCP interactions which may provide you a skeleton to build your own. Feel free to extend and contribute.
P.S. About MDB: message-driven bean is the only "legal" JCA approach of asynchronous incoming messages handling. Since TCP is asynchronous, you'll definitely need one in your application for all the things to start working. Outcoming data transfers happen through various ConnectionFactory interfaces you'll inject into your bean. The link above will provide you with a reference ConnectionFactory implementation as well as a simple tester app utilizing both ConnectionFactory and MDB messaging approaches.