Hi all,
I am canceling this voting as we decided to build RC5 to include fixes
for QPID-6926 and QPID-6928.
Thanks a lot for testing and reporting issues with the RC4.
Kind Regards,
Alex
On 3 December 2015 at 11:06, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
> Does the broker put the full stack trace of the NullPointerException in its
> logs?
>
> I'll try to fix this (as well as the out of order detach) if I can locate
> it.
>
> Cheers,
> Rob
>
> On 3 December 2015 at 10:03, Gordon Sim <g...@redhat.com> wrote:
>
>> On 12/02/2015 09:45 PM, Rob Godfrey wrote:
>>
>>> On 2 December 2015 at 21:45, Gordon Sim <g...@redhat.com> wrote:
>>>
>>>> From the proton python examples, I was unable to connect as that client
>>>> populates the hostname with a host and port combination, which was
>>>> causing
>>>> the broker to close the connection:
>>>>
>>> [...]
>>
>>> In its default configuration the Java Broker will accept any valid
>>> hostname
>>> or IP address as the "hostname", or the empty string, or "default". It
>>> will not match anything containing the port number, nor will it match to
>>> 0.0.0.0. To get the Python client to work you could add the following
>>> entry:
>>>
>>> {
>>> "name" : "pattern",
>>> "virtualHostNode" : "default",
>>> "type" : "patternMatchingAlias",
>>> "pattern" : ".*"
>>> }
>>>
>>> into the list of virtualhostaliases within the AMQP port entry within the
>>> config.json file. This will match any hostname in the open frame to the
>>> virtual host named "default".
>>>
>>
>> Yes indeed, that works perfectly, thanks! With that in place most of the
>> python examples work as expected. The one exception is those involving the
>> server, which creates a sending link with no address in the target (the so
>> called 'anonymous-relay' behaviour I believe?). The java broker responds
>> with:
>>
>> [0x8c9450]:0 <- @close(24) [error=@error(29)
>>> [condition=:"amqp:connection:forced",
>>> description="java.lang.NullPointerException"]]
>>>
>>
>> That of course isn't an issue per-se as the behaviour in question isn't in
>> any way official, its just a useful convention. I mention it here only in
>> case it is expected to work and there is some minor interop issue we can
>> fix (and also for future reference if anyone else hits it).
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
