I found while compiling on RedHat Linux, in a printf that
Property consumer_tag required a char*, not an integer (%s, not %d).
Property scope didn't exist. But queue does.

Keven Miller

When you use a synchronous method (e.g. Basic.Consume), WireAPI waits for the server to respond with a synchronous reply, and it processes this reply.

I think, you meant Basic.Get is synchronous, and not Basic.Consume.

Thanks,
Raman

If I'm not wrong, tcp_nodelay is activated by default isn't it ? (at least this is what the doc is saying)

To demonstrate the issue even more : this morning I had to rollback a change that gone to production with the wrong amq version (1.3d0 instead of good old 1.2c4).
Latency jumped from 2/5msec up to 40/80msec.

1.2c4 was compiled with google's allocator, 1.3d0 did not. I have to say 1.3d0 should not have gone to prod, this was a mistake cause I have had not fully validated it. Also 1.3d0 was not setup to use direct mode. But so far, the testing I have done showed that even with direct mode enabled the latency was not good at all.

Putting these questions in a separate thread would be good. We stopped free support because it was too much work and it's nice to see OpenAMQ users helping each other, this rarely happened before.

We're thinking of moving to a better forum for discussion. Would you use that?

That's interesting. I have observed the same bad latencies with my 1st tests, that also involve sending just a handful of messages around.
I am also using direct mode and it was just local distribution for these tests, I didn't touch the batching parameter. I decided to investigate later about that but now as you're asking …
I would appreciate if pieter can give us a hint about this, but as he decided to cancel (free) support here :-( …

Regards,
Günther

BTW:
I think you should open separate topics/issues for your questions, I feel these threads 'pollute' the WireAPI documentation page in a way.

how can you tune openamq for latency ?

I'm using direct mode with amq 1.3d0 and have this custom wireapi.cfg :
<?xml?>
<config>
<direct batching="0" on_overflow="warn"/>
</config>

If I send only one message without this config file, I see a local roundtrip of 40msec (client, amq and server running local).
If I send only one message with this config file, I see a local roundtrip of 20msec (client, amq and server still running local)

This is way too slow !

When I send several thousands of messages I see a roundtrip of 60microsecs. Which is acceptable.
Most of the time my system will not have so many messages but they need to be delivered fast. I need to remove all the batching so that I can achieve the same kind of low latency roundtrip (60microsecs) with a few messages per seconds.

setting batching=0 both on wireapi.cfg and server does not seem to have the correct effect. Is there anything else I can tune ?

Tx

David

I could use the field table if I could put binary data in it, but it seems like it can hold only strings. So it seems like I cannot use it.

Looking at the source code of amq, I've also found the (undocumented) amq_content_basic_wire_get() which might do what I want, but it seems very low level and I'm not sure it's going to return only content (I'm afraid it could return also protocol content). For example : source comment says it is automatically skipping heartbeat frames. Plus it does not work out of an amq_content but uses an ip_bucket as input.

AFAIK it's not possible to do so. As far I understand your sample 'allocateObject()' does some memory allocation based on the information in the header part, right? So what about putting all your possible 'Object ' structures into a union and just reinterpret(_cast) the part after your header structure appropriately, without extra allocation and copy from the original buffer?

BTW I would recommend you to use Google Protobuf or s.th. alike to define your messages' content. Handling wireable formats can become pretty tricky, especially if you need to interchange stuff between different machine types and using different programming languages to interpret it. Google Protobuf works pretty good for my needs and is easy to use an understand.

HTH
günther

Basic content properties

All contents have these properties, which you can inspect directly using content->propertyname

So the documentation is not consistent and should be fixed.

Also for my other question (partial read) : do you know where to begin ?

Tx

David

It's documented somewhere in the common part, as far I remember, that you should never access any of the WireAPI data structures directly but
use the get/set functions.

WBR
Günther

Should'nt the documentation be fixed to stress that you cannot access directly the properties but you need to call the get_XXX() functions ?

Tx

David

all messages I receive have body_size == 0
There is no method amq_content_basic_set_body_size() while section "Basic content property" (http://www.openamq.org/doc:prog-wireapi/comments/show#toc40) says all properties are settable using amq_content_basic_set_[propertyname] (content, newvalue).

I would have expected the method amq_content_basic_set_body to do it for me but it does not.

Please advise.

Tx

David

pseudo code :
Header header;
amq_content_basic_get_body (content, (byte*)header, sizeof (Header));
Object *o = allocateObject(header);
amq_content_basic_get_body (content, (byte*)o->getBuffer(), o->size());

The idea is I have some dynamic content that is going to transit through AMQ and if I cannot do a partial read, then I'm going to end up doing 2 allocations + 1 memcpy.

pseudo code :
byte buffer[SomeSize]; // first allocation
amq_content_basic_get_body (content, (byte*)buffer, sizeof (buffer));
Header *header = buffer;
Object *o = allocateObject(header); // second allocation
memcpy(o->getBuffer(), header + 1, o->size()); // memcpy

Any idea ?

Tx

David

Correct me if I misunderstood it, but the article states that Basic.Publish is always assynchronous. Is that right? Is there a sync counterpart?

Thanks,
Lac