Hi Michael I take it you mean https://issues.apache.org/jira/browse/PROTON-892
I notice from Alans reply (http://mail-archives.apache.org/mod_mbox/qpid-proton/201505.mbox/%3C1432734537.2993.118.camel%40redhat.com%3E) he suggested some changes to your original mail and asked you to create the JIRA and assign it to him. I see it isnt assigned to him, but I don't think you can actually assign JIRAs without specific project permissions, so that explains that. I imagine he simply overlooked it as a result; you can @mention folks on JIRAs to get their attention. I have assigned it to him now. Robbie On 20 August 2015 at 08:46, Michael Ivanov <iv...@logit-ag.de> wrote: > Sorry, > > A couple of months ago I discovered a case in proton that prevented > using more than 32767 nodes in message data. One of our applications > created large messages and wherever it exceeded this limit it just > crashed. The data type used to keep number of nodes in proton is > unsigned short and actually allows to have twice as much number of > nodes (65535), but because of the way pni_data_grow function is > implemented the upper half of the complete value range (32768...65535) > can never be used. > > To allow our application to run I created a fix and currently use > custom proton version. I also published the fix on mailing list and > created a jira issue on it on mr. Alan Conway's advice, but I see > that version 0.10 still uses the same approach. > > Is there any special reason to limit the data size to 32767 nodes? > It is sad that I have to proceed to use patched version for our systems. > > Best regards, > > 17.08.2015 23:57, Robbie Gemmell пишет: >> On 17 August 2015 at 21:11, Flavio Percoco <fla...@redhat.com> wrote: >> <snip> >>> >>> Outsider question: >>> >>> Is there a reason why 0.10 is used rather than 0.10.0? >>> >> >> I mainly used 0.10 because it was versioned 0.10-SNAPSHOT beforehand >> and had already gone through initial alpha/betas as 0.10 before I >> started progressing things, so I decided against changing it during >> the cycle (and potentially delaying things further..). >> >>> I believe sticking to 3-digit versions and keep it consistent would >>> make supporting scripts, bindings and even packages easier since they >>> would not have to care about these 2-to-3 digit changes. >>> >> >> Agreed. >> >>> Is that something we can change in qpid-proton ? >>> >> >> I'm entirely on board personally with including the extra digit all >> the time (and actually using it to do more regular point releases; >> when I did 0.9.1 that was really the first time any of the components >> have ever had one). I have been using x.y.z format versions for the >> JMS client releases from the start for precisely the reasons you >> covered, so a thumbs up from me. >> >> Robbie >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org >> For additional commands, e-mail: users-h...@qpid.apache.org >> > > > -- > \ / | | > (OvO) | Mikhail Iwanow | > (^^^) | Voice: +7 (911) 223-1300 | > \^/ | E-mail: iv...@logit-ag.de | > ^ ^ | |
