RediStreams implementation doesn't support topic wildcards

In our Ireland implementation, Events are now published to the Message Bus using multi level topics like: edgex/events/<profile>/<device>/<source>
Example:  edgex/events/Random-Integer/Random-Integer-Device-001/Int64
For ZMQ and MQTT clients can then subscribe using wild cards to filter what they receive.
Examples to receive all Events:
ZMQ: edgex/events
MQTT: edgex/events/#
Examples to receive just Events from the Random-Integer-Device-001 device
ZMQ: edgex/events/Random-Integer/Random-Integer-Device
MQTT: edgex/events/Random-Integer/Random-Integer-Device/#
The RedisStreams implementation of the Message Bus doesn't recognize any type of wild card in the subscribe topic.
If an Event is published to edgex/events/Random-Integer/Random-Integer-Device-001/Int64, the client has to subscribe to edgex/events/Random-Integer/Random-Integer-Device-001/Int64

@andresrinivasan , can you please review this issue and the RedisStreams implementation in this Repo and give guidance on how we could accomplish topic wildcards with RedisStreams. THX!

Interesting. XREAD can read from multiple keys at the same time... Is there a dictionary or registry that tracks the [profile, device, source] tuples?

Is there a dictionary or registry that tracks the [profile, device, source] tuples?
No, these are simply Event metadata that are added to the publish topic to better describe the data being published so that clients can filter via subscriptions.  Ideally any/all of them could be replaced with a wild card.

With MQTT we can have the following wildcard options:

edgex/events/#, edgex/# or #

All events

edgex/events/Random-Integer/#/Int64

All events for profile Random-Integer that have a source of Int64

edgex/events/Random-Integer/Random-Integer-Device-001/#

All events for device Random-Integer-Device-001 from  profile Random-Integer

edgex/events/#/Random-Integer-Device-001/#

All events for device Random-Integer-Device-001 no matter which profile or source

edgex/events/#/Random-Integer-Device-001/Int64

All events for device Random-Integer-Device-001 from source Int64 to no matter which profile

edgex/events/#/#/Int64

All events for source Int64 to no matter which profile or device

or with no wild card, which currently works with our RedisStreams MessageBus implementation

edgex/events/Random-Integer/Random-Integer-Device-001/Int64

Only Events for source Int64 on device Random-Integer-Device-001 from profile Random-Integer

edgex/events/Random-Integer/Random-Integer-Device-001/Int32

Only Events for source Int32 on device Random-Integer-Device-001 from profile Random-Integer


⚠ Bofrost.lu has degraded performance

In b2509b2, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1599 ms

Resolved: Bofrost.lu performance has improved in adb6a42 after 13 minutes.


Modify behavior of Array() on non-array result.

Closes #10.

@tidwall Just thought that I didn't update the README. Perhaps it could be usefull to add a note for the behavior of the Array() method.

I made a small mention on the README about Array(). Also I noticed that calling Array() on a path that does not exist a single item array with a Null a null result. For example:
gjson.Get(`{"item":null}`, "item1").Array()
gjson.Get(`{}`, "item").Array()

Both return []gjson.Result{null}. Though only the first one should return an array with one item.
I pushed an update to address this.

Good catch & thanks for the amazin work on the library btw 😄

You're welcome and thanks a ton for you help.


Add description in User's Guide on how to use a third-party connection pool

There has been many request on using e.g. HikariCP with Speedment.

Thanks for such quick response.

Should be added under https://speedment.github.io/speedment-doc/advanced_features.html#connection-pooling