Open Admiralkheir opened 10 months ago
@Jarema , maybe you can have a quick look?
Yes. Will take a look into this one. Sorry for late reaponse.
In Conext of Dapr, does it make sense to implement this feature as BulkPublish
interaface impl @berndverst ?
That way we could still have access to ack result for all messages, but handled in async manner (publish everything and wait for all acks to come back).
Hello, is there any news regarding this issue? According to the log provided by dapr runtime in 1.12.4, NATS streaming will be removed with version 1.13, but we could not fully switch to JetStream due to parallel processing and dependency on this component throughout our applications. I submit it for your information @yaron2
time="2024-02-02T11:36:37.0821027+03:00" level=warning msg="⚠️ The NATS Streaming PubSub component is deprecated due to the deprecation of NATS Server, and will be removed from Dapr 1.13" app_id=servicea component="serviceapublisher (pubsub.natsstreaming/v1)" instance=G4YS8S3 scope=dapr.contrib type=log ver=1.12.4
Hello, is there any news regarding this issue? According to the log provided by dapr runtime in 1.12.4, NATS streaming will be removed with version 1.13, but we could not fully switch to JetStream due to parallel processing and dependency on this component throughout our applications. I submit it for your information @yaron2
time="2024-02-02T11:36:37.0821027+03:00" level=warning msg="⚠️ The NATS Streaming PubSub component is deprecated due to the deprecation of NATS Server, and will be removed from Dapr 1.13" app_id=servicea component="serviceapublisher (pubsub.natsstreaming/v1)" instance=G4YS8S3 scope=dapr.contrib type=log ver=1.12.4
This component will indeed be removed in 1.13. Dapr has a support policy for previous two releases so you have time to switch your apps to using Jetstream. I highly advise to move away from NATS streaming as the product itself is considered legacy
@Admiralkheir we can certainly enable this for 1.14, the next version. Which means you can stay with 1.12.x as it will still be a supported version
@yaron2 ty, we will be waitting
Hello, is there any development on this issue?
I'll try to find time to pick it up in May.
Hello again, is there any development on this issue? @Jarema
I'm still planning to work on this, but unfortunately my schedule shifted.
Hi all, We have been using nats streaming for a long time. With the end of support in Nats Streaming, we decided to switch to JetStream. As a result of our tests, we are opening issues related to the situations we noticed. (#3079 resolved ty for effort)
Expected Behavior
Sidecar should sends the events without any limitation on its side, for the previous event It should forward the event without waiting for a success or fail response. We make this limitation with the Max Ack Pending parameter on the JetStream's side. If Nats does not receive an ack, it transmits the event itself.
Actual Behavior and Problem
We noticed sidecar is sending events to app one by one. Sending one and waiting for a response (success or failure) if success or fail it is sending a second event but JetStream component has Max Ack Pending parameter for this (unack message count). We are setting this parameter 5 and noticed in the subscription log from
nats consumer info
command, JetStream is sending 5 messages to sidecar but sidecar is sending one by one and waiting for processing event. This behaviour impact Parallelism I think.According the JetStream doc;
jetstream-component.yaml
dapr's log:
Note
dapr's version: 1.11.2 JetStream version: 2.9.21
1669 was a similar issue with this issue in the past, @yaron2 helped on that issue, maybe this will help