On Wed, May 14, 2014 at 1:05 PM, Clebert Suconic <csuco...@redhat.com>wrote:

> I was just playing with possibilities and trying to find ways to improve
> the API how things are done.
>
>
>
> >  The interface is designed to
> > operate in terms of chunks of message data rather than in terms of an
> > entire message.
>
>
>
> That's one thing that I'm lacking control through the API actually.. which
> I'm looking to improve.
>
>
> My application (hornetQ) has the ability to store messages on the disk and
> send in chunks to the server.
>
> Using the current API, I would have to parse the entire message to Proton,
> and have proton dealing with the chunks.
>

I'm not sure I follow this. The byte[] that you pass to send doesn't need
to be a complete message.


> I have tests for instance on sending 1 Gigabyte messages, where the body
> stays on the disk on the server, while the client streams bytes while
> receiving, and having flow control holding them.
>
> Proton has a big buffer internally, and which actually is not exposing
> flow control in such way I would stop feeding Proton. as a result this use
> case would easily cause OMEs from Proton.
>

The Delivery.pending() API will tell you exactly how much data is being
buffered for a given delivery, and
Session.getOutgoingBytes()/getIncomingBytes() will tell you how much is
being buffered in aggregate by the Session. Between the two of these you
should be able to limit what Proton is buffering.


>
> as I said I was just for now exploring with possibilities. I could send a
> ReadableBuffer (the new interface from my previous patch) and use a Pool on
> this buffer to encode my Message. But I stlil lack control on my large
> messages streaming and flow control.
>
>
> The way things are done now, if i wanted to preserve my large message
> functionality at the client level (outside of Proton's API), I would need
> to bypass proton and send Delivery directly without Proton intervention.


I'm still confused by this. Can you point me to the code or post some
samples of what you're having trouble with?

--Rafael

Reply via email to