🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
Using Selectors in Solace PHP SMF
Hello all,
is there a way to use Message selectors in the PHP SMF library similar to the other Solace interfaces ( https://tutorials.solace.dev/jcsmp/message-selectors/ ) ? If not, do you have any other idea how we can easily receive messages via PHP using message selectors? Thanks a lot and best regards from Mannheim, Timo 
Comments
-
Hey Timo..! There is no PHP SMF library that I know of? I'm not sure if there's some way to "wrap" another API to use with PHP (like wrapping C API to use with Python). Do you have to use PHP?
A possible future option would be to use a REST Delivery Point, and REST Consumer, which essentially means the broker will "webhook" out a message from a queue to a REST URL. This doesn't exist yet though.
I'll go do some looking about PHP options.
0 -
Hi @timob , As @Aaron said, there is no native PHP API interface to Solace. There are couple of wrapper ideas... Here is one based on our C API (CCSMP):
https://github.com/nram-dev/solace-php-smf
Though I haven't implemented message selectors, since its based on C API, it should be possible to extend it to support it.Here is another option with MQTT for completeness. This however won't be an option for you since MQTT has no concept message selectors - to my knowledge.
https://github.com/nram-dev/solace-php-mqtt0 -
Hi @nram and @Aaron, Thank you for your kind and quick responses! When you say it is basically possible to implement the message selectors on the php wrapper for CCSMP, do you know when this feature could be coming or where it could be kindly requested? I think that would help us a lot! Thank you very much and best wishes from Mannheim, Timo
0 -
@timob , I will look into adding selectors, but the CCSMP wrapper is is meant to be a reference implementation for you to get started and Iam sure more needs done before its deployable. Besides, as @Aaron mentioned, use of selector pattern for message filtering is not generally recommended - unless you have specific usecase that can't be met with topic routing. Message selectors bury the filtering in the application code and not performant compared to topic routing.
0 -
Hi, our usecase is the following: We have about 800 stores (maybe ~6000 in a few years), all of which want to receive messages for the corresponding store via their own client. This is supposed to happen from the php environment. The topic hierarchy also allows a proper filtering (store ID is included in the topic hierarchy), but we wanted to decide against a filtering on topic level for now, because then we would have to provision a queue for every single store (=> 800 Queues) and would also have to maintain it and ensure that the message quota is not exceeded in case the store fails or goes offline. Thats why we decided to use Selectors in the first place, to avoid the provisioning of so many queues. Do you guys have any other ideas on how we can best implement this usecase?
0 -
Hey @timob ... thanks for the extra use case info. That's really helpful!! 🙏
First off, I'd say that in terms of best practices, it's definitely better to have a queue per store, rather than having a giant "catch all" non-exclusive queue and having 800 subscribers hang off that with Selectors. That's a very old-school way of designing what you're proposing. I'd strongly suggest reconsidering your approach. I think a few thousand queues is not that bad... in some of our IOT architectures for connected cars use cases we have 100,000+ queues on a single broker. The rates are low, so the broker is ok, and we have nice separation of concerns... each queue/vehicle is independent of the others.
You already have the store ID in the hierarchy, so that's great! Managing a large number of queues may seem daunting, but it really ensures you have very granular view into each store's rates and potential issues. And isolation as well. I think most of my colleagues would agree here with me..?
And finally, re: batches. MQTT/AMQP are built for streaming... built to just "stay online" and receive a message as it's published... why do you want to do periodic polling / batches? I mean, you could use a persistent subscription (e.g. QoS 1) in MQTT, and just occasionally connect when you want to check. AMQP or Solace SMF would work for this as well. But let me know if there's a reason you wouldn't want to just keep the connection up and receive things in real-time? Having that "always on" connection means you can do other things as well... receive real-time updates from HQ, push out metrics or inventory data from stores back to HQ, etc..?
3 -
Hey @timob,
I fully agree with all Aaron has said. Selectors have a severe impact on performance and will degrade the broker in different aspects like max queued messages, etc.
The better and recommended way is to filter on the topic hierarchy. The creation and administration of queues can be more or less automated via SEMP for example.
Uli and myself can support you and if you would like to discuss further, we can jump to a call at any time.
BR,
Alex3 -
Hey there @timob ... just a follow-up: I heard of some reasoning for maybe why one might want to use a single large "catch-all" queue with Selectors, rather than individual queues per store. Cost! haha that's a pretty good reason. Especially when looking to use Solace Cloud, and how large a service you might need for that.
By far, the better architectural approach would be to have each store have it's own queue for receiving data... that way each store's persistent data is decoupled and separate from other stores, you can control per-queue capacity, you can get metrics (msg rates and sizes per queue) etc. But if your rates are quite low across all your store (like in the 10s or 100s of messages per second) then the one-queue-with-Selectors approach could work well. But if the number of messages starts to go up, load goes up, you'll probably need to start considering multiple queues in the future.
I'm just saying... the queue-per-store approach is definitely best, but there are many ways to slice a pie / skin a cat / do something with similar results... the Selector approach might be ok with careful consideration. Heck, maybe even one-queue-per-metro might be ok? Some hibrid where you have some separation, and some sharing. Anyhow, just putting some ideas out there.
Hope that helps..!
1
