[jira] [Commented] (CXF-8279) Attachment inputstream starts with -1 for slow connections
[
https://issues.apache.org/jira/browse/CXF-8279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17103115#comment-17103115
]
Bhathiya Jayasekara commented on CXF-8279:
--
This change also works perfectly fine. So it seems like a race condition or a
timeout caused this.
Hope this will help.
{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.
try { <<
Thread.sleep(500); <<
} catch (InterruptedException e) { <<
e.printStackTrace();<<
} <<
int value = pbs.read();
pbs.unread(value);
while (value != -1) {
{code}
> 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}
> Another important thing is this happens only for non-localhost and https
> connections.
> 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)
[jira] [Updated] (CXF-8206) Update to saaj-impl 1.5.2
[ https://issues.apache.org/jira/browse/CXF-8206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Markevich updated CXF-8206: -- Summary: Update to saaj-impl 1.5.2 (was: Update to saaj-impl 1.5.1) > Update to saaj-impl 1.5.2 > - > > Key: CXF-8206 > URL: https://issues.apache.org/jira/browse/CXF-8206 > Project: CXF > Issue Type: Task > Components: JAX-WS Runtime >Reporter: Alexey Markevich >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CXF-8192) Upgrade jaxb runtime to 2.3.3
[ https://issues.apache.org/jira/browse/CXF-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Markevich resolved CXF-8192. --- Resolution: Fixed > Upgrade jaxb runtime to 2.3.3 > - > > Key: CXF-8192 > URL: https://issues.apache.org/jira/browse/CXF-8192 > Project: CXF > Issue Type: Task > Components: JAXB Databinding >Affects Versions: 3.3.4 >Reporter: Jim Ma >Assignee: Jim Ma >Priority: Major > Fix For: 3.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CXF-8192) Upgrade jaxb runtime to 2.3.3
[ https://issues.apache.org/jira/browse/CXF-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102882#comment-17102882 ] Alexey Markevich commented on CXF-8192: --- https://github.com/apache/cxf/commit/cd7cbb3aec02654cdd7e891e9e17ef2c0f70888b > Upgrade jaxb runtime to 2.3.3 > - > > Key: CXF-8192 > URL: https://issues.apache.org/jira/browse/CXF-8192 > Project: CXF > Issue Type: Task > Components: JAXB Databinding >Affects Versions: 3.3.4 >Reporter: Jim Ma >Assignee: Jim Ma >Priority: Major > Fix For: 3.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CXF-8192) Upgrade jaxb runtime to 2.3.3
[ https://issues.apache.org/jira/browse/CXF-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Markevich updated CXF-8192: -- Summary: Upgrade jaxb runtime to 2.3.3 (was: Upgrade jaxb runtime to 2.3.3-b02) > Upgrade jaxb runtime to 2.3.3 > - > > Key: CXF-8192 > URL: https://issues.apache.org/jira/browse/CXF-8192 > Project: CXF > Issue Type: Task > Components: JAXB Databinding >Affects Versions: 3.3.4 >Reporter: Jim Ma >Assignee: Jim Ma >Priority: Major > Fix For: 3.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CXF-8279) Attachment inputstream starts with -1 for slow connections
[
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}
Another important thing is this happens only for non-localhost and https
connections.
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 (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
> 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();
>
[jira] [Resolved] (CXF-8280) AttachmentId issue
[
https://issues.apache.org/jira/browse/CXF-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-8280.
--
Resolution: Fixed
> AttachmentId issue
> ---
>
> Key: CXF-8280
> URL: https://issues.apache.org/jira/browse/CXF-8280
> Project: CXF
> Issue Type: Bug
>Reporter: Frédéric Pirson
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.4.0, 3.3.7
>
>
> Hello,
> I don't know if it is really a bug, or something I am missing, but I have and
> issue when the attachmend is resolved.
> I have a xopUri like this :
>
> {code:java}
> //
> cid:998c3362-5b5f-405a-817a-b20f8373c378-5@urn%3Abe%3Acin%3Anip%3Aasync%3Ageneric
> {code}
> when it is resolved as attachmentId via the method getAttachmentId(xopUri)
> the value is this :
> {code:java}
> // 998c3362-5b5f-405a-817a-b20f8373c378-5@urn:be:cin:nip:async:generic
> {code}
> We see here that %3A has been replaced by his related characters ':'
>
> After when the attachmentCallbackHandler try to find the correct attachment
> in the list (loadAttachments methods) it compare these 2 values in the do
> while
>
> {code:java}
> // }while(attachmentId != null && !attachmentId.equals(attachment.getId()));
> {code}
> The value of attachmentId is
>
> {code:java}
> // 998c3362-5b5f-405a-817a-b20f8373c378-5@urn:be:cin:nip:async:generic
> {code}
> The value of attachment.getId() is :
> {code:java}
> //
> 998c3362-5b5f-405a-817a-b20f8373c378-5@urn%3Abe%3Acin%3Anip%3Aasync%3Ageneric
> {code}
> So the comparaison fails and attachment is not found => Exception attachment
> not found
>
> Is it some issue, or do I something wrong ?
>
> Version of wss4j : 2.2.4
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CXF-8280) AttachmentId issue
[
https://issues.apache.org/jira/browse/CXF-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-8280:
-
Fix Version/s: 3.3.7
3.4.0
> AttachmentId issue
> ---
>
> Key: CXF-8280
> URL: https://issues.apache.org/jira/browse/CXF-8280
> Project: CXF
> Issue Type: Bug
>Reporter: Frédéric Pirson
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.4.0, 3.3.7
>
>
> Hello,
> I don't know if it is really a bug, or something I am missing, but I have and
> issue when the attachmend is resolved.
> I have a xopUri like this :
>
> {code:java}
> //
> cid:998c3362-5b5f-405a-817a-b20f8373c378-5@urn%3Abe%3Acin%3Anip%3Aasync%3Ageneric
> {code}
> when it is resolved as attachmentId via the method getAttachmentId(xopUri)
> the value is this :
> {code:java}
> // 998c3362-5b5f-405a-817a-b20f8373c378-5@urn:be:cin:nip:async:generic
> {code}
> We see here that %3A has been replaced by his related characters ':'
>
> After when the attachmentCallbackHandler try to find the correct attachment
> in the list (loadAttachments methods) it compare these 2 values in the do
> while
>
> {code:java}
> // }while(attachmentId != null && !attachmentId.equals(attachment.getId()));
> {code}
> The value of attachmentId is
>
> {code:java}
> // 998c3362-5b5f-405a-817a-b20f8373c378-5@urn:be:cin:nip:async:generic
> {code}
> The value of attachment.getId() is :
> {code:java}
> //
> 998c3362-5b5f-405a-817a-b20f8373c378-5@urn%3Abe%3Acin%3Anip%3Aasync%3Ageneric
> {code}
> So the comparaison fails and attachment is not found => Exception attachment
> not found
>
> Is it some issue, or do I something wrong ?
>
> Version of wss4j : 2.2.4
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CXF-8280) AttachmentId issue
[
https://issues.apache.org/jira/browse/CXF-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102478#comment-17102478
]
Colm O hEigeartaigh commented on CXF-8280:
--
I've moved this to CXF. What I will do is to add some code in the
AttachmentCallbackHandler to URL Decode the attachment ID + check this as well.
Hopefully this will work. Please test with the latest code + re-open this issue
if it does not work for you!
> AttachmentId issue
> ---
>
> Key: CXF-8280
> URL: https://issues.apache.org/jira/browse/CXF-8280
> Project: CXF
> Issue Type: Bug
>Reporter: Frédéric Pirson
>Assignee: Colm O hEigeartaigh
>Priority: Major
>
> Hello,
> I don't know if it is really a bug, or something I am missing, but I have and
> issue when the attachmend is resolved.
> I have a xopUri like this :
>
> {code:java}
> //
> cid:998c3362-5b5f-405a-817a-b20f8373c378-5@urn%3Abe%3Acin%3Anip%3Aasync%3Ageneric
> {code}
> when it is resolved as attachmentId via the method getAttachmentId(xopUri)
> the value is this :
> {code:java}
> // 998c3362-5b5f-405a-817a-b20f8373c378-5@urn:be:cin:nip:async:generic
> {code}
> We see here that %3A has been replaced by his related characters ':'
>
> After when the attachmentCallbackHandler try to find the correct attachment
> in the list (loadAttachments methods) it compare these 2 values in the do
> while
>
> {code:java}
> // }while(attachmentId != null && !attachmentId.equals(attachment.getId()));
> {code}
> The value of attachmentId is
>
> {code:java}
> // 998c3362-5b5f-405a-817a-b20f8373c378-5@urn:be:cin:nip:async:generic
> {code}
> The value of attachment.getId() is :
> {code:java}
> //
> 998c3362-5b5f-405a-817a-b20f8373c378-5@urn%3Abe%3Acin%3Anip%3Aasync%3Ageneric
> {code}
> So the comparaison fails and attachment is not found => Exception attachment
> not found
>
> Is it some issue, or do I something wrong ?
>
> Version of wss4j : 2.2.4
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CXF-8276) Create a Build Of Material POM file with only the CXF modules
[ https://issues.apache.org/jira/browse/CXF-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-8276: - Fix Version/s: 3.4.0 > Create a Build Of Material POM file with only the CXF modules > - > > Key: CXF-8276 > URL: https://issues.apache.org/jira/browse/CXF-8276 > Project: CXF > Issue Type: Improvement > Components: Build system >Reporter: Emile de Weerd >Priority: Trivial > Fix For: 3.4.0 > > > CXF parent was changed in 3.2.5 to contain all the CXF modules in the > dependency managemenet which was a great improvement for CXF users when > integrating CXF as they would have to worry so much about dependency version. > A project I am involved in though is also a framework project and provides > CXF amongst a whole lot of other dependencies, and integrating the CXF > thirdparty dependency tree becomes quite tricky. > Hence the need for a lighter BOM (build of material) POM file, containing > only the modules of the CXF project. This would follow the example of netty > for instance in [https://github.com/netty/netty/blob/4.1/bom/pom.xml] with > their netty-bom module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CXF-8276) Create a Build Of Material POM file with only the CXF modules
[ https://issues.apache.org/jira/browse/CXF-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-8276. -- Resolution: Fixed > Create a Build Of Material POM file with only the CXF modules > - > > Key: CXF-8276 > URL: https://issues.apache.org/jira/browse/CXF-8276 > Project: CXF > Issue Type: Improvement > Components: Build system >Reporter: Emile de Weerd >Priority: Trivial > Fix For: 3.4.0 > > > CXF parent was changed in 3.2.5 to contain all the CXF modules in the > dependency managemenet which was a great improvement for CXF users when > integrating CXF as they would have to worry so much about dependency version. > A project I am involved in though is also a framework project and provides > CXF amongst a whole lot of other dependencies, and integrating the CXF > thirdparty dependency tree becomes quite tricky. > Hence the need for a lighter BOM (build of material) POM file, containing > only the modules of the CXF project. This would follow the example of netty > for instance in [https://github.com/netty/netty/blob/4.1/bom/pom.xml] with > their netty-bom module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Moved] (CXF-8280) AttachmentId issue
[
https://issues.apache.org/jira/browse/CXF-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh moved WSS-671 to CXF-8280:
--
Component/s: (was: WSS4J Handlers)
Estimated Complexity: Unknown
Key: CXF-8280 (was: WSS-671)
Affects Version/s: (was: 2.2.4)
Workflow: Default workflow, editable Closed status (was:
classic default workflow)
Project: CXF (was: WSS4J)
> AttachmentId issue
> ---
>
> Key: CXF-8280
> URL: https://issues.apache.org/jira/browse/CXF-8280
> Project: CXF
> Issue Type: Bug
>Reporter: Frédéric Pirson
>Assignee: Colm O hEigeartaigh
>Priority: Major
>
> Hello,
> I don't know if it is really a bug, or something I am missing, but I have and
> issue when the attachmend is resolved.
> I have a xopUri like this :
>
> {code:java}
> //
> cid:998c3362-5b5f-405a-817a-b20f8373c378-5@urn%3Abe%3Acin%3Anip%3Aasync%3Ageneric
> {code}
> when it is resolved as attachmentId via the method getAttachmentId(xopUri)
> the value is this :
> {code:java}
> // 998c3362-5b5f-405a-817a-b20f8373c378-5@urn:be:cin:nip:async:generic
> {code}
> We see here that %3A has been replaced by his related characters ':'
>
> After when the attachmentCallbackHandler try to find the correct attachment
> in the list (loadAttachments methods) it compare these 2 values in the do
> while
>
> {code:java}
> // }while(attachmentId != null && !attachmentId.equals(attachment.getId()));
> {code}
> The value of attachmentId is
>
> {code:java}
> // 998c3362-5b5f-405a-817a-b20f8373c378-5@urn:be:cin:nip:async:generic
> {code}
> The value of attachment.getId() is :
> {code:java}
> //
> 998c3362-5b5f-405a-817a-b20f8373c378-5@urn%3Abe%3Acin%3Anip%3Aasync%3Ageneric
> {code}
> So the comparaison fails and attachment is not found => Exception attachment
> not found
>
> Is it some issue, or do I something wrong ?
>
> Version of wss4j : 2.2.4
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CXF-8279) Attachment inputstream starts with -1 for slow connections
[
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
[jira] [Created] (CXF-8279) Attachment inputstream starts with -1 for slow connections
Bhathiya Jayasekara created CXF-8279:
Summary: 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
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
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
