开发者

javax.jms.JMSSecurityException: MQJMS2008: failed to open MQ queue

开发者 https://www.devze.com 2023-02-24 20:16 出处:网络
I have a JMS-based application that I am running in on Websphere 6.0, and am migrating to Websphere 7.Both Websphere servers are backed with a Websphere MQ 6.0 server.I receive the following exception

I have a JMS-based application that I am running in on Websphere 6.0, and am migrating to Websphere 7. Both Websphere servers are backed with a Websphere MQ 6.0 server. I receive the following exception when attempting to deploy a test servlet to the Websphere 7 server:

javax.jms.JMSSecurityException: MQJMS2008: failed to open MQ queue

Websphere 6.0 : RHEL 5.3

Websphere 7.0.0.15: RHEL 5.3

Websphere MQ 6.0: Windows Server 2003

Servlet Test Code:

public class JMSTestServlet extends HttpServlet {
    private static final long serialVersionUID = 1L;

    /**
     * @see HttpServlet#HttpServlet()
     */
        String MQConnectionFactory, MQQueue; 

    public JMSTestServlet() {
        super();
        // TODO Auto-generated constructor stub
        System.out.println("JMSTestServlet: loading");

        URL urlProps = getClass().getClassLoader().getResource("META-INF/startup.properties");
        Properties props = new Properties();
        try
                {
          System.out.println("JMSTestServlet: loading properties");
          props.load( urlProps.openStream() );

                    MQConnectionFactory = props.getProperty("MQConnectionFactory"); 
                    MQQueue = props.getProperty("MQQueue"); 

          System.out.println("JMSTestServlet: loading properties ... done!");

          sendMessage("ABCDEFGHIJKLMNOPQRSTUVWXYZ");
                } catch (IOException e)
                {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
    }

    protected void sendMessage(String messageString) { 
        QueueConnectionFactory fact;
        QueueConnection qConn = null;
        try { 
            System.out.println("JMSTestServlet: creating context");
            Context ctx = new InitialContext();
            fact = (QueueConnectionFactory)ctx.lookup(MQConnectionFactory);
            Destination destination = (Destination)ctx.lookup(MQQueue);

            System.out.println("JMSTestServlet: creating QueueConnection");
            qConn = fact.createQueueConnection(); 
            QueueSession    qSess = qConn.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
            MessageProducer prod = qSess.createProducer(destination); 


            System.out.println("JMSTestServlet: sending Message");
            TextMessage message = qSess.createTextMessage();
            message.setText(messageString);
            prod.send(message); 

            System.out.println("JMSTestServlet: done sendMessage()");
        } catch ( JMSException ex ) {
            ex.toString(); 
            ex.printStackTrace();
            ex.getLinkedException().toString();
            ex.getLinkedException().printStackTrace();
        } catch ( NamingException ex ) {
            System.out.println("JMSTestServlet: naming exception " + ex.toString());
            ex.printStackTrace();
        } catch ( Exception ex ) {
          System.out.println("JNDI API lookup failed: " +         ex.toString());
            ex.printStackTrace();           
        } finally {
            System.out.println("JMSTestServlet: cleaning up sendMessage()");

            try
            {
                if ( qConn != null ) qConn.close();
            } catch (JMSException e)
            {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
        }
    }

    /**
     * @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response)
     */
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        try { 
            String messageString = request.getParameter("message"); 
            sendMessage(messageString);
        } finally {
        }
    }

Properties file is:

MQConnectionFactory=jms/QUEUECONNFACTORY
MQQueue=jms/QUEUE 

When deployed to Websphere 6 I get messages in my remote queues. When I deploy to Websphere 7, I get:

[4/13/11 14:53:55:622 EDT] 0000005c ConnectionEve A   J2CA0056I: The Connection Manager received a fatal connection error from the Resource Adapter for resource JMS$QUEUECONNFACTORY$JMSManagedConnection@15. The exception is: javax.jms.JMSSecurityException: MQJMS2008: failed to open MQ queue 'QUEUE'.
[4/13/11 14:53:55:622 EDT] 0000005c ConnectionEve W   J2CA0206W: A connection error occurred.  To help determine the problem, enable the Diagnose Connection Usage option on the Connection Factory or Data Source.
[4/13/11 14:53:55:623 EDT] 0000005c ConnectionEve A   J2CA0056I: The Connection Manager received a fatal connection error from the Resource Adapter for resource jms/QUEUECONNFACTORY. The exception is: javax.jms.JMSSecurityException: MQJMS2008: failed to open MQ queue 'QUEUE'.
[4/13/11 14:53:55:625 EDT] 0000005c SystemErr     R   javax.jms.JMSSecurityException: MQJMS2008: failed to open MQ queue 'QUEUE'.

I'm pretty sure I've configured the queues and connection factories on both Websphere servers the same. I'm at a loss as to how to resolve this issue, and the Google is of no help.

Update 2011-04-15:

I've extracted the following error from the logs:

com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2035'

I've read up on it at a few locations, and I really can't see where there's a difference between WAS 6 and WAS 7 to cause this issue.

I'm running Websphere on both Linux hosts as root. I have a root account created on the Window开发者_JAVA技巧s machine with full permissions to the MQ installation:

setmqaut -t qmgr -m QM_webspheremq -p root +all


I'll take a shot at answering this old post since it has been "Bumped by Community user" every four months since January 2019.


First some background:

  • WAS 6.0

    • Included MQ jar files from Websphere MQ v5.3
    • Depending on the specific version of WAS 6.0, the jars would be from Websphere MQ v5.3 CSD08 up to CSD14
  • WAS 7.0.0.15

    • Is supposed to include WebSphere MQ JCA resource adapter Version 7.0.1.3 (the default behavior here would have been that of the MQ v5.3 jars), but because of a bug, if you upgraded from WAS 7.0.0.0 to WAS 7.0.0.15, the WebSphere MQ JCA resource adapter Version 7.0.0.0 which came with WAS 7.0.0.0 would stay in place.

The difference:

  • With MQ v5.3 jar files, when you call fact.createQueueConnection();, a blank userid would be sent to the queue manager. If the SVRCONN channel you connected to had a blank MCAUSER attribute then the connection would be running under the authority of the user account the Windows MQ queue manager was running as. In other words you would get full authority to the the queue manager and all queues (full MQ admin authority).

  • With MQ v7.0.0.0 resource adapter, when you call fact.createQueueConnection(); the JVM process ID will be sent to the queue manager. If the SVRCONN channel you connect to had a blank MCAUSER attribute then the Windows MQ queue manager would attempt to run the connection under the authority of the JVM process ID. Based on the information in your question this would be the user root.


Summary:

It worked under Websphere 6.0 because the connection runs with full MQ Admin authority.

It failed under Websphere 7.0.0.15 because the connection runs with root user authority, and in this case you only provided the root user with all authority to the queue manager (qmgr) itself, but no authority to the QUEUE.

Websphere must first connect to and inquire the queue manager object before it would open any queues. The error you got was javax.jms.JMSSecurityException: MQJMS2008: failed to open MQ queue 'QUEUE'.. This means that you did successfully connect to the queue manager, but then failed to connect to the queue.

This could have been fixed by providing authority for the QUEUE to the root user:

setmqaut -t q -m QM_webspheremq -n QUEUE -p root +put +get +browse +inq +dsp


Note all of the versions of software listed in the question are now (8.5 years later) out of support from IBM. It would also not be advisable to have a SVRCONN channel with a blank MCAUSER unless you were using some other method such as a security exit to set the MCAUSER to a non-MQ Admin id. In current IBM MQ versions you can use TLS with a client cert mapped on the queue manager to a non-MQ Admin id, or TLS without a cert + connection authentication to validate a user id and password sent by the client at the queue manager.


I was getting the same error too. Check your port,queuemanager and queue details.For me it was the channel which was not correct.

For other users: When you have MQJMS2008, you have no permissions to manipulate that queue, you must get a nested Exception that gives you more information about your error, and it tells you a MQRC Reason Code and Termination Code.

For more info about the Reason Code, open a CMD and type mqrc

Analiyzing your error, looks you are permitted to access that queue, i have some questions:

Are you connecting using JNDI? If you are connecting with a class that makes PTP connecting (i mean not using JNDI), you must provide the MQQueueConnectionFactory the channel, the queue manager, the queue name, and the hostname of the server, if you wanna know more about PTP connections, here is: http://hursleyonwmq.wordpress.com/2007/05/29/simplest-sample-applications-using-websphere-mq-jms/ .

If you are doing this with a remote queue and you are using MQSeries and not WMQ on Windows, you must grant to public all privilegies. Use WRKMQMQ.

If you can give the nested exception, i will help you.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号