Re: Qpid Proton C++ open_sender vs open_receiver
Robbie Gemmell wrote
> Calling open_sender will open a 'sender' link, and calling
> open_receiver will create a 'receiver' link. The two are mostly
> independent if you are simply sending to a queue, suggesting any
> difference being seen from adding the latter would probably be some
> interaction with the server configuration, other clients in use, etc.
This was the basic jist I was getting from qpid.log, but wasn't sure there
was something more worthwhile knowing about going on behind the scenes.
Robbie Gemmell wrote
> It seems likely your sender is either never being given any credit to
> send
I've verified I have credit on the sender before I try sending via
on_sender_open.
Robbie Gemmell wrote
> or actually the messages are being sent but just not accepted
> (e.g instead released/modified/rejected) due to the particular setup.
How could I verify this? I don't see anything in my qpid.log that shows the
message is being received/rejected/released/modified.
Robbie Gemmell wrote
> Or it could just be an issue in your program, or the client. Its hard
> to say much based on the limited info here.
Totally fair. Here are the (subjectively) relevant code snippets where I'm
actually trying to "do" something (just trying to do basic ssl setup and
message send to get myself started).
void on_container_start(proton::container ) override {
if (!connected()) {
try {
cout << "inside on_container_start" << endl;
stringstream qpidURLBuilder;
qpidURLBuilder << "amqps://";
qpidURLBuilder << this->brokerURI;
qpidURLBuilder << ":";
qpidURLBuilder << this->portNumber;
string qpidURL = qpidURLBuilder.str();
connection_options connectionOptions;
cout << "setting ssl connectionOptions..." << endl;
string envCertPassword = "password";
string certName = "/home/mrich/guest.crt";
string certKey = "/home/mrich/guest.key";
string server_ca = "/home/mrich/root.crt";
ssl_certificate client_cert = ssl_certificate(certName,
certKey, envCertPassword);
ssl_client_options ssl_cli(client_cert, server_ca,
proton::ssl::VERIFY_PEER);
connectionOptions.sasl_allowed_mechs("EXTERNAL");
connectionOptions.ssl_client_options(ssl_cli);
cout << "preparing to connect to qpid..." << endl;
this->conn = c.connect(qpidURL, connectionOptions);
} catch (const std::exception& error) {
cerr << error.what() << endl;
cleanup();
}
}
}
void on_connection_open(proton::connection ) override {
c.open_sender("external.dropbox");
//c.open_receiver("external.dropbox");
cout << "connection has been opened..." << endl;
this->isConnected = true;
}
int send() {
int messagesProcessed = 0;
if (!connected()) {
return -1;
}
string loc;
string header;
try {
while (this->sent < this->maxMessagesPerSend) {
message msg;
msg.durable(true);
msg.id(this->sent);
header="gobble-dee-goo" + to_string(this->sent);
msg.subject(header);
loc="blah-blah-blah";
msg.body(loc);
this->sndr.send(msg);
cout << "attempting to send message: " << fileHeader << endl;
messagesProcessed++;
this->sent++;
sleep(1);
}
} catch (const std::exception& error) {
cerr << error.what() << endl;
cleanup();
}
return messagesProcessed;
}
To reiterate my previous comment, when I use c.open_receiver in
on_connection_open, the messages successfully go through. Without it,
though, I don't see any sign the message is successfully sending.
Also, I'm not sure if it adds anything regarding qpid configuration, but we
are also using Qpid JMS and Proton Python. I've successfully got those
working (connecting/sending/receiving/etc.), but Proton C++ is providing the
most difficult to properly set up and consistently get working. This merely
lends to the thought that my issue seems code related and not necessarily
qpid configuration related. I could very well be off base, though.
Thanks again,
Matt R.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Qpid Proton C++ open_sender vs open_receiver
Hi All, I was hoping someone could explain the difference in what is going on behind the scenes with Qpid Proton C++'s open_sender and open_receiver functions. I am running into an issue with my class that is opening the sender and the queue I am sending to not receiving messages. I have checked that when I call the open_sender that a connection and channel (or "session" as I understand it could be correlated with) are created, but no messages are going through to the queue on send. When I qpid-stat I see that the queue exists and it has consumers. However, if I add an open_receiver call alongside my open_sender then the messages send just fine (qpid-stat verifies this as well as on_tracker_accept is now getting called in my code). Could someone explain what I might be missing or doing wrong so that I do not require also calling open_receiver when I merely want to send messages to my queue? All responses are greatly appreciated. - Matt R. -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Qpid Proton C++ 32-bit Support?
Thanks for the reply, Ted! If that is the case, then it seems my biggest issue is knowing what 32-bit lib dependencies are required and if there are rhel7 versions available. If there are any 32-bit dependencies no longer managed and secured by red hat, then we will definitely want to look into going purely 64-bit. Would you be able to provide any insight into that information? Thanks, Matt R. -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Qpid Proton C++ 32-bit Support?
Hi All, I was wondering, does Qpid Proton C++ still support 32-bit builds? We have a couple of legacy applications that are 32-bit using the old (OLD) Qpid (0.32 if I remember correctly) while the rest are based on 64-bit. Currently I can only find x86_64 based rpms, so I'm assuming that is now the be-all end-all. Is there a way to build/install the Qpid Proton C++ lib as 32-bit or do I need to convince the higher-ups that we need to switch solely to 64-bit support? Thanks, Matt R. -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Set destination from Qpid Proton Client
My apologies for lacking detail. I'm certainly not trying to make anything more complicated than I need to. >From my understanding, there is no way to create a queue from the client. However, with Broker-J, if trying to subscribe to a non-existent queue, then Broker-J will create one for you; albeit with a mangled name for the queue (e.g. qpidsub_/ID:). The mangled name was my problem as I needed the name to match the binding key so as to prevent unnecessary extra queues (i.e. a queue with name "test_queue" could be found in the amq.direct exchange with destination and bindingKey both set to "test_queue"). I have gotten around this by simply utilizing the REST api to create the queue and exchange binding on the fly (based on our current code, this used to be possible using the old Python Qpid api's session.declare_queue and session.exchange_bind, respectively). My issue now is that I, essentially, need to be able to do the following in Proton: # Declare a local queue to which we subscribe the reply-to queue localQueueName = "producerLocalQueue_" + session.name localQueue = session.incoming(localQueueName) session.message_subscribe(queue=replyQueueName, destination=localQueueName) localQueue.start() (ref: https://www.linuxjournal.com/article/10379) I can't seem to figure out how to mimic the message_subscribe behavior. Is that simply creating another receiver passing the reply queue as the source and local queue as the target or name? I apologize in advance if I'm making this over complicated or missing something from the docs/api that explain this. Thanks, Matt R. -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
