Re: Why performance of sending durable messages to qpid queue is really bad?

[smartdog]

This probably does not matter. I think legacystore.so is the one that is
working.



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Why-performance-of-sending-durable-messages-to-qpid-queue-is-really-bad-tp7609368p7609543.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

Re: Why performance of sending durable messages to qpid queue is really bad?

[smartdog]

Thanks for that. After changing it from 500 to 10, I am able to get 20ms
latency for a send. Pretty cool.

But I cannot reproduce it on another machine, i.e. after I copied the
rebuilt qpidd executable with reduced timeout to another machine, the
latency is still 1000ms on that machine, unless I rebuild qpidd on that
machine, then all qpidd executables have 20ms latency.

So I guess the build process changed something only on the machine, not the
qpidd executable, legacystore.so, etc. How to work around this because we
don't want to build qpidd from src on every machine.



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Why-performance-of-sending-durable-messages-to-qpid-queue-is-really-bad-tp7609368p7609542.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

Project Adverb - Illustrated AMQP decoding for real-world scenarios

[Chuck Rolke]

Please see Project Adverb at https://github.com/ChugR/Adverb.git

You can get to the meat of what I'm trying to present by cloning the repo and 
opening
 ./Adverb/website/index.html

I'm on the verge of creating more examples and more complicated scenarios and 
I'd like some feedback on whether this is worthwhile. What do you think?

Note that I need to give lots of credit to Pavel Moravec for creating the AMQP 
1.0 dissector for Wireshark. Without that this project could not exist. 
Hopefully that dissector will make it to a formal Wireshark release soon.

Regards,
Chuck

---
>From the README
---

Adverb - a project to distill Wireshark trace data into web pages
that expose the AMQP on-the-wire protocol.

OVERVIEW


Real AMQP 1.0 is complicated even in simple interactions.
Hand waving in front of the AMQP 1.0 specification leaves beginners
lost. Presenting simple interactions with selectable levels of
detail is hard. Even with Pavel Moravec's AMQP 1.0 Wireshark 
dissector it's hard to use Wireshark to study the protocol in
detail.

This project tries to show complete AMPQ transaction scenarios
like "Hello World" in complete detail without being overwhelming.

A Wireshark trace is converted into a web page where there is
one line for each AMQP frame on the wire. The line shows the
frame direction (to or from a broker on port 5672) and the
AMQP performatives or methods in that frame. When the frame
is expanded by clicking on the arrow on the left, a new level
of detail is exposed showing: the TCP header; each AMQP item.
These may be expanded in turn showing the complete protocol
detail.

You may go from the triggering command line down to every bit
in every AMQP frame emitted by the messaging libraries and
broker. How things are done and in what order is exposed and
will help you learn AMQP.

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

FW: [amqp-bindmap] 30-day Public Review for Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) Version 1.0 - ends July 19th

[Steve Huston]

I haven’t seen this come around to the Qpid users list, so am forwarding it 
directly.
-Steve

From: amqp-bind...@lists.oasis-open.org 
[mailto:amqp-bind...@lists.oasis-open.org] On Behalf Of Paul Knight
Sent: Thursday, June 19, 2014 4:10 PM
To: tc-annou...@lists.oasis-open.org; memb...@lists.oasis-open.org; 
amqp-bind...@lists.oasis-open.org; a...@lists.oasis-open.org; 
amqp-bindmap-comm...@lists.oasis-open.org
Subject: [amqp-bindmap] 30-day Public Review for Advanced Message Queuing 
Protocol (AMQP) WebSocket Binding (WSB) Version 1.0 - ends July 19th


OASIS members and other interested stakeholders,

The OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings 
(AMQP-BINDMAP) TC [1] members have recently approved a Committee Specification 
Draft (CSD) and submitted it for 30-day public review:

Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) Version 1.0
Committee Specification Draft 01 / Public Review Draft 01
10 June 2014

Overview:

The AMQP WebSocket Binding specification defines a mechanism for tunneling an 
AMQP connection over a WebSocket transport. It is applicable as an approach for 
general firewall tunneling and for Web browser messaging scenarios.

TC Description:

The purpose of the AMQP Bindings and Mappings (AMQP-BINDMAP) TC is to define 
bindings of AMQP 1.0 core protocol to underlying transports other than TCP, to 
define mappings of the AMQP 1.0 core protocol to existing well-known 
programming APIs, and to define representations of the AMQP 1.0 message format 
in existing well-known languages.

For more information, see the TC Charter and FAQ.

Public Review Period:

The public review starts 20 June 2014 at 00:00 GMT and ends 19 July 2014 at 
23:59 GMT.

This is an open invitation to comment. OASIS solicits feedback from potential 
users, developers and others, whether OASIS members or not, for the sake of 
improving the interoperability and quality of its technical work.

URIs:

The prose specification document and related files are available here:

Editable source (Authoritative):
http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd01/amqp-wsb-v1.0-csprd01.doc

HTML:
http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd01/amqp-wsb-v1.0-csprd01.html

PDF:
http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd01/amqp-wsb-v1.0-csprd01.pdf

ZIP distribution file (complete):

For your convenience, OASIS provides a complete package of the prose document 
and related files in a ZIP distribution file. You can download the ZIP file 
here:

http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd01/amqp-wsb-v1.0-csprd01.zip

Additional information about the specification and the OASIS Advanced Message 
Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC can be found at 
the TC's public home page:

https://www.oasis-open.org/committees/amqp-bindmap/

Comments may be submitted to the TC by any person through the use of the OASIS 
TC Comment Facility which can be used by following the instructions on the TC's 
"Send A Comment" page, or directly at:

https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=amqp-bindmap

Comments submitted by TC non-members for this work and for other work of this 
TC are publicly archived and can be viewed at:

https://lists.oasis-open.org/archives/amqp-bindmap-comment/

All comments submitted to OASIS are subject to the OASIS Feedback License, 
which ensures that the feedback you provide carries the same obligations at 
least as the obligations of the TC members. In connection with this public 
review of "Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) 
Version 1.0", we call your attention to the OASIS IPR Policy [2] applicable 
especially [3] to the work of this Technical Committee. All members of the TC 
should be familiar with this document, which may create obligations regarding 
the disclosure and availability of a member's patent, copyright, trademark and 
license rights that read on an approved OASIS specification.

OASIS invites any persons who know of any such claims to disclose these if they 
may be essential to the implementation of the above specification, so that 
notice of them may be posted to the notice page for this TC's work.

== Additional references:

[1] OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings 
(AMQP-BINDMAP) TC
https://www.oasis-open.org/committees/amqp-bindmap/

[2] https://www.oasis-open.org/who/intellectualproperty.php

[3] https://www.oasis-open.org/committees/amqp-bindmap/ipr.php
https://www.oasis-open.org/policies-guidelines/ipr#s10.2.2
RF on RAND Mode

--
Paul Knight  - Tel: +1 781-861-1013
OASIS - Advancing open standards for the 
information society
Document Process Analyst

Re: Why performance of sending durable messages to qpid queue is really bad?

[Kim van der Riet]

On Tue, 2014-06-17 at 14:35 -0700, smartdog wrote:
> load-module=/usr/local/phonefactor/bin/legacystore.so
> load-module=/usr/local/phonefactor/bin/qpid/store/store.so

Do you have *two* stores loaded at the same time?


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

Re: Remove unused routes and links

[Gordon Sim]

On 06/17/2014 05:14 PM, Filipe Santos wrote:

I have this scenario:

Two federated qpid A and B, in different machines, with routes ( and links) 
between them.

Without deleting any configuration I've remove qpid B  and added a qpid C.

 From this moment I couldn't configure qpid C with routes between A and C 
because qpid A was returning an error  complaining the routes between A and B.


Could you give a bot more detail on the steps you took and the error you 
saw?



Routes from A and B couldn't no longer be deleted because A was not finding B 
anymore.
I got stuck until I've reconnected B, erased all the routes and links from A to 
B, removed B, reconnected C and configured C.
Shouldn't it be a way of forcing the deletion of routes without one being 
present?


The fact that certain routes to some other broker are disconnected (due 
to that other broker being offline) should certainly not have any effect 
on adding new routes to a different broker.



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

Re: Why performance of sending durable messages to qpid queue is really bad?

[Gordon Sim]

On 06/19/2014 10:03 PM, smartdog wrote:

I am not sending big messages, just a couple of words. Indeed, I use AMQP
1.0. Then it seems the static 1000ms latency comes from qpid timeout for
waiting more messages to write to the store. Can I adjust the timeout value
in qpid source code? I would be happy if we could reduce it to 100ms for
durable messages.


The timeout is 500ms by default (at least on trunk at present and I 
doubt its changed very recently). To edit it change the value for 
MessageStoreImpl::defJournalFlushTimeout in 
cpp/src/qpid/legacystore/MessageStoreImpl.cpp


(There is a timer task per journal, though at present configured to use 
the same periodicity. So it would be possible without too much work to 
make it configurable on a per queue basis if anyone had the inclination).



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