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

Reply via email to