Daniel Kulp [[email protected]] wrote:
> 
> In most cases, that will not buffer the data.   The cases where it would
> involve:
> 
> 1) Multple attachments.  Not your case.  You only have one.
> 
> 2) Turning on schema validation.  Due to a "bug" in JAXB, if schema validation
> is on, the schema validator consumes the stream.   Thus, we buffer.   Again,
> not your case.
> 
> 3) SAAJ interceptors.   SAAJ also requires buffering them.  Again, not your
> case.
> 
> 4) JAX-WS handlers - relates to SAAJ.  Again, not your case.
> 
> Thus, you should be all set.

Thank you for calming me down a bit :)

> On Friday 08 October 2010 10:29:13 am Jimi Hullegård wrote:
> >
> > OK. Well, since I will refactor my code and divide the entity into two (one
> > for metadata, and one for binary data), I won't have to handle any
> > unwanted binary data. But I'm still wondering what happens if I request
> > the binary data entity, but then for some reason never touch the
> > InputStream (ie not reading from it, and not closing it. Considering the
> > setup above, what will happen? Will the connection linger for a while
> > before it times out? Can it cause some negative side effects, like leaking
> > memory?
> 
> On the client side, I don't think it would really cause an issue.  Eventually,
> the connection would get garbage collected and cleaned up and such.  There may
> be a performance issue if you use the client to talk back and forth with the
> server quite a bit as that particular connection would not be able to be used
> for keep-alive scenarios.
> 
> The server side is slightly more problematic.   The server will be trying to
> write to that socket.  If the client isn't reading, the server will block.
> Eventually, the socket will timeout (your app server or container or whatever
> usually have somesort of timeout control) and the server will throw an
> Exception and the thread will free up, but for that period of time, that
> thread will not be available to process additional requests.

This is for a internal web service, and will be the only access point the 
application has to the database. So it will basically be only one client 
responsible for requests. So that would mean that both the ws-client and the 
ws-server would be effected if we would have cases where the InputStream is 
ignored. So I guess I have to make damn sure that I: 1) only request the binary 
data when it's really needed, 2) really read the InputStream and read it fully, 
and, 3) if I for some reason don't want the data after having requested it 
(maybe because something else is wrong and I will not be able to use it anyway) 
then I must call InputStream.close() to limit the side effects as much as 
possible.

Thanks for your help. :)

/Jimi

Reply via email to