The problem is exactly the same as described here:
Exception java.util.zip.ZipFile.ensureOpenOrZipException with WAS 7
Following the resolution, I changed my application module to 2.4 and it resolved the issue. I did not changed the path of wsdl as mentioned in the resolution. But once the application module is changed, the webservices.xml file is not getting generated. I need the xml file to be generated.
Anyone having any alternative solution to this problem where I do not need to change the application module?
Regards,
The original question you are referring to has two parts. One is about the ZIPException. Since that exception is triggered deep down in the WebSphere code it is unlikely that you will get a solution for that problem here. You should contact IBM support for that. The other part is about memory issues. From my experience with using JAX-WS services deployed on WebSphere (and using WebSphere in general), I can make two recommendations:
The original question says that the problem occurs "after few deployments". This poins to a class loader leak. A class loader leak is a particular kind of memory leak that prevents the old class loader of an application from being garbage collected after a redeployment or restart of the application (for a more detailed description, see here). This can be caused by the application or the server runtime. Experience shows that WebSphere itself has several issues that cause this type of leaks, and IBM is in general not very efficient in solving these issues. I once compiled a list of known WebSphere issues of this type that I have encountered. It is published here. One can see that basically any more or less complex Java EE application will be affected by this type of issue. Therefore you should be prepared for the fact that when redeploying frequently without restarting the server, it will eventually run out of memory.
Note: In defense of IBM it should be said that other application servers don't necessarily perform better in this area.
There is one particular case where JAX-WS services deployed on WebSphere may consume unexpectedly large amounts of memory. This occurs for services that have been developed using the top-down approach (i.e. starting from the WSDL), but that have #WebService annotations that don't refer to the original WSDL. In that case, WebSphere (quite correctly) believes that they are bottom-up services and generates WSDL and XML Schema documents based on the JAX-WS/JAXB2 annotations. These documents are kept in memory and in some cases (especially for complex services) may be significantly larger than the original WSDL and XML Schema documents. I've once seen an application that was consuming 200MB of heap just for that. To avoid this, make sure that when creating top-down JAX-WS services, you package the original WSDL and XML Schema documents in the application and that the service implementations have #WebService annotations that correctly refer to these documents.
Related
I am trying to incorporate JasperReports into an existing Java web project. After managing to get everything to work I found out that my WAR file had grown to quite a scary filesize (> 25MB) because of all of the dependencies. With some tinkering I managed to bring it down to 16MB.
I would like to avoid this huge amount of dependencies. For reasons of filesize, but also because I am slightly worried about the versions of JasperReport's dependencies. JasperReports seems to depend on older versions of many of its dependencies. I'm afraid that at some point this will cause compatibility problems with the rest of my application.
For the moment I have solved this by deploying a separate WAR file that just generates the reports. The original web app communicates with this new one by using Tomcat's crossContext="true" parameter. The two app's servlets communicate by passing a series of attributes using request.setAttribute(arg). The file size might still be there, but at least it's inside of a WAR that I'll hardly touch.
The actual question should probably be something along the lines of: How can I separate JasperReports (or in fact any other big library) from my web app without using the servlet container's common classloader?
Also: am I being overly cautious here?
I could see in my application that no of loaded classes keeps on increasing as discussed here.
On using yourkit and help from the stack overflow community ,I was able to conclude that the classes getting increased is because of the reflection classes getting dynamically created as listed below:
GeneratedConstructorAccessorXX
GeneratedMethodAccessorXX
GeneratedSerializationConstructorAccessorXX
where XX is some number.
As per my knowledge and what I have come to know after googling, These are kind of runtime proxies used by reflection to access object information which is stored in the memory.These accessors are cached so that they dont have to be regenerated each time. These class objects are singleton per classloader, and hence we have only one instance of a generated accessor per classloader of a given Class.
If this is the case,why I see the increase of loaded classes when I am running the repeat test.
Update*
On further analysis I have observed that increased load is specifically because of
GeneratedSerializationConstructorAccessor.
I will share my findings below and will accept this as answer unless someone else comes with something better.
On further analysis and checking the stacktraces using your kit I was able to see thatGeneratedSerializationConstructorAccessor was getting created when any EJb bean calls was being made.Though it wasnt for every request that new such class was getting created.
Another observation that found was that another application using EJB beans was also deployed on the same jboss server and was part of the test but we were not facing any such issue there.
One difference I could see was that the later application where no such issue was found was using EJB 3.X and where issue was found was having 2.X.
May be it is the legacy version which is creating issue.
It has been identified not a show stopper and its performance will be watched on the production.
I develop applications using a customized version of Tomcat.
There is support for dynamic class loading, which I use a lot in test and development environments, and I'm curious about the impact of using it in production environment also.
By my knowledge, dynamic class loading is not to be used in production due to performance issues, due to the class loader polling classes at each access.
But, this applcation server support configuration of polling frequency for loading new classes.
If I understand it correctly, if I configure the dynamic class loading to poll every reasonably large amount of time (ie. 1hour) I should avoid most adverse performance impacts.
In production, this mechanism would be used in a limited number of ways:
1) emergency patching without user downtime (fixes would be released at the first shutdown)
2) permanent patching of classes of which we do not have the source (legacy third party libs)
Is this a reliable solution?
Thanks
IMHO you should not use the feature for production. Apart from the polling overhead there may be lot of other scenario which would not cause problems in a dev environment
Few things that come to my mind are
Impact on any constants that are inlined during compiletime
Impact on perm space
You lose track of the version you have deployed in production
there can be mistakes like missing a classfile during the patch
Without knowing what "customized Tomcat version" you have it is obviously difficult to tell if you understand it correctly. However yes, if it does what it says on the tin, you will be avoiding most advers effects.
Still for Emergegency Pachting and the like, why would you want to wait up to an hour for the classes to be reloaded when you could just use the Tomcat Manager Application as described below?
If you want to use this feature for Emergency patching or generell patching, I would strongly suggest using Tomcat Manager Application to trigger a reload when requried:
reloadable
Set to true if you want Catalina to monitor classes in
/WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically
reload the web application if a change is detected. This feature is
very useful during application development, but it requires
significant runtime overhead and is not recommended for use on
deployed production applications. That's why the default setting for
this attribute is false. You can use the Manager web application,
however, to trigger reloads of deployed applications on demand.
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
I try to transfer file with Mtom and it is working pretty good until i use SoapHandler to verify client signature. SoapHandler keeps all message and changes it to base64 encoded. So when i try to get huge file, Jvm throws heap size exception. Do you guys know any ways to solve this problem?
The Java JRE comes with a JAX-WS Provider. This provider has what I would consider a bug. If a SoapHandler is added, either by directly getting the HandlerChain or by using a HandlerResolver, the message, which was correctly created using MTOM, is deconstructed and the attachment(s) are placed inline within the SOAP message. If the attachments are large, this can lead to very poor performance or out of memory errors.
The only solution I have found is to use another JAX-WS provider. From testing, Axis2 seems to work perfectly (although it has a huge number of dependencies). Simply placing another provider on the classpath will cause it to be used. Java looks for a file in META-INF/services named javax.xml.ws.spi.Provider. If this file is found, it will use the Provider specified. The main Axis2 jar will include this file to ensure the Axis2 provider is used. Other Providers may also solve this problem.
Because of this automatic Provider detection, you may find your application does or does not have this problem depending on where it is running. For example, if you deploy an application to IBM WebSphere it already has overridden the default Provider and you will not have this issue. Likely other Application Servers also have overridden the default Provider. If you can get ahold of a copy, IBM also provides a very nice jar, com.ibm.jaxws.thinclient_7.0.0.jar, that has Axis2 packaged in it. This can only be used for standalone applications (those not running in WebSphere), but it is very convenient and resolves this issue.
I've seen this problem all over the Web, but still haven't found a clear solution that has worked for me. Here's the issue:
I am trying to create a Web service client in Java. The client needs to be a console app that will be placed on a server and automatically run at a certain time interval. The Web service I am trying to consume was written and is hosted by a third party company. The service was written in ASP.NET. The company in question has several services that we hit. All of them are written in ASP.NET. I have never dealt with these services until 2 days ago when I was tasked with consuming 2 of the services and building an Excel spreadsheet from the data. Before I continue, let me describe my development environment. Some of this is relevant, some is not, but I want to include everything:
Windows 7 Professional 32-bit
NetBeans IDE 6.9.1
Java JDK 1.6.0_17
jre6
Glassfish 3 Open Source Full-Platform Release
All software has had all available updates applied
On to the problem. When I added the first Web Service Client to my console app, I was surprised at how smoothly the process went. Most of my experience writing Web Service apps is in .NET. I was able to import the WSDL and NetBeans generated all classes on the first try. Within 5 minutes, I was able to make my first call to the service and was greeted with the expected response, letting me know that my attempt was successful. I then added the second Web Service Client to the console app using the address to the second WSDL I needed. This is where I ran into a major problem.
Upon importing the WSDL, I was alerted to an error by NetBeans stating:
Web Service Client can not be created by JAXWS:wsimport utility.
Reason: undefined element declaration 's:schema'
After abusing Google for the next hour looking for a solution, I finally decided to apply some trial and error. Looking at the Output window in NetBeans, I could see that it was complaining about 3 specific lines. Once I took a look at the WSDL, I could see that those 3 lines were exactly the same, as follows:
<s:element ref="s:schema" />
These 3 lines were found in random places from the top of the WSDL, down to about half-way through. I removed these lines from the WSDL found in the Web Service References folder, leaving the WSDL in the META-INF folder alone. I then did a refresh on the service reference and much to my surprise, NetBeans parsed the WSDL and generated my classes just as before. Great, right? Well, here's where problem #2 comes into play.
Now that I was able to compile my app with no errors, I had to try to hit the service to see if my hack had worked. It did not. Because of another bug in JAXWS, I have to provide the URL to the WSDL in the constructor when creating a service object. This means that the WSDL I fixed is being ignored and the service is now back to using the WSDL that can not be parsed. When I tried to provide the location of WSDL I edited locally within my project, I was greeted with another compilation error stating that I had a NullPointerException. It said that I needed to initialize the object before using it.
I have researched what seems like an infinite amount of topics on this site looking for and trying any solutions that have been provided. I have also tried solutions from all over the Web, all with no luck. If anyone has any advice for me, any tips, tricks, hacks, please let me know. I'm open to any suggestions at this point.
Thanks in advance for any assistance provided.
One-sided contract changes may lead to problems.
Assuming the s prefix refers to the http://www.w3.org/2001/XMLSchema namespace, it looks like your WSDL references XML schema types. JAX-WS is probably unable to resolve this when generating the JAXB bindings.
You can download the XSD from http://www.w3.org/2001/XMLSchema.html; at a minimum, you'll need XMLSchema.xsd, XMLSchema.dtd and datatypes.dtd. Generating Java types from this may require fiddling with your JAXB binding configuration.
Alternatively, it may be easier to just use dynamic JAX-WS client code. You can use a tool like soapUI to create/test sample XML requests.
If you do decide to edit the WSDL, the generated service code should have a constructor of the form Foo_Service(URL, QName) that allows you to provision the WSDL locally (e.g. from your classpath).
The first thing I'd do is try to open it in one of the tools meant for testing SOAP services, like SoapUI. If you have schema not resolving, that is possible there will be pieces of code that you may need that won't be generated as well. I had that happen recently with a vendor supplied "web service", and after much dissembling they "miraculously" found an alternative set of services that worked fine.
You could also try some of the alternatives to Jax-Ws, like CXF or Axis.