[jira] [Closed] (CXF-6254) Buffer Problem using CXF with NTLM Auth and SSL

["Colm O hEigeartaigh (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CXF-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Colm O hEigeartaigh closed CXF-6254.
------------------------------------

> Buffer Problem using CXF with NTLM Auth and SSL
> -----------------------------------------------
>
>                 Key: CXF-6254
>                 URL: https://issues.apache.org/jira/browse/CXF-6254
>             Project: CXF
>          Issue Type: Bug
>          Components: Transports
>    Affects Versions: 2.7.14
>            Reporter: Andreas Reinhardt
>            Priority: Minor
>             Fix For: 3.0.3
>
>         Attachments: log.txt
>
>
> I'm trying to connect to a sharepoint WSDL using a generated CXF client.
> While I've had my fun struggling with NTLM authentication (I wasn't using the async-client before!) I'm confronted with a new problem.
> I want to upload a binary file using the copy.wsdl from sharepoint which is working fine with files approximately smaller than 16kbyte (using SSL & NTLM)...
> Using larger files with about ~500kbyte cxf blocks at HttpConduit.handleRetrasmits() (first line at getHttpResponse()), coming from AsyncHttpConduit.updateCookiesBeforeRetransmit().
> I tried increasing the buffers to an insanely amount like
> {code}
> Bus bus = BusFactory.getDefaultBus();
> bus.setProperty("bus.io.CachedOutputStream.Threshold", String.valueOf(1024 * 1024 * 128));
> conduit.getClient().setChunkLength(1024 * 1024 * 128);
> {code}
> altough chunking is disabled - the buffer size comes from that configuration (AsyncHttpConduit line 266):
> {code}
> int bufSize = csPolicy.getChunkLength() > 0 ? csPolicy.getChunkLength() : 16320;
> inbuf = new SharedInputBuffer(bufSize, allocator);
> outbuf = new SharedOutputBuffer(bufSize, allocator);
> {code}
> but after that I got http code 400 (invalid request) from the sharepoint server if the file was larger than those pesky ~16kbyte...
> using the highest loglevel I noticed that in the 1st retransmission the buffer is now always sending the same first ~16kbyte to the sslcontext...
> That's all happening in CxfHttpAsyncRequestProducer.produceContent() and as far as I can tell it's happening because the buffer is always resettet in line 82 at buffer.rewind().
> {code}
> public void produceContent(final ContentEncoder enc, final IOControl ioc) throws IOException {
>         if (content != null) {
>             if (buffer == null) {
>                 if (content.getTempFile() == null) {
>                     buffer = ByteBuffer.wrap(content.getBytes());
>                 } else {
>                     fis = content.getInputStream();
>                     chan = (fis instanceof FileInputStream) 
>                         ? ((FileInputStream)fis).getChannel() : Channels.newChannel(fis);
>                     buffer = ByteBuffer.allocate(8 * 1024);
>                 }
>             }
>             int i = -1;
>             buffer.rewind();
>             if (buffer.hasRemaining() && chan != null) {
>                 i = chan.read(buffer);
>                 buffer.flip();
>             }
>             enc.write(buffer);
>             if (!buffer.hasRemaining() && i == -1) {
>                 enc.complete();
>             }
>         } else {
>             buf.produceContent(enc, ioc);
>         }
>     }
> {code}
> So I guess something is either terribly wrong at my setup or there might be a bug here...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)