> For the latter case I have proposed and had agreement in principal to
> add another method to the protocol to determine whether a given
> routing key is routable by an exchange thereby allowing us to throw an
> exception on creation of the producer.
That's not sufficient as it may (for instance) be a temporary queue
which gets auto deleted during the lifetime of the MessageProducer. In
this case send() should starting throwing InvalidDestinationException
- at least my my reading of the JMS API docs.
Ah yes, that's true. We could use an option to make the send
asynchronous, as I mentioned in the other case.
> For the former case, we can block by default (which is nasty but
> required for strict compliance) or provide an option allowing it to be
> done asynchronously since I imagine some users will not want to take
> the hit of the block. We should certainly discuss this issue
> separately.
We cannot block at the moment as there is no way in the protocol to do
so.
Sorry I should have mentioned that we have discussed (and had
agreement in principle) for a version of the Send call that returns a
response. That was motivated by the use case where you are using
persistence but not transactions, and you need a response to know that
the broker has actually committed to message to a store.
It hasn't been implemented yet because we were waiting for some
resolution on the somewhat thorny nowait issue.
Using transactions closes the channel on error and in any case
doesn't seem to cover all use cases.
Yes, saying "use transactions" (which is what we used to say) is too
restricting.
I just mean that it needn't be encoded in a JMS-compliant way. Perhaps
with extensions to the field table types this problem may go away.
Ah ok I see what you mean.
Don't misunderstand me, I absolutely think that JMS (an extended JMS)
should be the primary API what we push. I just think that it could be
elegant to have a AMQP API layer that the JMS layer uses.
I'm just not convinced of that, at least I think I would need to see a
detailed proposal to make that decision. I would also like to
understand if it would have any impact on efficiency.
This
AMQP-level API may be useful for direct use by other implementors (not
generally end-users) who are building adapters for other middleware
such as SCA or a middleware api adapter at JPMC that I am aware of.
Why would it be more useful than an extended JMS API?
> I think we agree that we need to expose functionality that goes beyond
> JMS. The question is whether we can do this though extension points to
> JMS or whether we need a separate API.
Perhaps both. Application developers use JMS in order to remain
somewhat independant of the provider. For other uses that isn't a
requirement.
Would we support it for end users and have to make guarantees about
backward compatibility for it?
RG
