[
https://issues.apache.org/jira/browse/CXF-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-6254.
--------------------------------------
Resolution: Fixed
Marking as "fixed" as the comment notes it works in CXF 3.0.3.
> 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)
