Bad memory leak in Axis 1.4 - can we upgrade to Axis2?

[Jim Hargrave]

https://issues.apache.org/jira/browse/AXIS-2668

We ran into the problem described in the link above (out of memory
with web services connector). Its sounds like Axis 1.4 is not being
maintained and there is little chance that this bug will be fixed. I
have confirmed that the "org.apache.axis.MessageContext" finalizer
method is the problem. We could remove this method and build our own
version - but I would prefer Axis2.

Jim

[Yves Savourel]

When we switched to Java 1.6 I was hoping to get rid of Axis altogether and use JAXWS/JAXB. So I tried to change the GS connector to do that and I couldn't manage that at the time: the GS XSD had something not supported by wsimport if I recall well. At some point I gave up.

If we get rid of Axis I'd rather use Java 1.6 runtime support rather than a third party library. If it's possible.

-ys

[Chase Tingley]

Oof.  The axis/axis2 situation is something that hounds us (where "us" means GlobalSight) a little bit.  See the relevant bug report here:

    http://globalsight.com/bugs/browse/GS-3

My understanding of the problem is still about what it was when I last posted to that -- it seems like that GS would need to re-implement all of its web service methods to work with axis2.  (If this is wrong, somebody please set me straight.)

Sorry this is causing problems for people.

ct

[Yves Savourel]

Hi Chase,

 

Thanks for retrieving back that issue.

It seems that was with Axis2. So maybe there are other options if we use JAXWS/JAXB.

 

I don’t have an instance of GS accessible. Is there a way to access the GS WSDL without being connected to G? (I’d like to try a few things).

 

...I guess it has to be in the source code somewhere. I’ll look there.

 

Thanks,

-yves

[Chase Tingley]

Hi Yves,

I'll send you the WSDL.

ct

[Yves Savourel]

Thanks for the file Chase.

 

I had to add the schemaLocation attribute for soapenc, but after that I was able to process it with wsimport.

 

Alas I’m block on this now:

 

“rpc/encoded wsdls are not supported in JAXWS 2.0”

 

I’m not an expert at all with Web services, but it seems that type of encoding is a bit old and not supported much anymore. Maybe it’s just a matter of re-writing the WSDL using a different notation, while keeping the same interface? No idea really.

 

Anyway, from that and the Axis2 issue already mentioned, it seems we’re stuck with Axis 1.4...

 

-ys

[Jim Hargrave]

I have found a workaround on our side. Every 1000 queries I call system.gc() - not elegant and it slows down the systwm somewhat - but it works.

What are modern Java-based webservices using these days?  Is JAXWS the defacto standard?

Personally I hate SOAP based services as they are too heavy, hard to debug and slow. 

Jim

[Asgeir Frimannsson]

Not by any means advocating SOAP services, but: I've used Apache CXF in a couple of projects, which has worked quite well for us. It is also the implementation used by default in JBossAS. It is a JaxWS implementation.

http://cxf.apache.org/docs/developing-a-consumer.html

cheers,

asgeir

[Yves]

> Not by any means advocating SOAP services, but: I've used
> Apache CXF in a couple of projects, which has worked quite
> well for us. It is also the implementation used by default in
> JBossAS. It is a JaxWS implementation.
> http://cxf.apache.org/docs/developing-a-consumer.html

Asgeir: Thanks for the pointer.

I've tried its wsdl2java tool with the GS WSDL and got the error
"WSDLToJava Error: Rpc/encoded wsdls are not supported with CXF".
So, like for Axis2, or other WS implementation it seems this RPC/
encoded mode is completely obsolete. Apparently only Axis1 supports
it.

I've looked at the other connectors that currently use Axis:

a) MyMemory: Their WSDL file works at least with CXF and presumably
with the default JaxWS implementation. In addition they have now a
REST interface. We should switch to that. By the way: they have a nice
"How to use MyMemory" page: http://mymemory.translated.net/doc/cat.php.

b) CrossLanguage: That connector is not completely tested and not
distributed. It looks like their WSDL is also ok with JaxWS.

That leaves only GS as depending on Axis-1.

Chase: Any chance to get GS to re-factor the its Web service interface
using REST or a more up-to-date implementation of WSDL?

Cheers,
-ys

[Chase Tingley]

On Sun, Aug 28, 2011 at 4:23 AM, Yves <yves.s...@gmail.com> wrote:

That leaves only GS as depending on Axis-1.

Chase: Any chance to get GS to re-factor the its Web service interface
using REST or a more up-to-date implementation of WSDL?

Hi Yves,

There's been some discussion of a REST API for a while, but we haven't had time to do it -- there are some quirks in the current web service API that would be nice to fix in the new one, but some of that stuff requires deeper changes to make possible.

As I said upthread, I'm not an expert on WSDL, so please somebody correct me if I get this wrong.  My main concern with updating the WSDL implementation is that it seems like it would break existing integrations by requiring people to regenerate the stubs from the new WSDL.  If that's true, it's sort of a showstopper for us, and it would be better to just put the effort into a new API.

ct

[Yves]

> a) MyMemory: Their WSDL file works at least with CXF and presumably
> with the default JaxWS implementation. In addition they have now a
> REST interface. We should switch to that. By the way: they have a nice
> "How to use MyMemory" page:http://mymemory.translated.net/doc/cat.php.

FYI: I've changed the MyMemory TM Connector to use the REST API
instead of SOAP.
So that's one less project with Axis dependency.

-ys

[Yves Savourel]

> ... If that's true, it's sort of a showstopper

> for us, and it would be better to just put the
> effort into a new API.

I'm no expert either, but I'm guessing that changing the service to not use the RPC/encoded mode would indeed require some changes for the clients.

-ys

[Jim Hargrave]

I think I found a workaround for the client out of memory:

*Call*.getMessageContext().getRequestMessage().getSOAPEnvelope().getRecorder().clear();

I think you can execute this method from the stub after each call (or
after a certain number of calls). I am a webservices ignorant so
googling the call above may give more information.

Jim