Re: qpid-cpp-1.35 - Cannot sent large message (320K)

[sivasnp]

Hi Gordon,
  Please see the broker log attached.

Thanks,
Siva.



On Wed, Mar 29, 2017 at 4:36 PM, Siva Kumar Siva Sankaran <
siva.kumar.siva.sanka...@rockwellcollins.com> wrote:

> The qpid-send just hangs. I have to terminate it.
>
> I did a qpid-stat -q on the queue at the broker and did not see any new
> messages
>
> I did not enable the qpid-broker logs. I will enable it and sent that to
> you in an hour.
>
> Thanks,
> Siva
>
> On Wed, Mar 29, 2017 at 4:32 PM Gordon Sim [via Qpid] <
> ml-node+s2158936n7661650...@n2.nabble.com> wrote:
>
>> On 29/03/17 22:10, sivasnp wrote:
>> > Please see the output of
>> >
>> > qpid-send -b 172.21.0.254 --address amq.fanout --content-size 50
>> > --log-enable trace+
>>
>> [...]
>>
>> > 2017-03-29 21:07:06 [Network] trace RECV [[10.0.3.219:51830
>> > -172.21.0.254:5672]]: Frame[BEbe; channel=1; {SessionCompletedBody:
>> > commands={ [0,2] }; }]
>> > 2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
>> > -172.21.0.254:5672]]: Frame[Bbe; channel=1; {MessageTransferBody:
>> > destination=amq.fanout; accept-mode=1; acquire-mode=0; }]
>> > 2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
>> > -172.21.0.254:5672]]: Frame[be; channel=1; header (66 bytes);
>> > properties={{MessageProperties: content-length=50;
>> > content-type=text/plain; user-id=;
>> > application-headers={sn:F4:uint32(1),ts:F8:int64(1490821626691555779)};
>>
>> > }{DeliveryProperties: routing-key=; }}]
>> > 2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
>> > -172.21.0.254:5672]]: Frame[Eb; channel=1; content (65523 bytes)
>> > ...]
>> > 2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
>> > -172.21.0.254:5672]]: Frame[E; channel=1; content (65523 bytes)
>> > ...]
>>
>> Is that all the output? Does qpid-send terminate or just hangs? Is there
>> anything on the broker logs?
>>
>>
>> -
>> To unsubscribe, e-mail: [hidden email]
>> 
>> For additional commands, e-mail: [hidden email]
>> 
>>
>>
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://qpid.2158936.n2.nabble.com/qpid-cpp-1-35-Cannot-sent-
>> large-message-320K-tp7661623p7661650.html
>> To unsubscribe from qpid-cpp-1.35 - Cannot sent large message (320K), click
>> here
>> 
>> .
>> NAML
>> 
>>
>


broker.log (16K) 





--
View this message in context: 
http://qpid.2158936.n2.nabble.com/qpid-cpp-1-35-Cannot-sent-large-message-320K-tp7661623p7661662.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

Re: [Java Broker - 6.0.4] Dojo toolkit dependency

[Rob Godfrey]

Are you talking dojo itself, or the fact that the http-management plugin
also notes that it "This bundles portions of crypto-js, which is under the
MIT licence".

The only "cryptographic functions" used within the web console are those
necessary to implement the necessary SASL authentication mechanisms.  In
particular SHA-1, SHA-256 (and for historical reasons MD5) hashing.  There
is no encryption used within the console (other than TLS through the
standard browser mechanism).  The use of crypto-js code was because dojo
didn't have an implementation of the necessary HMAC mechanisms for SHA-1 /
SHA-256 if I remember correctly.  (See https://tools.ietf.org/html/rfc5802
and https://tools.ietf.org/html/rfc7677 for details of the SCRAM-SHA* SASL
mechanisms).

Hope this helps,
Rob



On 29 March 2017 at 21:17, Adel Boutros  wrote:

> Hello,
>
>
> While our legal team was reviewing the Broker's packaged dependencies and
> their licenses, they had some questions regarding Dojo toolkit materials
> which I hope you can help me with:
>
>
> * Could you please list all cryptographic means contained in the dojo
> materials used?
>
>
> * Could you please describe:
>
> 1) the purpose(s) for which the dojo materials use these cryptographic
> means
>
> 2) whether these means will be accessible to end users
>
>
> * Why is this dependency needed and could we omit it from distribution?
>
>
> Regards,
>
> Adel
>

Re: qpid-cpp-1.35 - Cannot sent large message (320K)

[sivasnp]

The qpid-send just hangs. I have to terminate it.

I did a qpid-stat -q on the queue at the broker and did not see any new
messages

I did not enable the qpid-broker logs. I will enable it and sent that to
you in an hour.

Thanks,
Siva

On Wed, Mar 29, 2017 at 4:32 PM Gordon Sim [via Qpid] <
ml-node+s2158936n7661650...@n2.nabble.com> wrote:

> On 29/03/17 22:10, sivasnp wrote:
> > Please see the output of
> >
> > qpid-send -b 172.21.0.254 --address amq.fanout --content-size 50
> > --log-enable trace+
>
> [...]
>
> > 2017-03-29 21:07:06 [Network] trace RECV [[10.0.3.219:51830
> > -172.21.0.254:5672]]: Frame[BEbe; channel=1; {SessionCompletedBody:
> > commands={ [0,2] }; }]
> > 2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
> > -172.21.0.254:5672]]: Frame[Bbe; channel=1; {MessageTransferBody:
> > destination=amq.fanout; accept-mode=1; acquire-mode=0; }]
> > 2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
> > -172.21.0.254:5672]]: Frame[be; channel=1; header (66 bytes);
> > properties={{MessageProperties: content-length=50;
> > content-type=text/plain; user-id=;
> > application-headers={sn:F4:uint32(1),ts:F8:int64(1490821626691555779)};
> > }{DeliveryProperties: routing-key=; }}]
> > 2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
> > -172.21.0.254:5672]]: Frame[Eb; channel=1; content (65523 bytes)
> > ...]
> > 2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
> > -172.21.0.254:5672]]: Frame[E; channel=1; content (65523 bytes)
> > ...]
>
> Is that all the output? Does qpid-send terminate or just hangs? Is there
> anything on the broker logs?
>
>
> -
> To unsubscribe, e-mail: [hidden email]
> 
> For additional commands, e-mail: [hidden email]
> 
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://qpid.2158936.n2.nabble.com/qpid-cpp-1-35-Cannot-sent-large-message-320K-tp7661623p7661650.html
> To unsubscribe from qpid-cpp-1.35 - Cannot sent large message (320K), click
> here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://qpid.2158936.n2.nabble.com/qpid-cpp-1-35-Cannot-sent-large-message-320K-tp7661623p7661651.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

Re: qpid-cpp-1.35 - Cannot sent large message (320K)

[Gordon Sim]

On 29/03/17 22:10, sivasnp wrote:

Please see the output of

qpid-send -b 172.21.0.254 --address amq.fanout --content-size 50
--log-enable trace+


[...]


2017-03-29 21:07:06 [Network] trace RECV [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=1; {SessionCompletedBody:
commands={ [0,2] }; }]
2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[Bbe; channel=1; {MessageTransferBody:
destination=amq.fanout; accept-mode=1; acquire-mode=0; }]
2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[be; channel=1; header (66 bytes);
properties={{MessageProperties: content-length=50;
content-type=text/plain; user-id=;
application-headers={sn:F4:uint32(1),ts:F8:int64(1490821626691555779)};
}{DeliveryProperties: routing-key=; }}]
2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[Eb; channel=1; content (65523 bytes)
...]
2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[E; channel=1; content (65523 bytes)
...]


Is that all the output? Does qpid-send terminate or just hangs? Is there 
anything on the broker logs?



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

Re: [Proton C++ 0.16.0] Reconnect and reconnect timer

[Rob Godfrey]

Hi Adel,

That error would be coming from the Java Broker... what this normally means
is that the Virtual Host inside the broker is not currently active ... this
may just be something like sending the message before the broker is
completely started... Because each virtual host has its own lifecycle and
can be stopped and started independently of the port listener, the fact
that the port is up doesn't actually mean the virtual host has finished
started.

-- Rob
On Wed, 29 Mar 2017 at 21:23, Adel Boutros  wrote:

> Thank you Alan,
>
>
> As discussed with Andrew offline, we will develop our own reconnect
> strategy as we need it to handle all possible scenarios, examples:
>
> * Failure while establishing connection
>
> * Failure while sending a message
>
> * Failure while receiving a message
>
> and by failure we mean any failure regarding a lost connection.
>
>
> While testing our work, we noticed very rarely we were receiving the below
> exception. Do you know what it is about and how we should handle it?
>
>
> amqp:connection:forced:amqp:connection:forced:
> org.apache.qpid.server.virtualhost.VirtualHostUnavailableException:
> Virtualhost state UNAVAILABLE prevents the message from being sent
>
>
> Regards,
>
> Adel
>
> 
> From: Alan Conway 
> Sent: Friday, March 24, 2017 2:47:56 PM
> To: users@qpid.apache.org
> Subject: Re: [Proton C++ 0.16.0] Reconnect and reconnect timer
>
> On Fri, 2017-03-17 at 17:21 +0100, Rabih M wrote:
> > Hello,
> >
> > Bit of context:
> > I am trying to implement a connection retry mechanism using proton. A
> > bit
> > similar to the failover Url in JMS...
> >
> > I discovered that we can set "reconnect" option in the
> > connection_options.reconnect(reconnect_timer).
> >
> > There are no clear documentation, how does this option behaves?
> > Does it try to reconnect only at connection start? and does it try to
> > reconnect in the middle of an Amqp communication (after
> > sending/receiving
> > some messages)?
> >
> > On the other side, how to know that the max retries or dead line
> > timeout is
> > reached?
> >
>
> See include/proton/reconnect_timer.hpp for the things you can
> configure. This is still an "experimental" feature and could use some
> rounding out - your experience can be helpful with that.
>
> Currently this will reconnect on an unexpected disconnect - that is to
> say on_transport_closed() occurs before on_connection_closed()
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: qpid-cpp-1.35 - Cannot sent large message (320K)

[sivasnp]

Please see the output of

qpid-send -b 172.21.0.254 --address amq.fanout --content-size 50
--log-enable trace+

2017-03-29 21:07:06 [Messaging] debug Trying versions amqp0-10, amqp1.0
2017-03-29 21:07:06 [Client] debug Starting connection, urls=[172.21.0.254]
2017-03-29 21:07:06 [Client] info Trying to connect to 172.21.0.254...
2017-03-29 21:07:06 [Client] debug Created IO thread: 0
2017-03-29 21:07:06 [Network] debug TCPConnector created for 0-10
2017-03-29 21:07:06 [Client] debug Set TCP_NODELAY
2017-03-29 21:07:06 [System] info Connecting: 172.21.0.254:5672
2017-03-29 21:07:06 [Client] debug RECV [[10.0.3.219:51830-172.21.0.254:5672]]:
INIT(0-10)
2017-03-29 21:07:06 [Network] trace RECV [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=0; {ConnectionStartBody:
server-properties={qpid.federation_tag:V2:36:str16(40671cbf-c4e3-4eab-a740-2f1ae110ca63)};
mechanisms=str16{V2:9:str16(ANONYMOUS), V2:5:str16(PLAIN)};
locales=str16{V2:5:str16(en_US)}; }]
2017-03-29 21:07:06 [Security] debug CyrusSasl::start(ANONYMOUS PLAIN)
2017-03-29 21:07:06 [Security] debug min_ssf: 0, max_ssf: 256
2017-03-29 21:07:06 [Security] debug CyrusSasl::start(ANONYMOUS PLAIN):
selected ANONYMOUS response: 'anonymous@S-001'
2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=0; {ConnectionStartOkBody:
client-properties={qpid.client_pid:F4:int32(2031),qpid.client_ppid:F4:int32(339),qpid.client_process:V2:9:str16(qpid-send),qpid.session_flow:F4:int32(1)};
mechanism=ANONYMOUS; response=xx; locale=en_US; }]
2017-03-29 21:07:06 [Network] trace RECV [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=0; {ConnectionTuneBody:
channel-max=32767; max-frame-size=65535; heartbeat-min=0;
heartbeat-max=120; }]
2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=0; {ConnectionTuneOkBody:
channel-max=32767; max-frame-size=65535; heartbeat=0; }]
2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=0; {ConnectionOpenBody:
virtual-host=; capabilities=void{}; insist=1; }]
2017-03-29 21:07:06 [Network] trace RECV [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=0; {ConnectionOpenOkBody:
known-hosts=str16{}; }]
2017-03-29 21:07:06 [Client] info Connection [10.0.3.219:51830-
172.21.0.254:5672] connected to tcp:172.21.0.254:5672
2017-03-29 21:07:06 [Client] debug Connection [10.0.3.219:51830-
172.21.0.254:5672] no security layer in place
2017-03-29 21:07:06 [Client] info Connected to 172.21.0.254
2017-03-29 21:07:06 [Client] debug Added known-hosts,
reconnect-urls=[172.21.0.254]
2017-03-29 21:07:06 [Client] debug Connection successful,
urls=[172.21.0.254]
2017-03-29 21:07:06 [Broker] debug SessionState::SessionState .: 0xcefe38
2017-03-29 21:07:06 [Client] debug Known-brokers for connection:
2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=1; {SessionAttachBody:
name=c7a09332-6d50-49db-b9e8-4ea9b90afbec; }]
2017-03-29 21:07:06 [Network] trace RECV [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=1; {SessionAttachedBody:
name=c7a09332-6d50-49db-b9e8-4ea9b90afbec; }]
2017-03-29 21:07:06 [Network] trace RECV [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=1; {SessionCommandPointBody:
command-id=0; command-offset=0; }]
2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=1; {SessionRequestTimeoutBody:
timeout=0; }]
2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=1; {SessionCommandPointBody:
command-id=0; command-offset=0; }]
2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=1; {ExecutionSyncBody: }]
2017-03-29 21:07:06 [Network] trace RECV [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=1; {SessionTimeoutBody:
timeout=0; }]
2017-03-29 21:07:06 [Network] trace RECV [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=1; {SessionCompletedBody:
commands={ [0,0] }; }]
2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=1; {ExchangeBoundBody:
exchange=amq.fanout; queue=amq.fanout; binding-key=; arguments={}; }]
2017-03-29 21:07:06 [Network] trace RECV [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=1; {ExecutionResultBody:
command-id=1; value=\x07\x02\x02\x00; }]
2017-03-29 21:07:06 [Client] debug treating target address as topic:
amq.fanout
2017-03-29 21:07:06 [Network] trace RECV [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=1; {SessionCompletedBody:
commands={ [0,1] }; }]
2017-03-29 21:07:06 [Network] trace SENT [[10.0.3.219:51830
-172.21.0.254:5672]]: Frame[BEbe; channel=1; {ExchangeDeclareBody:
exchange=amq.fanout; type=; alternate-exchange=; passive=1; arguments={}; }]
2017-03-29 21:07:06 [Network] trace RECV [[10.0.3.219:51830
-172.21.0.254:5672]]: 

Re: qpid-cpp-1.35 - Cannot sent large message (320K)

[Gordon Sim]

On 29/03/17 20:34, sivasnp wrote:

Hi Gordon,
  Thank you for the response.

What broker are you sending to?
   I am trying to sent to a remote broker (version 0.24, unfortunately,
I cannot update the version).
Have you tried with a larger frame size?
  Yes, I have, the result is same.


Does your qpid-cpp package include qpid-send? If so could you get a 
protocol trace for:


  qpid-send -b  --address amq.fanout --content-size 
50 --log-enable trace+


(You can use a different address if needed for any reason).

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

Re: qpid-cpp-1.35 - Cannot sent large message (320K)

[sivasnp]

I don't know, if it helps... The client application is running inside
lxc-container (ubuntu xenial 16.04) and the broker runs in CentOS.

Thanks,
Siva.

On Wed, Mar 29, 2017 at 2:25 PM, Gordon Sim [via Qpid] <
ml-node+s2158936n7661639...@n2.nabble.com> wrote:

> On 29/03/17 17:20, sivasnp wrote:
>
> > Hi,
> >   qpid-client is unable to send a message of size 320K. But a small size
> > message (10K) is sent without any problem
> >
> >  Following are the options, I set while connecting to the broker.
> >
> >options["reconnect"] = true;
> >   options["max_frame_size"] = 1370;
> >options["bounds"] = 33;
> >
> > Initially I did not have the bounds option set. Without bounds option
> set,
> > when I try to send this message, the send() function hangs and never
> > returns.
>
> What broker are you sending to? It seems to work for me (even for much
> larger messages) against qpidd.
>
> Have you tried with a larger frame size?
>
>
> -
> To unsubscribe, e-mail: [hidden email]
> 
> For additional commands, e-mail: [hidden email]
> 
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://qpid.2158936.n2.nabble.com/qpid-cpp-1-35-Cannot-sent-
> large-message-320K-tp7661623p7661639.html
> To unsubscribe from qpid-cpp-1.35 - Cannot sent large message (320K), click
> here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://qpid.2158936.n2.nabble.com/qpid-cpp-1-35-Cannot-sent-large-message-320K-tp7661623p7661642.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

Re: qpid-cpp-1.35 - Cannot sent large message (320K)

[sivasnp]

Hi Gordon,
  Thank you for the response.

What broker are you sending to?
   I am trying to sent to a remote broker (version 0.24, unfortunately,
I cannot update the version).
Have you tried with a larger frame size?
  Yes, I have, the result is same.

Thanks again for your help
Siva

On Wed, Mar 29, 2017 at 2:25 PM, Gordon Sim [via Qpid] <
ml-node+s2158936n7661639...@n2.nabble.com> wrote:

> On 29/03/17 17:20, sivasnp wrote:
>
> > Hi,
> >   qpid-client is unable to send a message of size 320K. But a small size
> > message (10K) is sent without any problem
> >
> >  Following are the options, I set while connecting to the broker.
> >
> >options["reconnect"] = true;
> >   options["max_frame_size"] = 1370;
> >options["bounds"] = 33;
> >
> > Initially I did not have the bounds option set. Without bounds option
> set,
> > when I try to send this message, the send() function hangs and never
> > returns.
>
> What broker are you sending to? It seems to work for me (even for much
> larger messages) against qpidd.
>
> Have you tried with a larger frame size?
>
>
> -
> To unsubscribe, e-mail: [hidden email]
> 
> For additional commands, e-mail: [hidden email]
> 
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://qpid.2158936.n2.nabble.com/qpid-cpp-1-35-Cannot-sent-
> large-message-320K-tp7661623p7661639.html
> To unsubscribe from qpid-cpp-1.35 - Cannot sent large message (320K), click
> here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://qpid.2158936.n2.nabble.com/qpid-cpp-1-35-Cannot-sent-large-message-320K-tp7661623p7661641.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0

[Olivier Mallassi]

To complement and certainly explain the need, We would like urls like
amqp://ip:port/domain/subdomain1/queueA or
amqp://ip:port/domain/subdomain2/queueB
 + use routing capabilities to route queueA, queueB on different brokers or
even queueA to brokers and queueB to another dispatch-router (e.g. for
external integration)

I did some really quick and basic tests using the dispatch-router.
§ qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink
addr=/domain/subdomain/queueA dir=in connection=broker3
§ sending / receiving messaging using the simple_recv/send.py scripts.

It appears that the messages are well published / consumed. sounds correct
to you?

yet (and this is not really important), the qdstat displays weird labels

mobile  queue.first0   0  0   00
0 00

  local   temp.2ndwYNc5ZaHaD2O   1  0   0
00 00

  unknown: s  ubdomain/queueA1  0   200
200  0 00

  unknown: s  ubdomain/queueA0  0   0
00 00

version used: dispatch-router 0.7.0


On Wed, Mar 29, 2017 at 12:15 PM, Rob Godfrey 
wrote:

> On 29 March 2017 at 11:48, Ted Ross  wrote:
>
> >
> >
> > On 03/08/2017 02:33 PM, Alan Conway wrote:
> >
> >> On Fri, 2017-03-03 at 09:58 +, Antoine Chevin wrote:
> >>
> >>> Hello,
> >>>
> >>> Do you have an idea on the below behavior?
> >>>
> >>
> >> This is related to early drafts of the AMQP addressing specification,
> >> but those are out of date now and the specification is still not
> >> released.
> >>
> >> Given that, I think this behavior is probably not helpful - dispatch
> >> should accept address exactly as provided by the user and do no
> >> modification. I'm not 100% sure if that would cause any internal
> >> problems for the router, if not we should raise an issue.
> >>
> >> Ted do you have any thoughts?
> >>
> >
> > Dispatch normalizes addresses to make sure that various "equivalent"
> forms
> > are hashed to the same entry in the address table.
> >
> > As Alan pointed out, we use a URL-like address format per early drafts of
> > the addressing specification.  As such, the leading slash is removed from
> > the normalized address.
> >
> >
> What are the normalization rules, and why is dispatch assuming that
> removing a leading slash is correct (since in this case it is not - the
> Java Broker does its own normalization - and if you want you can query it
> and find out what prefixes it considers equivalent)?
>
> -- Rob
>
>
> >
> >
> >>
> >>> Thank you,
> >>> Regards,
> >>> Antoine
> >>>
> >>> -Original Message-
> >>> From: Antoine Chevin [mailto:antoine.che...@gmail.com]
> >>> Sent: jeudi 2 mars 2017 10:43
> >>> To: users@qpid.apache.org
> >>> Subject: Configuring addresses starting with '/' on qpid-dispatch
> >>> router
> >>> 0.7.0
> >>>
> >>> Hello,
> >>>
> >>> I tried to configure addresses starting with a '/' but using qdstat I
> >>> see
> >>> that this '/' is removed. Is it expected?
> >>> I noticed the same behavior with autolinks.
> >>>
> >>> Thank you,
> >>> Regards,
> >>> Antoine
> >>>
> >>
> >>
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
> >
>

Re: [Proton C++ 0.16.0] Reconnect and reconnect timer

[Adel Boutros]

Thank you Alan,


As discussed with Andrew offline, we will develop our own reconnect strategy as 
we need it to handle all possible scenarios, examples:

* Failure while establishing connection

* Failure while sending a message

* Failure while receiving a message

and by failure we mean any failure regarding a lost connection.


While testing our work, we noticed very rarely we were receiving the below 
exception. Do you know what it is about and how we should handle it?


amqp:connection:forced:amqp:connection:forced: 
org.apache.qpid.server.virtualhost.VirtualHostUnavailableException: Virtualhost 
state UNAVAILABLE prevents the message from being sent


Regards,

Adel


From: Alan Conway 
Sent: Friday, March 24, 2017 2:47:56 PM
To: users@qpid.apache.org
Subject: Re: [Proton C++ 0.16.0] Reconnect and reconnect timer

On Fri, 2017-03-17 at 17:21 +0100, Rabih M wrote:
> Hello,
>
> Bit of context:
> I am trying to implement a connection retry mechanism using proton. A
> bit
> similar to the failover Url in JMS...
>
> I discovered that we can set "reconnect" option in the
> connection_options.reconnect(reconnect_timer).
>
> There are no clear documentation, how does this option behaves?
> Does it try to reconnect only at connection start? and does it try to
> reconnect in the middle of an Amqp communication (after
> sending/receiving
> some messages)?
>
> On the other side, how to know that the max retries or dead line
> timeout is
> reached?
>

See include/proton/reconnect_timer.hpp for the things you can
configure. This is still an "experimental" feature and could use some
rounding out - your experience can be helpful with that.

Currently this will reconnect on an unexpected disconnect - that is to
say on_transport_closed() occurs before on_connection_closed()



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

Re: qpid-cpp-1.35 - Cannot sent large message (320K)

[Gordon Sim]

On 29/03/17 17:20, sivasnp wrote:

Hi,
  qpid-client is unable to send a message of size 320K. But a small size
message (10K) is sent without any problem

 Following are the options, I set while connecting to the broker.

   options["reconnect"] = true;
  options["max_frame_size"] = 1370;
   options["bounds"] = 33;

Initially I did not have the bounds option set. Without bounds option set,
when I try to send this message, the send() function hangs and never
returns.


What broker are you sending to? It seems to work for me (even for much 
larger messages) against qpidd.


Have you tried with a larger frame size?


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

[Java Broker - 6.0.4] Dojo toolkit dependency

[Adel Boutros]

Hello,


While our legal team was reviewing the Broker's packaged dependencies and their 
licenses, they had some questions regarding Dojo toolkit materials which I hope 
you can help me with:


* Could you please list all cryptographic means contained in the dojo materials 
used?


* Could you please describe:

1) the purpose(s) for which the dojo materials use these cryptographic means

2) whether these means will be accessible to end users


* Why is this dependency needed and could we omit it from distribution?


Regards,

Adel

qpid-cpp-1.35 - Cannot sent large message (320K)

[sivasnp]

Hi,
  qpid-client is unable to send a message of size 320K. But a small size
message (10K) is sent without any problem

 Following are the options, I set while connecting to the broker.

   options["reconnect"] = true;
  options["max_frame_size"] = 1370;
   options["bounds"] = 33;

Initially I did not have the bounds option set. Without bounds option set,
when I try to send this message, the send() function hangs and never
returns.

After bounds options is set, the sender returns immediately, but the actual
message is not send to the receiver.

Packet capture shows that the first frame( 1490 bytes) is sent, but
remaining is not sent.

Please help. I am using qpid on ubuntu xenial.

Please let me know, if I am missing something. I can update the logs if
necessary.

Thanks,
Siva.




--
View this message in context: 
http://qpid.2158936.n2.nabble.com/qpid-cpp-1-35-Cannot-sent-large-message-320K-tp7661623.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

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

Qpid Dispatch Router 0.8.0 Release Candidate 1

[Ted Ross]

The first release candidate for Qpid Dispatch Router 0.8.0 is ready for 
evaluation.


Build Artifacts:

https://dist.apache.org/repos/dist/dev/qpid/dispatch/0.8.0-rc1/

New Features:

DISPATCH-103 - Websocket Listeners
DISPATCH-195 - Add support for transactional messages in the Router
DISPATCH-441 - Support password environment variable in qdrouter config
DISPATCH-467 - Terminus renaming for autoLinks
DISPATCH-529 - Address annotation for Multi-Tenancy
DISPATCH-726 - Connection Property for Failover Servers

Improvements:

DISPATCH-113 - expose NodeTracker::last_topology_change in management
DISPATCH-542 - Popup text for clients should indicate if the client 
is a sender or receiver
DISPATCH-543 - Initial load of topology page fetches too much 
information
DISPATCH-544 - Add ability to hide the info panel on the left of 
the topology page
DISPATCH-552 - Allow only one tree node to be expanded if there is 
a large number of routers
DISPATCH-553 - Add statistic counter to the "log" entity to count 
log events per severity
DISPATCH-559 - qdstat - Request only the columns that will be used 
in the display

DISPATCH-561 - Create python program that returns fake management data
DISPATCH-568 - Iterator module cleanup
DISPATCH-570 - Add some counts to qdstat -g
DISPATCH-572 - Adding log info with proton transport id and related 
remote IP/port

DISPATCH-576 - Use new log entity statistic counter in console
DISPATCH-578 - Dispatch trace logging forces all proton tracing on
DISPATCH-579 - Expose software version via management
DISPATCH-592 - Attempt to auto-login to the host:port that served 
the web page

DISPATCH-597 - Log enhancements
DISPATCH-600 - Support secure websockets
DISPATCH-602 - Add a favicon to the stand-alone router site
DISPATCH-606 - Default session window is too small, causing 
performance bottlenecks
DISPATCH-627 - BatchedSettlement test fails with timeout on slower 
systems
DISPATCH-629 - Add a protocol-version to the inter-router protocol 
to enable backward compatibility

DISPATCH-641 - Make containerId attribute work with clients

Bugs Fixed:

DISPATCH-55 - Qdrouterd does not exit when service port is unavailable
DISPATCH-216 - system_tests_protocol_family fails on systems with 
no IPv6

DISPATCH-296 - segfault on router startup
DISPATCH-301 - Some unit tests fail with workerThreads are set to 4
DISPATCH-314 - If a router has a normal listener, show it in a 
different color on the topology page

DISPATCH-324 - Improve initial layout of topology node
DISPATCH-344 - memory growth after repeated calls from qdstat -m
DISPATCH-352 - Crash with empty configuration file
DISPATCH-355 - query fails with what seems to be the error of a 
previous command
DISPATCH-357 - Address field is empty for link routed links in the 
qdstat "links" output
DISPATCH-433 - Navigating to console from bookmark displays empty 
page with just toolbars
DISPATCH-451 - [AMQP] Hard coded session capacity should be 
configurable
DISPATCH-503 - [display_name] successful test runs  have non-ascii 
characters in router log
DISPATCH-504 - [display_name] successful test runs have invalid 
message errors  in router log
DISPATCH-506 - Detach with no "error" sent by router on client TCP 
connection dropped
DISPATCH-516 - Core dump when displayname IO adapter receives 
message with no reply-to
DISPATCH-526 - Coverity scan reported memory leaks in Qpid Dispatch 
0.7.0
DISPATCH-527 - The $displayname address is currently available. It 
should not be available to external users

DISPATCH-530 - Cannot connect using Firefox 48+
DISPATCH-534 - Node selection and location is lost when the 
topology changes
DISPATCH-536 - Circular buffer overflow errors occur when there are 
a large number of routers
DISPATCH-538 - Highlighted path between routers sometimes doesn't 
unhighlight
DISPATCH-540 - Clients with both in and out links are rendered in 
yellow

DISPATCH-541 - Highlighted path between routers contains black arrows
DISPATCH-546 - Crosssection popup position is incorrect
DISPATCH-547 - Stand-alone version can't download generated config 
file for new nodes
DISPATCH-554 - Topology nodes and links are too far apart when 
there are a large number of routers

DISPATCH-556 - qdstat fails at high scale
DISPATCH-557 - High connection rates cause problems in the Python 
management agent
DISPATCH-560 - [console] Only use the color red to indicate a 
failure/issue.
DISPATCH-563 - Topology graph flashes and redraws a few seconds 
after it is 1st drawn

DISPATCH-564 - Error when switching routers on Entities page
DISPATCH-565 - Error fetching log on Entities page
DISPATCH-566 - Message annotations are not propagated to brokers on 
a linkRoute
DISPATCH-567 - Slight but persistent memory leak when run

Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0

[Rob Godfrey]

On 29 March 2017 at 11:48, Ted Ross  wrote:

>
>
> On 03/08/2017 02:33 PM, Alan Conway wrote:
>
>> On Fri, 2017-03-03 at 09:58 +, Antoine Chevin wrote:
>>
>>> Hello,
>>>
>>> Do you have an idea on the below behavior?
>>>
>>
>> This is related to early drafts of the AMQP addressing specification,
>> but those are out of date now and the specification is still not
>> released.
>>
>> Given that, I think this behavior is probably not helpful - dispatch
>> should accept address exactly as provided by the user and do no
>> modification. I'm not 100% sure if that would cause any internal
>> problems for the router, if not we should raise an issue.
>>
>> Ted do you have any thoughts?
>>
>
> Dispatch normalizes addresses to make sure that various "equivalent" forms
> are hashed to the same entry in the address table.
>
> As Alan pointed out, we use a URL-like address format per early drafts of
> the addressing specification.  As such, the leading slash is removed from
> the normalized address.
>
>
What are the normalization rules, and why is dispatch assuming that
removing a leading slash is correct (since in this case it is not - the
Java Broker does its own normalization - and if you want you can query it
and find out what prefixes it considers equivalent)?

-- Rob


>
>
>>
>>> Thank you,
>>> Regards,
>>> Antoine
>>>
>>> -Original Message-
>>> From: Antoine Chevin [mailto:antoine.che...@gmail.com]
>>> Sent: jeudi 2 mars 2017 10:43
>>> To: users@qpid.apache.org
>>> Subject: Configuring addresses starting with '/' on qpid-dispatch
>>> router
>>> 0.7.0
>>>
>>> Hello,
>>>
>>> I tried to configure addresses starting with a '/' but using qdstat I
>>> see
>>> that this '/' is removed. Is it expected?
>>> I noticed the same behavior with autolinks.
>>>
>>> Thank you,
>>> Regards,
>>> Antoine
>>>
>>
>>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: [DISCUSS] release checksum filename extension

[Robbie Gemmell]

Just to close the loop on this, infra have updated the dist.apache.org
config to have the files present as text/plain, as they do on
www.apache.org, which lets them work in firefox without us needing to
play with the svn mime types.

On 10 March 2017 at 17:16, Robbie Gemmell  wrote:
> I decided to set the svn:mime-type to text/plain for the
> qpid-jms-0.21.0 release files I just added. It turns out that is what
> gets used on the main www.apache.org webserver once they are
> eventually released, and the issue only applies on the dist.apache.org
> webserver fronting the svn dist repo.
>
> Robbie
>
> On 10 March 2017 at 12:22, Robbie Gemmell  wrote:
>> As noted in the vote thread, the webserver presenting the svn dist
>> repo is seemingly mishhandling the .sha files and this leads to
>> Firefox saving a gzip encoded version of the checksum. This is raised
>> as https://issues.apache.org/jira/browse/INFRA-13629
>>
>> Hopefully it can be fixed webserver side, but in the mean time setting
>> a mime type on the file in the svn repo makes the webserver pick it up
>> and act differently, and this gets things working in Firefox. I used
>> the following for the proton-j 0.18.0 release checksums:
>> svn propset svn:mime-type application/x-sha2 *.sha
>>
>> If needed, we can use some svn client config to do that automatically
>> in future. If folks use a recent enough svn client it can actually be
>> propset in the repo and clients will pick it up and action it.
>>
>> On 7 March 2017 at 23:24, Robbie Gemmell  wrote:
>>> Thats probably where the key difference lies - I dont have the general
>>> shasum, only specific sha[1|224|256|384|512]sum variants that do
>>> complain when given the 'wrong' thing. I'm long overdue an update to
>>> an up to date OS so that probably explains that. It makes sense they
>>> should be able to look at whats there and attempt to verify as seems
>>> appropriate.
>>>
>>> My suggestion to change wasnt really to say that there is an implied
>>> particular choice for .sha, just that given we are changing things we
>>> should make them consistent the distribution policy and each other
>>> while doing so.
>>>
>>> On 7 March 2017 at 23:04, Justin Ross  wrote:
 I will change the qpid-python .sha file to SHA-512.  And I wouldn't have
 objected to using .sha512 if Robbie had felt like going against the grain.

 FWIW, before I made the change to SHA-256 and .sha, I tested that Fedora's
 'shasum' does not require extra options to check such files.  It seems to
 figure it out on its own.  In some cursory poking around, I haven't found
 anything that says .sha indicates any particular SHA hash function.

 On Tue, Mar 7, 2017 at 10:19 AM, Robbie Gemmell 
 wrote:

> ;)
>
> I decided to go with the guideline and created a SHA512 file with .sha
> extension. We can make it clear on the website that its SHA512. Folks
> doing it blind will just have to try it, or look at the content to
> figure it out.
>
> Given the name is 'correct', I'd probably regenerate the qpid-python
> checksum using SHA512. We could also just leave it alone this time
> since it only says you SHOULD use SHA512.
>
> On 7 March 2017 at 18:05, Rob Godfrey  wrote:
> > To be fair that page says nothing about how to name SHA256 checksums 
> > :-),
> > only that we SHOULD be creating SHA512 checksums named .sha.
> >
> > So, I'm +1 on naming the SHA256 .sha256 ... and it seems like the Python
> > release really shouldn't name a SHA256 file .sha as by the above that
> > extension should be reserved for SHA512.
> >
> > -- Rob
> >
> > On 7 March 2017 at 18:34, Timothy Bish  wrote:
> >
> >> On 03/07/2017 12:23 PM, Robbie Gemmell wrote:
> >>
> >>> According to http://www.apache.org/dev/release-distribution.html#sigs-
> >>> and-sums
> >>> .sha is actually required:
> >>>
> >>> "An SHA checksum SHOULD also be created and MUST be suffixed .sha. The
> >>> checksum SHOULD be generated using SHA512."
> >>>
> >>> I find the extension a little unhelpful personally, but ok.. :)
> >>>
> >>
> >> I would have voted for .sha256 for clarity
> >>
> >>
> >>> Robbie
> >>>
> >>> On 7 March 2017 at 17:11, Robbie Gemmell 
> >>> wrote:
> >>>
>  Hi folks,
> 
>  I noted in the qpid-python-1.36.0 vote thread that the .sha file
>  contained a sha256 checksum, this being in place of the historic 
>  .sha1
>  checksum file.
> 
>  I'm curious what people think about the name relative to the 
>  contents?
>  I think .sha256 might be friendlier so that people know how to try 
>  and
>  verify it implicitly from its name?
> 
>  I mainly ask as I think I'll include one for the proton-j-0.18.0
>  release im about to cut, and am trying to settle on a n

Re: Configuring addresses starting with '/' on qpid-dispatch router 0.7.0

[Ted Ross]

On 03/08/2017 02:33 PM, Alan Conway wrote:

On Fri, 2017-03-03 at 09:58 +, Antoine Chevin wrote:

Hello,

Do you have an idea on the below behavior?


This is related to early drafts of the AMQP addressing specification,
but those are out of date now and the specification is still not
released.

Given that, I think this behavior is probably not helpful - dispatch
should accept address exactly as provided by the user and do no
modification. I'm not 100% sure if that would cause any internal
problems for the router, if not we should raise an issue.

Ted do you have any thoughts?


Dispatch normalizes addresses to make sure that various "equivalent" 
forms are hashed to the same entry in the address table.


As Alan pointed out, we use a URL-like address format per early drafts 
of the addressing specification.  As such, the leading slash is removed 
from the normalized address.






Thank you,
Regards,
Antoine

-Original Message-
From: Antoine Chevin [mailto:antoine.che...@gmail.com]
Sent: jeudi 2 mars 2017 10:43
To: users@qpid.apache.org
Subject: Configuring addresses starting with '/' on qpid-dispatch
router
0.7.0

Hello,

I tried to configure addresses starting with a '/' but using qdstat I
see
that this '/' is removed. Is it expected?
I noticed the same behavior with autolinks.

Thank you,
Regards,
Antoine




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