When using the core API, what will happen is the message will find its routes. On your case you won't have any route, hence no results to be reported.
When doing it through JMS, the JMS Spec requires you to have pre-existent destinations.. hence you would get an exception.
This is a bit different with Consumers though, since you need a pre-existent queue in order to be able to create the consumer.
Hi Clebert, thank you for responding.
Using the core API, is there any way to be informed if the message was not sent successfully? For most of my queues, it would be fine if a send failed and an error is not reported, but for others, I absolutely must receive an error if the send is not successful.
Can you advise how I can do that with the core API?
That's the point.. using core-concepts there's nothing wrong on not having a queue associated. So, nothing wrong happened in terms of the API.
You probably should query if the destinations exists.
Think of an address without any subscriptions. You could have a situation where this is legal.. .and you just create a queue and at that point you start receiving your messages.
The core API is for more generic usages than just JMS. You could use session.queueQuery before you created your producer or consumer and do the test yourself. (Create a class wrapper for it if you like, which is just like what happens on the JMS wrapper).
Thanks again Clebert. That's a good idea to query for the queue upon session creation to see if it's there.
As a more general question, even if the queue exists, would I get an error if there is another kind of problem sending the message? When I saw that I got no error for a nonexistent queue, it made me think that I would receive no notification if the broker were unable to receive the message properly for other reasons.
For example, if I limit the size of a queue by some method, maybe by specifying a max memory for an address, and I send using the core API to a queue that is full, would I get an exception from the broker when send(...) is called? Or would it complete without error as it did in the 'invalid queue' case we discussed previously?
As I said you didn't get an error because there's no error on that... it is legal in core terms. (It may not be what you want.. but it is legal)
You would get an exception on cases where you had a failure (say IO, network or any other exceptions)
As for maxSize, I don't think there's a policy where we would throw an exception when maxSize is reached. I believe someone added a JIRA about it.
Okay -- thanks. Just one more point to clarify:
Using the core API, are errors reported only if they are detectable by the client? What I really want is that even if the network is fine and the client is able to send the message to the broker, if the broker responds with an error code, indicating any number of things, will an error be thrown in the client app.? My concern is that the client reports errors only if they occur on the client side and that it is unaware of broker-side errors. Excepting, of course, the case you mentioned regarding maxSize, which is known.
didn't I say you would get an exception?
I'm trying to clarify under what circumstances I would get an exception. Your comment was:
"You would get an exception on cases where you had a failure (say IO, network or any other exceptions)"
I want to be sure that I get an exception if something happens on the broker side as well as the client side. IO and network can be detected by the client without any input from the broker, so I wanted to double check to be sure the logic is in place for the broker to communicate error conditions to the client and for the client to throw an exception in all of those cases.
Thanks again for any help.
you will get an error message for any call that expects a response such as a session query. you will also get a response for any send where the client blocks on send, if you dont block on send then obviously no response will be received.