I’m trying to run a sample JMS consumer code under Tomcat 7, which consumes JMS queue running on a remote WebLogic 12. To do so, I’m using the “WebLogic thin client” approach (added wlclient.jar, wljmsclient.jar to my classpath).
Here’s the code snippet:
Hashtable ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
ht.put(Context.PROVIDER_URL, "t3://testjmsserver:8710");
Context cx = new InitialContext(ht);
ConnectionFactory cf = (ConnectionFactory)cx.lookup("jms/TestFactory");
Connection connection = cf.createConnection();
When I’m running it – the discover works fine, but cf.createConnection() call is stuck for a minute, then it throws exception (see full exception dump below).
Note that running the same code under fully-blown WebLogic instead of Tomcat – works just fine.
What am I doing wrong? How can I find the root cause of the exception I’m getting?
Thanks.
OK, here's what's happening:
There are 3 ways to consume WebLogic JMS:
"Full", i.e. running client under fully-blown WebLogic, or using wlfullclient.jar. This is what was working for me before, but that won't work when running under Tomcat
"IIOP" tunneling client, wlclient.jar + wljmsclient.jar, which is what I've been doing here and this is what wasn't working (likely due to firewall/server-config issues around IIOP protocol tunneling).
"T3 thin" client, i.e. running using wlthint3client.jar, which is what I eventually started using and it's working just fine.
I'm really surprised that option #3 is not the default one (and even maybe the only one available), especially considering the fact that Oracle docs say that #3 is the fastest and the best one (e.g. here: http://docs.oracle.com/cd/E17904_01/web.1111/e13717/wlthint3client.htm)
So the bottom line is - if you want to run WebLogic JMS consumer under Tomcat, simply use wlthint3client.jar from the WebLogic "server/lib" folder.
Related
I have come across a strange issue where SSL configuration of embedded jetty is working fine when i use server.join() but is failing when i remove the join code.
I am using WrapperManager from tanuki software to make it as a service which needs something to be returned from the Integer start(String[] args) method and it is not possible as server.join is a blocking call and it wait till the last thread kills.
I am just using regular SSLConnectionFactory like below nothing much is added.
httpsConnector = new ServerConnector(server, new SslConnectionFactory(sslContextFactory, "http/1.1"),
new HttpConnectionFactory(httpsConf));
Any quick help to resolve the issue is really appreciated.
I am able to resolve the issue by creating new HTTPConfiguration object for HTTPS. i was using only one object and have passed http port as part of the new server() construtor which is actually causing the issue.
Now the connector HTTP & HTTPS are working fine without server.join()
Jaxws cxf client hangs after multiple calls to to the same port
I have an jaxws cxf client application running on tomcat7.
I have a very strange problem, after multiple sequential calls to the webservice server, at some point the JaxwsClientProxy hangs and a could not send message error is thrown with a caused by socketexception followed by a connection timeout.
The both connection timeout and the request timeout are already set to 5 minutes. More stranger is that this behavior may vary from machine to machine.
For example on my own computer (Mac) this does not happen and every thing works fine, but on some other machines (Windows) and the production environment (Linux) this issue exist.
I've been banging my head for a week and so far no luck. I am using the following frameworks:
- Spring 2.5
- Jaxws CXF 2.7.11
- Java 1.6.0_45
- Tomcat 7
Could this be JVM bug or something? There are some forums that talk about this issue, but most of them are running on jboss and there solutions did not work for me.
I tried to change Jaxws and cxf versions but no difference. Here's a code demonstration:
GreetingsWebService service = new GreetingsWebService();
GreetingsPort port = serive.getGreetingsPort();
port.call1(); // success
port.call2(); // success
port.call3(); // error
Any advice would be greatly appreciated
I actually solved my problem. The answer is that if you use java 1.6 with jaxws 2.2.x, you need to copy the jaxws-api.jar and jaxb-api.jar in the java endorsed or tomcat endorsed directorties. Also be sure that you generate the object with jaxws 2.2.
If you don't copy the jars in the endoresed, the java will pickup the old jaxws default jar which result in to strange problems. Also try to turnoff the allowJunk as some old server and proxies do not support junk.
I'm connecting to the WebSphere instance from the stand-alone Java app which is quite trivial:
InitialContext initCtx = new InitialContext();
That code was working perfectly in WebSphere 7, but after updating to WebSphere 8.5 I got the following exception:
Caused by: org.omg.CORBA.TRANSIENT: initial and forwarded IOR inaccessible vmcid: IBM minor code: E07 completed: No
at com.ibm.rmi.corba.ClientDelegate.createRequest(ClientDelegate.java:1276)
at com.ibm.CORBA.iiop.ClientDelegate.createRequest(ClientDelegate.java:1457)
at com.ibm.rmi.corba.ClientDelegate.createRequest(ClientDelegate.java:1164)
at com.ibm.CORBA.iiop.ClientDelegate.createRequest(ClientDelegate.java:1423)
at com.ibm.rmi.corba.ClientDelegate.request(ClientDelegate.java:1886)
at com.ibm.CORBA.iiop.ClientDelegate.request(ClientDelegate.java:1379)
at org.omg.CORBA.portable.ObjectImpl._request(ObjectImpl.java:458)
at com.ibm.WsnBootstrap._WsnNameServiceStub.getProperties(_WsnNameServiceStub.java:38)
at com.ibm.ws.naming.util.WsnInitCtxFactory.mergeWsnNSProperties(WsnInitCtxFactory.java:1441)
... 43 more
After research, I've fout out that IBM support page, which said to go to CSIv2 inbound and outbound settings (by me, Admin Console->Security->GlobalSecurity->RMI/IIOP security) and set the transport to SSL-Supported.
However, it didn't change anything. I've tried to change the 'Cleint certificate authentication' to Never, and Transport to TCP/IP for both CSIv2 inbound and outbound, but still without success. The error persisted until I've turned off 'Enable administrative security', which is not an option, because I need to enable 'Application Security' (the application logic depends of that).
How can I make my code working again? Everything was OK on WebSphere 7.
My research on this issue may prove useful to others;
WebSphere 8 changed the default setting of RMI/IIOP SSL security from
'supported' to 'required'. If you want a secure connection you'll need
to get the certs from the server and set Java system properties to files that specify the location of the certs;
com.ibm.CORBA.ConfigURL=file:/opt/IBM/JazzSM/profile/properties/sas.client.props
com.ibm.SSL.ConfigURL=file:/opt/IBM/JazzSM/profile/properties/ssl.client.props
If this doesn't work, you'll need to start debugging by setting the following System properties;
com.ibm.CORBA.Debug=true
com.ibm.CORBA.CommTrace=true
com.ibm.CORBA.Debug.Output=/tmp/corba.log
By studying this log and orb trace logs in the working directory, I found that the client failed to establish an ephemeral TCP connection to the server at "port=0". No mention of SSL in the logs! I wrote a small app to test my code running as a java console app and found that the SSL connection was successful and it worked fine. By diff'ing the logs, I found that only in the good case, the JVM was finding a local file 'orb.properties'. I then found that in my problem case, my test app was using a different JVM and my real app was using a JVM that had no 'orb.properties'. I could resolve the problem in a number of ways .. e.g. by including an orb.properties in my application and injecting the contents as System properties.
In my case switching CSIV inbound to SSL-Supported from SSL-required and restarting the server helped.
The error description
org.omg.CORBA.TRANSIENT: initial and forwarded IOR inaccessible vmcid: IBM minor code: E07
is very vague and happens under many, not directly connected circumstances.
In my case it had nothing to do with RMI/IIOP security settings, but it was a classpath problem. I was still using old version of com.ibm.ws.webservices.thinclient.
Switching to thinclient 8.5.0, as well as setting the launch JRE to standard (Oracle) JVM has fixed the problem.
it is absolutely no problem to connect to a ActiveMQ as standalone client. The only thing you need is to add the activemq-all-5.4.1.jar and there you go...
...
prop.put(Context.SECURITY_AUTHENTICATION , "system");
prop.put(Context.SECURITY_CREDENTIALS,"manager");
prop.put(Context.INITIAL_CONTEXT_FACTORY,"org.apache.activemq.jndi.ActiveMQInitialContextFactory");
prop.put(Context.PROVIDER_URL,"tcp://localhost:61616");
prop.put("connectionFactoryNames", "TopicCF");
prop.put("topic.topic1", "topic1");
InitialContext ctx = new InitialContext(prop);
...
Now you want to connect to Glassfish V3.x and it seems impossible to get the right libraries and classes in order to connect. While it still was possible in Glassfish V2.x I did not succeed yet to get the equivalent of above code running for Glassfish !
...
Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.appserv.naming.S1ASCtxFactory");
properties.put(Context.PROVIDER_URL, "iiop://localhost:3700");
InitialContext context = new InitialContext(properties)
...
Does anyone have an answer on this ? No, I dont want to deploy an enterprise app-client just to read from a Glassfish queue. There are similar threads here, but none guides anywhere.
Thanks for any tips
Sven
This is the complete list of client jars for glassfish 3 :
auto-depends.jar
deployment-common.jar
glassfish-corba-internal-api.jar
internal-api.jar
management-api.jar
bean-validator.jar
dol.jar
glassfish-corba-newtimer.jar
javax.ejb.jar
orb-connector.jar
common-util.jar
ejb-container.jar
glassfish-corba-omgapi.jar
javax.jms.jar
orb-iiop.jar
config-api.jar
ejb.security.jar
glassfish-corba-orb.jar
javax.resource.jar
security.jar
config-types.jar
glassfish-api.jar
glassfish-corba-orbgeneric.jar
javax.servlet.jar
ssl-impl.jar
config.jar
glassfish-corba-asm.jar
glassfish-naming.jar
javax.transaction.jar
transaction-internal-api.jar
connectors-internal-api.jar
glassfish-corba-codegen.jar
gmbal.jar
jta.jar
container-common.jar
glassfish-corba-csiv2-idl.jar
hk2-core.jar
kernel.jar
When connecting to Glassfish V3, there is no need to supply any properties to the InitialContext constructor. You can simply use the no-arg constructor. To specify the server name and port, set the -Dorg.omg.CORBA.ORBInitialHost and -Dorg.omg.CORBA.ORBInitialPort properties on the JVM, respectively.
As for the libraries, all you should need to include is the gf-client.jar file. It can be found at $GLASSFISH_HOME/lib. This jar file will automatically include whatever other libraries are needed.
For more information, please see http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB. Although that document addresses using EJBs in a stand-alone client, the same solutions apply to using JMS.
You can go see the solution I found when encountering quite the same issue : With which maven dependencies can i create a standalone JMS client for Glassfish ?
i am trying to access MQ queues using JMS. i am getting the below
java.lang.UnsatisfiedLinkError: no mqjbnd05 in java.library.path
i am passing
-Djava.library.path="C:\Program Files\IBM\WebSphere MQ\java\lib"
as the VM argument while running the program in eclipse. This issue is discussed quite a lot on the net but with out any conclusion. Has anyone resolved this? TIA.
As I had to deal with this error myself; and it took me a lot of time to find the right answer, I'd like to share it with the next one, who comes along this thread...
Actually the solution to the problem was very simple (at least in my case). It was not related to any CLASSPATH, java.library.path or installation issues.
I simply forgot to switch the MQConnectionFactory into the Client mode.
This has to be done, by simply calling
cf.setTransportType(WMQConstants.WMQ_CM_CLIENT);
or
cf.setTransportType(WMQConstants.WMQ_CM_BINDINGS_THEN_CLIENT);
or any other connection type, that fits your needs.
By default, the ConnectionFactory is in "Binding" mode (WMQ_CM_BINDINGS), which is intended for local server installations, as it is is stated in the IBM Documentation:
To connect to a queue manager in bindings mode, a WebSphere MQ classes for JMS application must run on the same system on which the queue manager is running.
This transport type is the same as the XMSC_WMQ_CONNECTION_MODE (WMQConstants.WMQ_CONNECTION_MODE) property, when using JNDI or the JmsFactoryFactory.
The same should apply to the other ConnectionFactory types: MQQueueConnectionFactory, MQTopicConnectionFactory, MQXAConnectionFactory, MQXAQueueConnectionFactory and MQXATopicConnectionFactory
Check the IMB Knowledge Center for more information about the different connection/binding options:
https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q031720_.htm
https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q030560_.htm
You probably have some older MQ jar files either in your CLASSPATH, in the lib or in the EAR.
Remove them and you should be fine.
You should not put MQ files in your EAR or in the WEB-INF/lib folders. They should be in the classpath of your appserver.
I came across this while connecting using IBM MQ api.
I didn't find this issue to be related to classpath either.
This happened to me when I instantiated MQQueueManager before setting MQEnvironment's hostname and channel.
Just ensure that your code does not do that and that it instantiates the manager after the environment is set. Something like..
MQEnvironment.hostname = "mq hostname";
MQEnvironment.channel = "mq channel";
..more code..
this._queueManager = new MQQueueManager(qManager);
(Observed that it's OK to set MQEnvironment.port after MQQueueManager is initialized, but one would probably initialize everything related to MQEnvironment together)
This can happen if you actually installed MQ Client instead of MQ Server.
IBM has even written a whole help page about it:
WebSphere MQ Client installation missing mqjb*.dll files
Problem(Abstract)
You install the WebSphere MQ Client and notice three dll's are missing from the \Program Files\IBM\WebSphere MQ\Java\lib\ directory.
Symptom
The following dlls appear in the directory on a server install, but are not part of the Java™ client:
03/17/2003 10:59a 19,456 mqjbdf02.dll
03/17/2003 10:59a 57,856 mqjbnd05.dll
03/17/2003 10:59a 36,864 MQXAi02.dll
The subdirectory \jdbc\ appears on the server, but not on the client machine.
03/17/2003 10:59a 61,440 jdbcdb2.dll
03/17/2003 10:59a 61,440 jdbcora.dll
Cause
The files are missing because they are not provided nor needed in a client install.
Resolving the problem
The files are only included in the WebSphere MQ Server product.
Here is an easy recipe: Tell the Java VM to Load the DLL. Is your code similiar, e.g. do you use System.loadLibrary to load mqjbnd05.dll?
If yes - does it work outside eclipse, like starting the application from the command line? If this is the case, you could try starting the whole eclipse IDE with that library path.
And sometimes we have trouble with pathnames that contain spaces. Copy the dll to C:\, put that on the lib path and try again.
Ah, that's the problem, the specified dll is missing. This blog has a solution. Good luck!
In my case when I set the transport type , the error goes away. I was using MQConnectionFactory
mQQueueConnectionFactory.setTransportType( JMSC.MQJMS_TP_CLIENT_MQ_TCPIP);