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 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.

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.

Reply via email to