qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <tabish...@gmail.com>
Subject Re: Connection problem with Azure Service Bus Queue
Date Fri, 01 Dec 2017 17:41:27 GMT
On 12/01/2017 12:38 PM, Gordon Sim wrote:
> On 01/12/17 14:37, Шелест Ігор wrote:
>> hello_world called
>> on_container_start called[00CB1200]:  -> SASL
>> [00CB1200]:  <- SASL
>> [00CB1200]:0 <- @sasl-mechanisms(64)
>> [sasl-server-mechanisms=@PN_SYMBOL[:MSSBCBS, :PLAIN, :ANONYMOUS,
>> :EXTERNAL]]
>> [00CB1200]:0 -> @sasl-init(65) [mechanism=:EXTERNAL,
>> initial-response=b"IgorShelestNotPartitionedQueuePolicyName"]
>> [00CB1200]:0 <- @sasl-outcome(68) [code=0, additional-data=b"Welcome!"]
>> [00CB1200]:  -> AMQP
>> [00CB1200]:0 -> @open(16)
>> [container-id="41155a12-3703-475c-8063-d61b8f3de514",
>> hostname="igorshelestnamespacename.servicebus.windows.net",
>> max-frame-size=10000, channel-max=32767, idle-time-out=500]
>> [00CB1200]:0 -> @close(24) [error=@error(29) [condition=:"proton:io",
>> description="An existing connection was forcibly closed by the remote
>> host.  - on read from
>> igorshelestnamespacename.servicebus.windows.net:5672 (AMQP header
>> mismatch: Insufficient data to determine protocol [''] (connection
>> aborted))"]]
>> [00CB1200]:  <- EOS
>>
>> Exception:▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌▌

>> >
>>
>> Unsuccessful exit
>> ========================================================================== 
>>
>>
>> I tried to google what the problem, didn't really find any solution.
>> As far as I understand some connection options are probably wrong.
>> Do you have any idea how to fix this issue?
>
> Is there any error or log message available on the service bus side? 
> It sounds like servicebus is just dropping the connection. It has 
> successfully authenticated, so you could be right it may be that it 
> doesn't like some of the values you send in the open frame, e.g. 500 
> millisecs may be considered too low for the idle timeout. (The 
> max-frame-size and channel-max don't really impose any particular 
> burden on the peer). 

I recall there being a lower limit on the idle timeout of something like 
2 minutes so that could be causing it to reject the connection.

-- 
Tim Bish


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message