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

Bhathiya Jayasekara updated CXF-8279:
-------------------------------------
    Description: 
When a file is uploaded with a slow connection (only), using my CXF REST API, I 
get {{Couldn't find MIME boundary}} error. So I debugged the CXF core code to 
find out why. Now I'm looking at this code[1].

{code:java}
    private static boolean readTillFirstBoundary(PushbackInputStream pbs, 
byte[] bp) throws IOException {

        // work around a bug in PushBackInputStream where the buffer isn't
        // initialized
        // and available always returns 0.
        int value = pbs.read();
        pbs.unread(value);
        while (value != -1) {
            value = pbs.read();
{code}

When the client to server connection is very slow, the first {{read()}} of the 
input stream almost always is -1. That results {{Couldn't find MIME boundary 
error}} at the later on the flow.

If I change the code (just to debug) to skip the first byte when it's -1, like 
below, it works smoothly. See the 3 lines shown with "<<<<<<<". That means the 
data I expect is available after -1.  

{code:java}
    private static boolean readTillFirstBoundary(PushbackInputStream pbs, 
byte[] bp) throws IOException {

        // work around a bug in PushBackInputStream where the buffer isn't
        // initialized
        // and available always returns 0.
        int value = pbs.read();
        if (value == -1) {                <<<<<< if the first byte is -1,
            value = pbs.read();           <<<<<< ignore that and read the  
        }                                 <<<<<< next byte
        pbs.unread(value);
        while (value != -1) {
            value = pbs.read();
{code}

Any idea what could be the reason for giving -1 for the first read always when 
the connection is slow?

[1] 
https://github.com/apache/cxf/blob/cxf-3.2.8/core/src/main/java/org/apache/cxf/attachment/AttachmentDeserializer.java#L264



  was:
When a file is uploaded with a slow connection (only), using my CXF REST API, I 
get {{Couldn't find MIME boundary}} error. So I debugged the CXF core code to 
find out why. Now I'm looking at this code[1].

{code:java}
    private static boolean readTillFirstBoundary(PushbackInputStream pbs, 
byte[] bp) throws IOException {

        // work around a bug in PushBackInputStream where the buffer isn't
        // initialized
        // and available always returns 0.
        int value = pbs.read();
        pbs.unread(value);
        while (value != -1) {
            value = pbs.read();
{code}

When the client to server connection is very slow, the first {{read()}} of the 
input stream almost always is -1. That results {{Couldn't find MIME boundary 
error}} at the later on the flow.

If I change the code to skip the first byte (just to debug), when it's -1, like 
below, it works smoothly. See the 3 lines shown with "<<<<<<<". 

{code:java}
    private static boolean readTillFirstBoundary(PushbackInputStream pbs, 
byte[] bp) throws IOException {

        // work around a bug in PushBackInputStream where the buffer isn't
        // initialized
        // and available always returns 0.
        int value = pbs.read();
        if (value == -1) {                <<<<<< if the first byte is -1,
            value = pbs.read();           <<<<<< ignore that and read the  
        }                                 <<<<<< next byte
        pbs.unread(value);
        while (value != -1) {
            value = pbs.read();
{code}

Any idea what could be the reason for giving -1 for the first read always when 
the connection is slow?

[1] 
https://github.com/apache/cxf/blob/cxf-3.2.8/core/src/main/java/org/apache/cxf/attachment/AttachmentDeserializer.java#L264




> Attachment inputstream starts with -1 for slow connections
> ----------------------------------------------------------
>
>                 Key: CXF-8279
>                 URL: https://issues.apache.org/jira/browse/CXF-8279
>             Project: CXF
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.2.8
>            Reporter: Bhathiya Jayasekara
>            Priority: Major
>
> When a file is uploaded with a slow connection (only), using my CXF REST API, 
> I get {{Couldn't find MIME boundary}} error. So I debugged the CXF core code 
> to find out why. Now I'm looking at this code[1].
> {code:java}
>     private static boolean readTillFirstBoundary(PushbackInputStream pbs, 
> byte[] bp) throws IOException {
>         // work around a bug in PushBackInputStream where the buffer isn't
>         // initialized
>         // and available always returns 0.
>         int value = pbs.read();
>         pbs.unread(value);
>         while (value != -1) {
>             value = pbs.read();
> {code}
> When the client to server connection is very slow, the first {{read()}} of 
> the input stream almost always is -1. That results {{Couldn't find MIME 
> boundary error}} at the later on the flow.
> If I change the code (just to debug) to skip the first byte when it's -1, 
> like below, it works smoothly. See the 3 lines shown with "<<<<<<<". That 
> means the data I expect is available after -1.  
> {code:java}
>     private static boolean readTillFirstBoundary(PushbackInputStream pbs, 
> byte[] bp) throws IOException {
>         // work around a bug in PushBackInputStream where the buffer isn't
>         // initialized
>         // and available always returns 0.
>         int value = pbs.read();
>         if (value == -1) {                <<<<<< if the first byte is -1,
>             value = pbs.read();           <<<<<< ignore that and read the  
>         }                                 <<<<<< next byte
>         pbs.unread(value);
>         while (value != -1) {
>             value = pbs.read();
> {code}
> Any idea what could be the reason for giving -1 for the first read always 
> when the connection is slow?
> [1] 
> https://github.com/apache/cxf/blob/cxf-3.2.8/core/src/main/java/org/apache/cxf/attachment/AttachmentDeserializer.java#L264



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to