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

This would make it far more Internet friendly. It would be easier to secure, and to deploy. By deploying many lightweight caching servers across the Internet, messages would potentially have multiple routes to get where they're going, thus mitigating the problem of failure in any one server.

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

Where does the code call snprintf_flush?

I start the applications as follows:

Machine #1

./amq_server —listen 192.168.1.10
./server_time 192.168.1.10 timeserver

Machine #2

./client 192.168.1.10 client

When I type 'cur_time', the client quits with

11:18:53: E: buffer size is zero in smt_socket_request_write_bucket
11:18:53: E: SMT error: Success

What am I doing wrong?

We assume that the connection between partitions is perhaps slow, but reliable. That is, we do not attempt to queue and forward messages in case of a network failure - messages will simply be dropped. Applications that require reliable message transfer must implement end-to-end reliability.

Then the comments Pieter says

communication between exchanges is robust against dropped VPN connections; it will queue messages and forward then when the link comes back up.

This seems directly contradictory. Which is it?

Johnatan

However I'd still advise end-to-end reliability if you are doing request-response patterns across federation, e.g. to access remote services and get answers back. That's simply because a failure in a broker anywhere in the chain can cause messages to be lost.

From your answer I'm not sure whether it means that communication between exchanges already provides reliability and it's only a matter of securing the communication with VPN? Would exchanges between themselves take care of retransmissions if VPN connection breaks? Or is there no inherent possibility to federate exchanges reliably over the Internet?

j.

much appreciate your quick answer.

J.

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.

For end-to-end reliability, for a request-response scenario, store requests in the sender in a database, and mark them as "answered" when responses arrive. Resend if no response arrives within a certain time. At the other end, store incoming requests and outgoing responses, and if a duplicate request arrives, resend the response.

was wondering if you have any suggestions or solutions for federating exchanges over the Internet.

How would one go about implementing 'end-to-end reliability' you mention in 'limitations' section?

Thanks,

John.

Please see the below code. I tried binding a queue to the exchange with routing queue as "#.#". And then i tried consuming form the queue. This caused the AMQ server to crash.

 amq_client_session_queue_bind ( session, // session 0, // ticket session->queue, // queue "amq.topic", // exchange "#.#", // routing-key NULL); // arguments // Consume from the queue amq_client_session_basic_consume ( session, // session 0, // ticket session->queue, // queue NULL, // consumer-tag TRUE, // no-local TRUE, // no-ack FALSE, // exclusive NULL); // arguments 

Please help me out.

Thanks and regards,
Jayadev.

Sorry for posting it in the other place. Actually I was confused regarding the usability of the forum. Yours is a good answer. I appreciate that, but, I am trying to migrate from the existing MoM that is been used in our present system. Most of our user terminals run on Windows, so if my migration need to be successful, I should consider Windows compatibility as well.

Best regards,
Jayadev.

I tried publishing messages from a windows machine in a fast rate (not so fast though) using the C wire API, and I am getting this error at the AMQ server. I tried the same code from a Linux machine and I am not getting this error. What could be the reason?

2009-10-29 19:08:23: E: Connection error: 502 Expected a method frame, closing connection (127.0.0.1:4751, OpenAMQ Kernel Client, 1.4c0, test)

Thanks,
Jayadev.

Without having an answer for your question (besides 'Use Linux then' ;-)), why are you
posting this on this issue, instead of opening a new one?

WBR
Günther

I tried publishing messages from a windows machine in a fast rate (not so fast though) using the C wire API, and I am getting this error at the AMQ server. I tried the same code from a Linux machine and I am not getting this error. What could be the reason?

2009-10-29 19:08:23: E: Connection error: 502 Expected a method frame, closing connection (127.0.0.1:4751, OpenAMQ Kernel Client, 1.4c0, test)

Will be ready in a day or so.

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

Sorry for being harsh, had a bad day then …

Regards,
Günther

and set icl_mem_free() after using in amq_content_set_body()

I think that's not the way it's intended, read the WireAPI spec …
Are you a net vamipre? Ask yourself!

Regards,
Günther

Thanks,
Charan.

I am getting some messages correctly without any problem, but some messages stripping at the end, and sometimes lost, or sometime adding junk data at the end. I am unable to find the reason, Is this might be due to using C++ API?

 (gdb) bt #0 0x00221402 in __kernel_vsyscall () #1 0x0024ac10 in raise () from /lib/libc.so.6 #2 0x0024c521 in abort () from /lib/libc.so.6 #3 0x0024425b in __assert_fail () from /lib/libc.so.6 #4 0x08093206 in amq_consumer_content_hold (self=0xad5ed08, content=0xaf774788) at amq_consumer.c:434 #5 0x0808f23f in amq_queue_basic_dispatch (self=0xabfb528) at amq_queue_basic.c:1012 #6 0x0808fe41 in amq_queue_basic_consumer_ack (self=0xabfb528, consumer=0xad5ed08) at amq_queue_basic.c:659 #7 0x0808a38a in amq_queue_agent_manager (thread_p=0xb56f43a8) at amq_queue_agent.c:4496 #8 0x08178d1c in s_execute (apr_thread=0xa3248b0, data=0xa2fc4d8) at smt_os_thread.c:3216 #9 0x0819fcf6 in dummy_worker (opaque=0xa3248b0) at threadproc/unix/thread.c:138 #10 0x00db443b in start_thread () from /lib/libpthread.so.0 #11 0x002effde in clone () from /lib/libc.so.6 

Seems that sometimes the consumer still has pending_content even though the code seems to assume it won't. At line 1010 of openamq/server/amq_queue_basic.c adding a check for consumer->pending_content and calling amq_consumer_content_release if it's set before calling amq_consumer_content_hold at line 1012 prevents the server from crashing. I don't know if that is valid behavior, but hopefully it helps.

OpenAMQ used to provide C++ classes for some APIs but this was complex and not fully tested. On the 1.4 branch it's been ripped out.

So I think you should be aware of things not working properly with this interface.

WBR
Günther

Thanks,
Charan

WBR
Günther

Thanks,
Charan

HTH
Günther

Thanks,
Charan.

The wildcard only found the second match

2009-09-03 16:05:11: X: publish XXX_internalT: routing_key=XXX.MyProcessName_mySystem_791
2009-09-03 16:05:11: X: route XXX_internalT: routing_key=XXX.MyProcessName_mySystem_791
2009-09-03 16:05:11: X: hit XXX_internalT: wildcard=XXX.MyProcessName_mySystem_791
2009-09-03 16:05:11: X: deliver queue=XXX_topic.mySystem.myCompany.com_791
2009-09-03 16:05:11: X: publish XXX_internalT: routing_key=XXX.ReadAll
2009-09-03 16:05:11: X: route XXX_internalT: routing_key=XXX.ReadAll
2009-09-03 16:05:11: X: hit XXX_internalT: wildcard=XXX.*
2009-09-03 16:05:11: X: deliver queue=XXX_topic.mySystem.myCompany.com_780

FATAL ERROR at smt_signal.c:474, in smt_signal_annihilate
smt_signal at 0xa34b290 expected object_tag=0xfabb, actual object_tag=0xdead
<smt_signal file = "smt_signal.c" line = "474" pointer = "0xa34b290" />
Please report this to gro.qmanepo.stsil|ved-qmanepo#gro.qmanepo.stsil|ved-qmanepo
Aborted (core dumped)

The test case ran for about 30 minutes before showing up this time:

#0 0x00ea3410 in __kernel_vsyscall ()
#1 0x00a3cc00 in raise () from /lib/libc.so.6
#2 0x00a3e451 in abort () from /lib/libc.so.6
#3 0x0840b7d9 in smt_signal_destroy_ (self_p=0xb34fb154, file=0x8cabbc3 "smt_signal.c", line=726) at smt_signal.c:474
#4 0x0840bf54 in smt_signal_deregister (the_signal=2) at smt_signal.c:726
#5 0x083d237c in amq_client_agent_connection_destroy (thread=0xa311b60) at amq_client_agent.c:15842
#6 0x083f79b7 in smt_thread_annihilate_ (self_p=<value optimized out>, file=<value optimized out>, line=15752) at smt_thread.c:525
#7 0x083f7e18 in smt_thread_destroy_ (self_p=0xb34fb398, file=0x8c9b72a "amq_client_agent.c", line=15752) at smt_thread.c:2854
#8 0x083cde30 in amq_client_agent_manager (thread_p=0xb34fb398) at amq_client_agent.c:15752
#9 0x083ef8dc in s_execute (apr_thread=0xb5dac1e0, data=0xb5d83e08) at smt_os_thread.c:3216
#10 0x08450c76 in dummy_worker (opaque=0xb5dac1e0) at threadproc/unix/thread.c:138
#11 0x00b872db in start_thread () from /lib/libpthread.so.0
#12 0x00ae114e in clone () from /lib/libc.so.6

FATAL ERROR at smt_signal.c:474, in smt_signal_annihilate
smt_signal at 0xb5e217a8 expected object_tag=0xfabb, actual object_tag=0xc8
<smt_signal file = "smt_signal.c" line = "474" pointer = "0xb5e217a8" />
Please report this to gro.qmanepo.stsil|ved-qmanepo#gro.qmanepo.stsil|ved-qmanepo
Aborted (core dumped)

#0 0x004cb410 in __kernel_vsyscall ()
#1 0x00a3cc00 in raise () from /lib/libc.so.6
#2 0x00a3e451 in abort () from /lib/libc.so.6
#3 0x084014c2 in smt_signal_destroy_ ()
#4 0x084019d5 in smt_signal_deregister ()
#5 0x083ce6d3 in amq_client_agent_connection_destroy ()
#6 0x083ef98d in smt_thread_annihilate_ ()
#7 0x083efef0 in smt_thread_destroy_ ()
#8 0x083bfc2d in amq_client_agent_manager ()
#9 0x083e87aa in s_execute ()
#10 0x08440916 in dummy_worker (opaque=0x9d58f88) at threadproc/unix/thread.c:138
#11 0x00b872db in start_thread () from /lib/libpthread.so.0
#12 0x00ae114e in clone () from /lib/libc.so.6

HTH
Günther

AFAIK this feature is available earliest with OpenAMQ-1.3d0 (see issue 65).

HTH
Günther

Thanks,
Charan

In the past 3 weeks, we have seen only one broker crash on Fedora 11 — and it appears to be different than what we've seen before.

Rather than open up another issue, I'm just going to put the details of the crash here:

FATAL ERROR at amq_content_basic.c:5903, in amq_content_basic_unlink_
amq_content_basic at 0x7f6eb0013da0 expected object_tag=0xfabb, actual object_tag=0x0
<amq_content_basic zombie = "0" links = "0" containers = "0" file = "amq_content_basic.c" line = "5903" pointer = "0x7f6eb0013da0" />
Please report this to gro.qmanepo.stsil|ved-qmanepo#gro.qmanepo.stsil|ved-qmanepo

If this happens again, I'll let you guys know.