Your version of Eclipse is 64-bit, based on the paths and filenames.
However, the version of Java that it's picking up is 32-bit, as indicated by where it is coming from, on this line:
-vm C:\Program Files (x86)\Java\jre7\bin\javaw.exe
Program Files (x86) is the folder where 64-bit Windows places 32-bit programs.
Program Files is the folder where 64-bit Windows places 64-bit programs.
This can happen when a system has more than one JVM installed, as is often the case on Windows 64-bit (for example, the JRE download page uses the bit-ness of the browser to determine what bit-ness download to offer you, and many people use(d) 32-bit browsers even though they run 64-bit Windows).
The best way to fix this, assuming you do in fact have 64-bit JRE or JDK on your system, is to specify in eclipse.ini exactly which JVM you want it to use. The instructions are detailed in the Eclipse wiki page, but basically you have to specify the -vm option in the ini file - make sure to read the wiki page carefully as the format is very specific.
Specifying the JVM path in eclipse.ini is strongly recommended because doing so isolates Eclipse from any potential changes to your system PATH that some program installers might make (I'm talking to you, Oracle!).
Another option would be to download and use 32-bit Eclipse instead of 64-bit, but it's still strongly recommended to specify the path to the JVM in eclipse.ini.
Left for historical reference:
To check your version of Java, run
java -version
in a console (command prompt). On Windows 7 with 64-bit Java 6 I get:
java version "1.6.0_27"
Java(TM) SE Runtime Environment (build 1.6.0_27-b07)
Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode)
Note the 3rd line, which shows that this is a 64-bit version.
On a 32-bit version you'll get something like:
Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)
If you are on a 64-bit machine, then you can install the 64-bit JDK and uninstall the 32-bit one. For instance on Windows 10, just go to Settings and under Apps, you will find Java. Click on it and you will find all the different versions. Now you can select which one to uninstall.
As a general rule, the most detail for any security error is provided at the queue manager. The reason for this is that the administrator needs as much information as possible but an attacker should get as little information as possible.
This gives us a great diagnostic tool for this kind of error. When at the client you get a very sparse "security error" with little explanation, look at the queue manager's logs. If they record a detailed error at the same time as your client did, then you know the request made it to MQ and why MQ rejected it.
However, if the QMgr logs do not record the error then you know to concentrate your efforts on the client side.
If this was an authorization error, you would get back a 2035. A 2063 has something to do with security but not authorization. That leaves things like the client cannot find or open its keystore, or the file permissions on the keystore allow world-read. It might be that the client JSSE provider isn't compatible with MQ.
The recommended diagnostic is to use the sample programs that come with MQ to perform verification tests. If these can recreate the problem, it is with configuration or the environment. If they work, then the issue is likely in the code, app server config, or managed objects. Turning on client-side trace should help tremendously, just remember to disable it afterwards,
Best Answer
Although the queue may be set to
DEFSOPT(SHARED), this is only a default. It does not prevent a program from opening it with exclusive use. In particular, transmission queues for non-cluster channels, the command queue and other queues used by MQ system components are opened with exclusive use, regardless of the queue's default setting. Similarly, monitoring programs often open the event queues for exclusive use to ensure that other programs do not compete for messages and result in missed critical events.Is it one of the event or XMit queues? If so, you may not be able to remove the error without stopping the channel or monitoring agent. If it is a user-defined queue, use the DISPLAY QSTATUS command to see which process has it open for exclusive input, then disconnect that process.
Here is an example:
The output of the command will repeat for each process attached to the queue. It shows the executable name (in this case
amqpcseawhich is the command server), the type of open, the process ID and the thread ID. Note that here it showsINPUT(EXCL)indicating that nothing else can open the command queue for browsing or getting of messages.