Sure, that's one way to deal with that issue. Non the less, it's no solution and as soon as I'm going to send a file with lets say 1GB, I'll have the same problem. As far as I understood one benefit of using MTOM (in case of JAX-WS) is, that there is no serialization/deserialization of the attached data taking place, actually providing in-/output as streams and not allocating a new object for the whole data structure. Why else would JBoss use a swapfile for the incoming request if at the same time the whole bunch of incoming data is stored in memory as well? But maybe I'm completely wrong here - that's why I'm asking :-) Well, in the later case - what would be a proper workaround? Provide a handler which parses the incoming SOAPMessage and extracts (or cuts out) the attached data providing a unique identifier that might be used to access this data from somewhere else, once the webservice method is invoked and all deserialization has been done? And yes, I'm aware that a web service is not the right solution for sending such huge documents, but by thinking about a middleware connected to a CMS backend, files (e.g. PDFs) with about 20-50MB are quite normal and should not result in a DoS ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230142#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...