cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Reinhardt (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-6254) Buffer Problem using CXF with NTLM Auth and SSL
Date Mon, 23 Feb 2015 20:02:12 GMT

    [ https://issues.apache.org/jira/browse/CXF-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333739#comment-14333739
] 

Andreas Reinhardt commented on CXF-6254:
----------------------------------------

Well I've just tried the very same code using CXF 3.0.3 and it worked like a charm... 

we are using maven so we just changed the version property... since 3.0.3 should be backward
compatible I guess it's not a big deal anymore...

> 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
>    Affects Versions: 2.7.14
>            Reporter: Andreas Reinhardt
>            Priority: Minor
>         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
(v6.3.4#6332)

Mime
View raw message