Best Of
Re: In the .NET API, why isn't the `CorrelationKey` set on the `RejectedMessageError`?
There is no public way to track the fix progress; however, we have linked this post to our internal development ticketing system and will provide an update here when the fix becomes available.
Re: pubsubplus-connector-aws-kinesis
we using Mac and github runners in our testing.
We got a new version from solace, it should be updated on the hub…
Re: In the .NET API, why isn't the `CorrelationKey` set on the `RejectedMessageError`?
Hello @NasdaqMickelson - So I did some deep digging and indeed was able to reproduce the issue you have described, specifically for cases when the message attachment is too large.
This was a bit of head scratcher, so I spoke with some of the Solace developers and discovered that you have found a known corner case bug which has been previously identified and does have a fix scheduled sometime in the near term future.
The issue ultimately stems from fact that when a broker receives an oversized method, it performs an optimization and rejects it early before handling it off to the part of the code that deals with guaranteed messaging. So although the client side application receives a rejection, it's as if the message was rejected as a Direct Message - which means no correlation data is sent.
This is the only case in which a GM can result in a rejection without correlation data. The planned fix within SDK will be to prevent sending oversized messages client-side and likely return an error on the Send
call outright.
As a workaround, your client-side code can guard specifically for this - my recommendation would be to add a special check for message sizes greater than 9MB (if the queue can accept a 10MB message) and reject them before sending.
Wish we had something more clever, but at present this appears to be the most workable approach.
Re: How to fetch the Non durable queue details via SEMP API
Which SEMP version are you using? If using v2, note that the config
API won't return anything about temporary queues because they're not actually statically configured in the broker… they're temporary. You'll have to use the monitor
API to see information about them.
Note you'll also have to URL encode your queue name filter parameter. For example, to view all temporary queues on my broker, I'm looking for anything that starts with #P2P/QTMP/*
. Something like:
curl -u admin:admin http://localhost:8080/SEMP/v2/monitor/msgVpns/default/queues?where=queueName%3d%3d%23P2P%2FQTMP%2F%2A | jq
If using SEMPv1, they should be returned as part of the regular show queue *
command:
curl -u admin:admin http://localhost:8080/SEMP -d '<rpc><show><queue><name>#P2P/QTMP/*</name><detail/></queue></show></rpc>'
Re: How to solve this error: Received disposition with role=receiver
Ah, ok. Looking here at the AMQP spec:
There are a number of outcomes specified. Solace doesn't support "modified". A message on a queue can't be changed/updated by anyone, consumer or publisher. Only "accepted", "rejected", or "released" outcomes are supported by Solace. So you'll have to update your Camel config to not try to do a "modified".
EDIT: check out protocol conformance page here:
and look for section 3.4.Re: How to send NACK(Negative Acknowledgement) using java API
@Karuppusamy Thought you might be interested.
FYI, There is support for Negative Acknowledgement in Solace, check out
Re: cluster external links
Hi @rmontalt,
Were you able to figure out what happened and get it resolved? If you are using the Solace Cloud managed service you should open a support ticket so they can help dissect the logs, otherwise the logs are the best place to start yourself as well!
Re: Parsing characters from Binary data
Hi @Naruto. Ok… is this C? This is just your data structure format, the "in-memory" representation within your app. But doesn't say how the data is encoded on the wire. You need that information from the publisher application or documentation. Trying to reverse engineer it is hard! For example:
- If there are only 2 options for
messageType
, it could be encoded as a single bit! Or maybe a whole ASCII char (1 byte), or a UTF-16 char (2 bytes)? Or maybe 4 bytes to allow for future expansion, and is a custom encoding. - If your timestamp is nanos since epoch, it should look something like
1712321293665926900
(which is right now). Not1929249811
- EDIT: just noticed that it's nanos since Jan 1 1980, not 1970 like normal epoch. That's odd..? So the expected number should be quite a bit smaller than the one above, something like:
1396745293665926900
- EDIT: just noticed that it's nanos since Jan 1 1980, not 1970 like normal epoch. That's odd..? So the expected number should be quite a bit smaller than the one above, something like:
orderID
is a double? Are you sure? That seems very odd. That should certainly be an int or long. Or a String.- You have control/escape characters
^@
and^P
listed, which probably correspond to binary 0x00 and 0x10. These aren't ASCII chars. - A quantity of 2,127,492,296? Someone is buying or selling 2.1 billion items?
Please go and ask the application developers/architects for the encoding format for these messages.
Re: Binary to ASCII
Hi again @Naruto. No, SdkPerf has no pluggable capabilities for providing a deserialization mechanism. You'd have to code something yourself if you know the proper encoding format.
Re: Cleanup of Unused Queues
BTW: when you say "beyond a defined TTL", I just want to make sure you're saying what I'm thinking you're saying (but also for anyone stumbling on this later):
Often, queues in dev fill up because devs are publishing away, but not necessarily consuming from them. Queues fill up, can cause spool full issues, stop your broker from accepting any new Guaranteed messages. A great way to keep developer queues "trimmed" is to ensure that queues created in dev have a "max TTL" set to something reasonable (e.g. 3 days), and "respect TTL" is enabled.
For admin-created queues, this can be done by the broker administrator. But for any application-created queues, this policy can be enforced by the use of queue templates, associated with the developer's application's client profile.