Subject: RE: RESEND: [xfire-user] SoapEnvelope attachments wh en using MTOM are not cleaned up. - msg#00046

List: java.xfire.user

Date: Prev Next Index Thread: Prev Next Index

It appears that the cause of our dilemma is in the class
"OutMessageDataSource" at

// TODO: its really not necessary to cache this...
CachedOutputStream out = new CachedOutputStream(1024*1000, null);

Perhaps if this was changed such that it used the
ATTACHMENT_MEMORY_THRESHOLD property, we could then set this value in the
services.xml file or programatically....just a suggestion. We also noticed
that we could not delete these files on the server-side until we rebooted
weblogic, which means that there may be an InputStream left open on the file
(just a guess).

We are going to patch a local copy with this change to fix this problem.

thanks for all of your help
-Zack Jones

-----Original Message-----
From: Tomek Sztelak [mailto:tsztelak@xxxxxxxxx]
Sent: Wednesday, October 18, 2006 10:02 AM
To: user@xxxxxxxxxxxxxxxxxx
Subject: Re: [xfire-user] RESEND: [xfire-user] SoapEnvelope attachments
wh en using MTOM are not cleaned up.

Add this to services.xml ( remeber to change handler classname ;)
<outHandlers>
<handler handlerClass="org.codehaus.xfire.util.dom.DOMOutHandler" />
</outHandlers>

On 10/18/06, Jones, Zack (SAIC) <JonesZ@xxxxxxxxxxxxxx> wrote:
> Thatcher,
>
> Thanks for the reply.
>
> The issue I was describing below is a server-side problem, but it is a
> client issue as well. If possible, I would appreciate an example of how to
> add a handler to the OutHandler list on the server-side. In the meantime,
we
> will try to figure out how to do this on our own. Thanks for the help!
>
> -Zack
>
> -----Original Message-----
> From: Chris Thatcher [mailto:chris.thatcher@xxxxxxxxxxxx]
> Sent: Wednesday, October 18, 2006 9:15 AM
> To: user@xxxxxxxxxxxxxxxxxx
> Subject: RE: [xfire-user] RESEND: [xfire-user] SoapEnvelope attachments
> when using MTOM are not cleaned up.
>
>
> Hi Zack,
> I'm not sure if this will help you, but ideally I think this would be best
> managed by writing a handler whose job it is to clean up any attachments
in
> the attachment directory (which can be configured as noted
> http://xfire.codehaus.org/MTOM here). Then just add this handler to your
> clients InHandler list, which should default to the 'user' phase, which
> should be fine. If this doesn't make sense let me know and Ill try to
> create
> a simple example handler that does this.
>
> Thatcher
>
> -----Original Message-----
> From: Jones, Zack (SAIC) [mailto:JonesZ@xxxxxxxxxxxxxx]
> Sent: Wednesday, October 18, 2006 8:11 AM
> To: 'user@xxxxxxxxxxxxxxxxxx'
> Subject: RE: [xfire-user] RESEND: [xfire-user] SoapEnvelope attachments
when
> using MTOM are not cleaned up.
>
>
> Dan,
>
> Thanks for the reply.
>
> We did read that section, and do follow the cleanup procedure for certain
> methods that apply, but here is the dilemma:
>
> If you have a service method like:
>
> public Car[] getAllCars()
>
> and the returned Car array is very large (and possible containing many
> fields), the resulting SOAP Envelope is saved to disk as an attachment
> without our code having any control over it. It would seem that Xfire
> decides
> that the SOAP envelope returned exceeds some threshold, and saves the SOAP
> Evelope as an attachment to disk and does not clean up after its delivered
> to
> the client. I don't see where we can control this behavior in our code.
>
> Is our understanding wrong?, or is this a legitimate problem.
>
> Thanks,
> Zack Jones
>
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@xxxxxxxxxxxxxxxxxx]
> Sent: Wednesday, October 18, 2006 1:08 AM
> To: user@xxxxxxxxxxxxxxxxxx
> Subject: Re: [xfire-user] RESEND: [xfire-user] SoapEnvelope attachments
when
> using MTOM are not cleaned up.
>
>
> Hi Zack,
>
> Did you read the part about cleaning up attachments in the manual?
> http://xfire.codehaus.org/MTOM
> Cheers,
> - Dan
>
> Jones, Zack (SAIC) wrote:
> > If anyone has any insight to this, it would be really appreciated!
> >
> > -----Original Message-----
> > From: Jones, Zack (SAIC) [mailto:JonesZ@xxxxxxxxxxxxxx]
> > Sent: Friday, October 13, 2006 2:40 PM
> > To: 'user@xxxxxxxxxxxxxxxxxx'
> > Subject: [xfire-user] SoapEnvelope attachments when using MTOM are not
> > cleaned up.
> >
> >
> > Hi,
> >
> > We are using Xfire 1.2-RC1 with MTOM enabled. We have an Xfire
> > service
> that
> > returns an array of objects. This objects contain nothing more than
> > simple getters and setters. The array returned can be very large in
> > size.
> >
> > We have noticed that the SOAPEnvelope containing the response is saved
> > as
> an
> > att*.tmp both in the server's local tmp directory and the client's
> > local
> tmp
> > directory. Unforunatley, becuase these files are not cleaned up, they
> > eventually cause the disk space to fill up in the tmp directory.
> >
> > In our services.xml file, we have set MTOM-enabled to true. We are
> > not setting the attachment-threshold or the attachment-dir properties,
> > as they do no seem to make a difference for non DataHandler/Datasource
> attachments.
> >
> > Our question is, is there any way to configure XFire so that it either
> does
> > not create the tmp files, or cleans them up. We noticed that turning
> > off MTOM resolves this issue, but is not an acceptable solution as we
> > require MTOM services.
> >
> > Also, we can remove the client-side tmp files without a problem, but
> > we cannot remove the server-side tmp files unless we shut down the web
> > server (weblogic 9.2). This would suggest that the InputStreams on
> > the
> server-side
> > attachments are not being closed.
> >
> > Any suggestions?
> >
> > -Zack
> >
> >
> > ____________________________
> > http://www.pragmatics.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
> >
> > ____________________________
> > http://www.pragmatics.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com
> http://netzooid.com/blog
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
> ____________________________
> http://www.pragmatics.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
> ____________________________
> http://www.pragmatics.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

--
-----
When one of our products stops working, we'll blame another vendor
within 24 hours.

---------------------------------------------------------------------
To unsubscribe from this list please visit:

http://xircles.codehaus.org/manage_email

____________________________
http://www.pragmatics.com

---------------------------------------------------------------------
To unsubscribe from this list please visit:

http://xircles.codehaus.org/manage_email

Was this page helpful?

Thread at a glance:

Previous Message by Date: click to view message preview

RE: RESEND: [xfire-user] SoapEnvelope attachments wh en using MTOM are not cleaned up.

It appears that the cause of our dilemma (server-side) is in the class -----Original Message----- From: Tomek Sztelak [mailto:tsztelak@xxxxxxxxx] Sent: Wednesday, October 18, 2006 10:02 AM To: user@xxxxxxxxxxxxxxxxxx Subject: Re: [xfire-user] RESEND: [xfire-user] SoapEnvelope attachments wh en using MTOM are not cleaned up. Add this to services.xml ( remeber to change handler classname ;) <outHandlers> <handler handlerClass="org.codehaus.xfire.util.dom.DOMOutHandler" /> </outHandlers> On 10/18/06, Jones, Zack (SAIC) <JonesZ@xxxxxxxxxxxxxx> wrote: > Thatcher, > > Thanks for the reply. > > The issue I was describing below is a server-side problem, but it is a > client issue as well. If possible, I would appreciate an example of how to > add a handler to the OutHandler list on the server-side. In the meantime, we > will try to figure out how to do this on our own. Thanks for the help! > > -Zack > > -----Original Message----- > From: Chris Thatcher [mailto:chris.thatcher@xxxxxxxxxxxx] > Sent: Wednesday, October 18, 2006 9:15 AM > To: user@xxxxxxxxxxxxxxxxxx > Subject: RE: [xfire-user] RESEND: [xfire-user] SoapEnvelope attachments > when using MTOM are not cleaned up. > > > Hi Zack, > I'm not sure if this will help you, but ideally I think this would be best > managed by writing a handler whose job it is to clean up any attachments in > the attachment directory (which can be configured as noted > http://xfire.codehaus.org/MTOM here). Then just add this handler to your > clients InHandler list, which should default to the 'user' phase, which > should be fine. If this doesn't make sense let me know and Ill try to > create > a simple example handler that does this. > > Thatcher > > -----Original Message----- > From: Jones, Zack (SAIC) [mailto:JonesZ@xxxxxxxxxxxxxx] > Sent: Wednesday, October 18, 2006 8:11 AM > To: 'user@xxxxxxxxxxxxxxxxxx' > Subject: RE: [xfire-user] RESEND: [xfire-user] SoapEnvelope attachments when > using MTOM are not cleaned up. > > > Dan, > > Thanks for the reply. > > We did read that section, and do follow the cleanup procedure for certain > methods that apply, but here is the dilemma: > > If you have a service method like: > > public Car[] getAllCars() > > and the returned Car array is very large (and possible containing many > fields), the resulting SOAP Envelope is saved to disk as an attachment > without our code having any control over it. It would seem that Xfire > decides > that the SOAP envelope returned exceeds some threshold, and saves the SOAP > Evelope as an attachment to disk and does not clean up after its delivered > to > the client. I don't see where we can control this behavior in our code. > > Is our understanding wrong?, or is this a legitimate problem. > > Thanks, > Zack Jones > > -----Original Message----- > From: Dan Diephouse [mailto:dan@xxxxxxxxxxxxxxxxxx] > Sent: Wednesday, October 18, 2006 1:08 AM > To: user@xxxxxxxxxxxxxxxxxx > Subject: Re: [xfire-user] RESEND: [xfire-user] SoapEnvelope attachments when > using MTOM are not cleaned up. > > > Hi Zack, > > Did you read the part about cleaning up attachments in the manual? > http://xfire.codehaus.org/MTOM > Cheers, > - Dan > > Jones, Zack (SAIC) wrote: > > If anyone has any insight to this, it would be really appreciated! > > > > -----Original Message----- > > From: Jones, Zack (SAIC) [mailto:JonesZ@xxxxxxxxxxxxxx] > > Sent: Friday, October 13, 2006 2:40 PM > > To: 'user@xxxxxxxxxxxxxxxxxx' > > Subject: [xfire-user] SoapEnvelope attachments when using MTOM are not > > cleaned up. > > > > > > Hi, > > > > We are using Xfire 1.2-RC1 with MTOM enabled. We have an Xfire > > service > that > > returns an array of objects. This objects contain nothing more than > > simple getters and setters. The array returned can be very large in > > size. > > > > We have noticed that the SOAPEnvelope containing the response is saved > > as > an > > att*.tmp both in the server's local tmp directory and the client's > > local > tmp > > directory. Unforunatley, becuase these files are not cleaned up, they > > eventually cause the disk space to fill up in the tmp directory. > > > > In our services.xml file, we have set MTOM-enabled to true. We are > > not setting the attachment-threshold or the attachment-dir properties, > > as they do no seem to make a difference for non DataHandler/Datasource > attachments. > > > > Our question is, is there any way to configure XFire so that it either > does > > not create the tmp files, or cleans them up. We noticed that turning > > off MTOM resolves this issue, but is not an acceptable solution as we > > require MTOM services. > > > > Also, we can remove the client-side tmp files without a problem, but > > we cannot remove the server-side tmp files unless we shut down the web > > server (weblogic 9.2). This would suggest that the InputStreams on > > the > server-side > > attachments are not being closed. > > > > Any suggestions? > > > > -Zack > > > > > > ____________________________ > > http://www.pragmatics.com > > > > --------------------------------------------------------------------- > > To unsubscribe from this list please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > > > ____________________________ > > http://www.pragmatics.com > > > > --------------------------------------------------------------------- > > To unsubscribe from this list please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com > http://netzooid.com/blog > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > > > ____________________________ > http://www.pragmatics.com > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > > > ____________________________ > http://www.pragmatics.com > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > -- ----- When one of our products stops working, we'll blame another vendor within 24 hours. --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email ____________________________ http://www.pragmatics.com --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email

Next Message by Date: click to view message preview

RE: wsdl: doesn't describe pojos in xsd

No change ... what set of dependency JARs would you like me to use with this? The latest JAXB2 nightly? Brice -----Original Message----- From: Dan Diephouse [mailto:dan@xxxxxxxxxxxxxxxxxx] Sent: Wednesday, October 18, 2006 12:16 AM To: user@xxxxxxxxxxxxxxxxxx Subject: Re: [xfire-user] wsdl: doesn't describe pojos in xsd I can confirm there is definitely a bug in the JAXB WSDL generation... Could you maybe try this build? http://snapshots.repository.codehaus.org/org/codehaus/xfire/xfire-all/1. 2-SNAPSHOT/xfire-all-1.2-20061016.171227-27.jar We're working on getting 1.2.3 out soon! :-) - Dan Ruth, Brice D wrote: > Dan - > > We're using JSR-181 annotations, so here's the annotation on the > service class: > > @WebService( > > serviceName = "EwsTaskService", > > endpointInterface = > "com.example.workflow.ewsng.controller.ITaskController") > > Here's our Spring app context, we're using vanilla spring instead of > XBean - > > <?xml version="1.0" encoding="UTF-8"?> > > <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" > "http://www.springframework.org/dtd/spring-beans.dtd"> > >  > > <beans> > >  > > <import resource="classpath:org/codehaus/xfire/spring/xfire.xml"/> > > <bean id="ewsng.TaskController.service" > class="org.codehaus.xfire.spring.ServiceBean"> > > <property name="serviceBean" ref="ewsng.taskController" /> > > <property name="serviceFactory" ref="jaxbServiceFactory" /> > > <property name="faultHandlers"> > > <list> > > <ref bean="ewsng.faultHandler"/> > > </list> > > </property> > > </bean> > > > >  > > <bean name="jaxbServiceFactory" > > class="org.codehaus.xfire.jaxb2.JaxbServiceFactory"> > > <constructor-arg ref="xfire.transportManager" /> > > </bean> > > </beans> > > > -----Original Message----- > *From:* Brice Ruth [mailto:bdruth@xxxxxxxxx] > *Sent:* Saturday, October 14, 2006 10:31 PM > *To:* user@xxxxxxxxxxxxxxxxxx > *Subject:* Re: [xfire-user] wsdl: doesn't describe pojos in xsd > > Not at all - I'll paste the relevant config parts on Monday. > > Brice > > On 10/14/06, *Dan Diephouse* <dan@xxxxxxxxxxxxxxxxxx > <mailto:dan@xxxxxxxxxxxxxxxxxx>> wrote: > > There might be a bug with our JAXBWSDLBuilder that someone pointed > out > to me the other day. Its on my list to fix monday. Although it > might be > a configuration issue - you mind pasting your config? > > - Dan > > Ruth, Brice D wrote: > > > XFire team - > > > > Rolling back to xfire-1.0 JARs appears to fix the problem, > though I am > > still no closer to understanding why the newer versions are "broken" > > for me. We are using JAXB2 bindings on the service side - is JAXB2 > > responsible for generating the schema parts in the wsdl, or is > wsdl4j? > > > > Respects, > > Brice Ruth > > > > -----Original Message----- > > *From:* Ruth, Brice D > > *Sent:* Wednesday, October 11, 2006 3:46 PM > > *To:* user@xxxxxxxxxxxxxxxxxx <mailto:user@xxxxxxxxxxxxxxxxxx> > > *Subject:* [xfire-user] wsdl: doesn't describe pojos in xsd > > > > Good afternoon - > > > > I am seeing a problem in xfire-1.2.2 and xfire-1.1.2, coming from > > xfire-1.0 with respect to generating the wsdl correctly. Somehow, > > XFire is generating the wsdl without explicitly defining the objects > > used by the web service operations. For example, an operation > > "startTasks" has an UpdateTaskInput and a ManageTaskResult (in0 and > > out, respectively). However, those objects are not enumerated > anywhere > > else in the wsdl. Obviously, this causes problems when generating > > client stubs. > > > > I have compiled xfire-1.2.2 from src and replaced all dependent > JARs > > with the ones downloaded by the build process. I have also > grabbed the > > nightly for JAXB2 (10/11) for jaxb-api, jaxb-impl, and jaxb-xjc. > > > > Here's what I would get (excerpts) from xfire-1.0: > > > > > > <xsd:element name="retrieveTasks"> > > <xsd:complexType> > > <xsd:sequence> > > <xsd:element > name="in0" type="ns2:RetrieveTasksInput" nillable="true" > minOccurs="1" maxOccurs="1" /> > > </xsd:sequence> > > </xsd:complexType> > > </xsd:element> > > > >... > > > > <xsd:complexType name="RetrieveTasksInput"> > > <xsd:sequence> > > <xsd:element > name="criteria" type="ns1:TaskSearchDto" minOccurs="0" > nillable="true" /> > > </xsd:sequence> > > </xsd:complexType> > >... > > > > <xsd:complexType name="TaskSearchDto"> > > <xsd:sequence> > > <xsd:element > name="actorIds" type="tns:ArrayOfString" minOccurs="0" > nillable="true" /> > > <xsd:element name="dates" > type="ns1:ArrayOfDateRange" minOccurs="0" nillable="true" /> > > <xsd:element > name="descriptions" type="tns:ArrayOfString" minOccurs="0" > nillable="true" /> > > <xsd:element name="ids" > type="tns:ArrayOfLong" minOccurs="0" nillable="true" /> > > <xsd:element name="names" > type="tns:ArrayOfString" minOccurs="0" nillable="true" /> > > <xsd:element > name="pageNumber" type="xsd:int" minOccurs="0" /> > > <xsd:element > name="pageSize" type="xsd:int" minOccurs="0" /> > > <xsd:element name="sorts" > type="ns1:ArrayOfSortImpl" minOccurs="0" nillable="true" /> > > <xsd:element > name="statuses" type="ns1:ArrayOfETaskStatus" minOccurs="0" > nillable="true" /> > > <xsd:element name="types" > type="tns:ArrayOfString" minOccurs="0" nillable="true" /> > > <xsd:element > name="variables" type="ns1:ArrayOfVariableImpl" minOccurs="0" > nillable="true" /> > > </xsd:sequence> > > </xsd:complexType> > >... (etc., defining each of the objects referenced as elements) > > > > > > > > In the wsdl I get with xfire-1.1.2 and xfire-1.2.2, all I see is > this: > > (No further definitions of the custom type is available.) > > > > > > > ><xsd:element name="retrieveTasks"> > > <xsd:complexType> > > <xsd:sequence> > > <xsd:element maxOccurs="1" minOccurs="1" name="in0" > nillable="true" type="ns1:RetrieveTasksInput"/> > > </xsd:sequence> > > </xsd:complexType> > ></xsd:element> > > > > What's going on here? I've looked through the JIRA issues fixed for > > each release since 1.0 and I've searched the archives and I > can't come > > up with anything that might be causing this. > > > > Cheers, > > Brice Ruth > > > > -- > Dan Diephouse > (616) 971-2053 > Envoi Solutions LLC > http://netzooid.com <http://netzooid.com> > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > <http://xircles.codehaus.org/manage_email> > > > > > -- > Brice Ruth > Software Engineer, Madison WI -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email

Previous Message by Thread: click to view message preview

Next Message by Thread: click to view message preview

Re: Collection member mappint, with java5

Well it seems it is working again in version 1.2.2 Thanks for your great job. Tonio wrote: > > Hi everybody, > > After a lot of trouble trying to subscribe to the list, I did it. > (Don't forget to enable cookies in your browser !!!!) > > I'm an xfire beginner, I'm using > xfire 1.2.1, java 1.5.0_08, xfire-java5 > > I'm trying to map my Service, my classes > look something like this: > > PersonLookUpImpl { > Person getPersonById(int id); > } > > Person { > int getId() > void setId(int id) > String getName() > void setName(String name) > Set<<Emails>> getEmails() > void setEmails(Set<<Emails>> pEmails) > } > > Email { > String getEmail(); > void setEmail(String email); > } > > In my WSDL Set is map to ArrayOfAnyType, is there > a way to map Set<<Emails>> automatically to the correct type, I've tried > - Mapping files (As I understand they are not read in java5) > > And that's all > > Any help will be greatly apreciatted > thanks in advance > tonioc > -- View this message in context: http://www.nabble.com/Collection-member-mappint%2C-with-java5-tf2283117.html#a6885627 Sent from the XFire - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email

Loading Comments...