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.
Related
This is my situation:
Eclipse ide that i use to develop java web apps.
Tomcat from apache.
Tomcat stack from bitnami.
OS Windows 8
If i deploy and debug to the apache tomcat all work without problem.
If i try the same thing with the bitnami stack, i see the exact same output from the console, like it is starting well, but actually it doesn't and it gets to the timeout saying it was unable to start withing 45 seconds.
I tried to increase the timeout but that's not the problem.
In both cases the Server Location is set to Use Tomcat installation, and i added my project to the source, everything else in the server config is default.
I'm not an expert of tomcat and java webapp deploying, and i need to get it working with the bitnami stack.
Any hint will be appreciated.
Ok i solved it, seems more a problem from eclipse.
In the server configuration i noticed the HTTP port was not listed and it was commented in server.xml
Could this be because the bitnami stack uses port 80 instead of 8080?
Anyway setting the port 80 in server.xml solved the problem.
I have tried to install Java EE 7 with updatetool to be able to run Java EE Tutorial examples.
But the installation of updatetool fails. I have tried to start updatetool installation from the command line on my elementary os, then I saw the error when installing updatetool.
Here is an image: http://oi58.tinypic.com/x6iumx.jpg
Error text example 1:
Input/output error: Connection failed for URL http://pkg.oracle.com/javaeesdk/7/native/release/manifest/0/updatetool#2.3.5%2C0-56.2852%3A20111207T211721Z: 503: Service Temporarily Unavailable
Could not download application packages. This could be because:
- a proxy server is needed to access the internet. Please ensure that
the system proxy server settings are correct, or set the 'http_proxy'
environment variable to the full URL of the proxy server.
- the package server or network connection is slow.
If you are getting time out errors you can try setting the
PKG_CLIENT_CONNECT_TIMEOUT and PKG_CLIENT_READ_TIMEOUT
environment variables and try again. For example to increase
the timeouts to 300 seconds set them to 300
- the package server is down or otherwise inaccessible or it is
generating invalid data. Please contact the provider of the package
server.
Error text example 2:
File 138/564 Input/output error: Connection failed for URL http: //pkg.oracle.com/javaeesdk/7/native/release/file/0/217e83782a91f09fa7f35122412cd155263b107f: 502: Proxy Error
Could not download application packages. This could be because:
- a proxy server is needed to access the internet. Please ensure that
the system proxy server settings are correct, or set the 'http_proxy'
environment variable to the full URL of the proxy server.
- the package server or network connection is slow.
If you are getting time out errors you can try setting the
PKG_CLIENT_CONNECT_TIMEOUT and PKG_CLIENT_READ_TIMEOUT
environment variables and try again. For example to increase
the timeouts to 300 seconds set them to 300
- the package server is down or otherwise inaccessible or it is
generating invalid data. Please contact the provider of the package
server.
I don't use any proxy server. Help please!
I had the same - it's because their site is so unbelievably slow.
The output you showed tells you what to do, increase the timeout.
But sometimes it just needs to be run again, which worked in my case.
You can download the tutorial from Oracle Java EE 7 SDK download page.
Just download the latest Java EE 7 SDK, and unzip. The tutorial is inside the glassfish4/docs folder.
I have managed to install updatetool finally, after 3 days.
My advice for everyone who has the same problem:
Try installation several times in the morning, afternoon, evening and at night. And maybe once you will have successful attempt :)
The problem was not on my side.
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.
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);
I've deployed some Managed Beans on WebSphere 6.1 and I've managed to invoke them through a standalone client, but when I try to use the application "jconsole" distributed with the standard JDK can can't make it works.
Has anyone achieved to connect the jconsole with WAS 6.1?
IBM WebSphere 6.1 it's supossed to support JSR 160 JavaTM Management Extensions (JMX) Remote API. Furthermore, it uses the MX4J implementation (http://mx4j.sourceforge.net). But I can't make it works with neither "jconsole" nor "MC4J".
I have the Classpath and the JAVA_HOME correctly setted, so the issue it's not there.
WebSphere's support for JMX is crap. Particularly, if you need to connect to any secured JMX beans. Here's an interesting tidbit, their own implementation of jConsole will not connect to their own JVM. I have had a PMR open with IBM for over a year to fix this issue, and have gotten nothing but the runaround. They clearly don't want to fix this issue.
The only way I have been able to invoke remote secured JMX beans hosted on WebSphere has been to implement a client using the "WebSphere application client". This is basically a stripped down app server used for stuff like this.
Open a PMR with IBM. Perhaps if more people report this issue, they will actually fix it.
Update: You can run your application as a WebSphere Application Client in RAD. Open the run menu, then choose "Run...". In the dialog that opens, towards the bottom on the left hand side, you will see "WebSphere v6.1 Application Client". I'm not sure how to start and Application Client outside of RAD.
IT WORKS !
http://issues.apache.org/jira/browse/GERONIMO-4534;jsessionid=FB20DD5973F01DD2D470FB9A1B45D209?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
1) Change the config.xml and start the server.
-see here how to change config.xml: http://publib.boulder.ibm.com/wasce/V2.1.0/en/working-with-jconsole.html
2) start the jconsole with : jconsole -J-Djavax.net.ssl.keyStore=%GERONIMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.keyStorePassword=secret -J-Djavax.net.ssl.trustStore=%GERONIMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.trustStorePassword=secret -J-Djava.class.path=%JAVA_HOME%\lib\jconsole.jar;%JAVA_HOME%\lib\tools.jar;%GERONIMO_HOME%\repository\org\apache\geronimo\framework\geronimo-kernel\2.1.4\geronimo-kernel-2.1.4.jar
[or your version of geronimo-kernel jar]
3) in the jconsole interface->advanced, input:
JMX URL: service:jmx:rmi:///jndi/rmi://localhost:1099/JMXSecureConnector
user name: system
password: manager
4) click the connect button.
If you want the WebSphere MBeans this one works for me:
The key is to configure the classpath and the security properly.
in one line:
jconsole -J-Dwas.install.root=C:/was61 -J-Djava.ext.dirs=C:/was61/plugins;C:/was61/plugins/com.ibm.ws.security.crypto_6.1.0;C:/was61/lib;C:/was61/java/jre/lib/ext -J-Dcom.ibm.SSL.ConfigURL="file:../../properties/ssl.client.props" -J-Dcom.ibm.CORBA.ConfigURL="file:../../properties/sas.client.props" service:jmx:iiop://host:port/jndi/JMXConnector
where port = bootstrap port ex: (2809)
Be careful when setting the sas and the ssl props.
Robert
I have successfully connected to ActiveMQ and ServiceMix using the JConsole. Does WAS 6.1 use Java Management Extension (JMX) technology? JMX is required for JConsole.
If your path is set correctly it should work fine. On windows you go to System Properties -> Advanced Tab -> Environment Variables. Have your JAVA_HOME System variable set to the path of your JDK or JRE and your Path variable with %JAVA_HOME%/bin added somewhere in there. Then all you need to do is go to Start->Run->JConsole. Select the correct Process Name and your done.
Where are you having problems at? I hope this helps.
Edit:
Here is the Java Doc's on JConsole.
Hmm... I know that WebSphere is kind of hard to configure. Thats part of the reason we used ServiceMix for our ESB. Maybe its not enabled by default in WebSphere and you would have to turn it on in the config somewhere.
Websphere 6.1 does not support the JConsole for some reason even though it fully implements the JMS specs. Seems to be a week area at the moment. Your best bet is to look at the Admin client to implement you own console.
You all seem to be incorrect. I am running Websphere 6.1.041 , using JDK 1.5 , and I just started up Jconsole and used the "simple connect" tab to connect to localhost with port=0 and without a username and password and it works fine.