qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rafael H. Schloming (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PROTON-126) Sender.send should return void
Date Mon, 11 Feb 2013 16:25:12 GMT

    [ https://issues.apache.org/jira/browse/PROTON-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575872#comment-13575872

Rafael H. Schloming commented on PROTON-126:

I don't think we should return void here because although it's useful for the engine to be
able to buffer bytes on behalf of the application, I don't want the API to force it to accept
all bytes all the time. I'd prefer the engine behaviour here to ultimately be a configurable

Fundamentally there are three issues at play here: (1) how should the engine indicate when
it is blocked from writing message data onto the wire, (2) should the engine be allowed to
partially consume bytes it is given, and (3) if so how should this be exposed through the
Java API.

My thoughts are for (1) we expose this through credit levels, for (2) we allow the engine
to impose an optionally configurable limit for buffering, and (3) given the current API we
would keep the original signature. It's possible we might revisit (3) in the context of a
wider change such as using ByteBuffers in place of byte[], however I'd file that as a separate
> Sender.send should return void
> ------------------------------
>                 Key: PROTON-126
>                 URL: https://issues.apache.org/jira/browse/PROTON-126
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-j
>            Reporter: Hiram Chirino
>            Assignee: Rafael H. Schloming
> No flow control is in place.  You can easily OOM a JVM since Sender.send continues to
accept more bytes even if the peer is not accepting anymore data.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message