You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by GitBox <gi...@apache.org> on 2021/04/29 09:05:24 UTC
[GitHub] [pulsar] AtticusLv opened a new issue #10437: pulsar java reactor based client support
AtticusLv opened a new issue #10437:
URL: https://github.com/apache/pulsar/issues/10437
Please support java and reactor client, reactive programming based client api.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] lhotari commented on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
lhotari commented on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-870008599
> @lhotari hey, I want to contribute towards reactor client, is there any development currently going on?
@MaxHub I'll soon have time to focus on an adapter library which adapts the existing Pulsar Java Client's Async API to Project Reactor / Reactive Streams. Such an adapter library is fairly simple to implement when the goal isn't to implement a purely reactive library and the requirements are relaxed.
There are a few areas which might need some changes to the Java Client. One of such is the producer backpressure solution. The [Java client "signals" producer backpressure with exceptions](https://github.com/apache/pulsar/blob/34a04b5fa4692cb4716df61e740795467f76451b/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ProducerImpl.java#L754-L780) such as PulsarClientException.ProducerQueueIsFullError and PulsarClientException.MemoryBufferIsFullError. It should be possible to adapt this to the Reactive wrapper, but it's not very optimal. Initially I was thinking of ignoring the requested demand (Subscription's `request(long n)`) completely.
Consumer backpressure doesn't require any special tricks in the adapter library when the requested demand is ignored.
I have previously implemented such an adapter library for Pulsar. I was planning to reimplement a clean room implementation from scratch so that there wouldn't be copyright issues. There would also be the possibility to rethink the design while reimplementing it.
I think that a good starting point would be to start from the design decisions and examples around the API and implemention.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] lhotari commented on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
lhotari commented on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-870008599
> @lhotari hey, I want to contribute towards reactor client, is there any development currently going on?
@MaxHub I'll soon have time to focus on an adapter library which adapts the existing Pulsar Java Client's Async API to Project Reactor / Reactive Streams. Such an adapter library is fairly simple to implement when the goal isn't to implement a purely reactive library and the requirements are relaxed.
There are a few areas which might need some changes to the Java Client. One of such is the producer backpressure solution. The [Java client "signals" producer backpressure with exceptions](https://github.com/apache/pulsar/blob/34a04b5fa4692cb4716df61e740795467f76451b/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ProducerImpl.java#L754-L780) such as PulsarClientException.ProducerQueueIsFullError and PulsarClientException.MemoryBufferIsFullError. It should be possible to adapt this to the Reactive wrapper, but it's not very optimal. Initially I was thinking of ignoring the requested demand (Subscription's `request(long n)`) completely.
Consumer backpressure doesn't require any special tricks in the adapter library when the requested demand is ignored.
I have previously implemented such an adapter library for Pulsar. I was planning to reimplement a clean room implementation from scratch so that there wouldn't be copyright issues. There would also be the possibility to rethink the design while reimplementing it.
I think that a good starting point would be to start from the design decisions and examples around the API and implemention.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] lhotari edited a comment on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
lhotari edited a comment on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-870008599
> @lhotari hey, I want to contribute towards reactor client, is there any development currently going on?
@MaxHub I'll soon have time to focus on an adapter library which adapts the existing Pulsar Java Client's Async API to Project Reactor / Reactive Streams. Such an adapter library is fairly simple to implement when the goal isn't to implement a purely reactive library and the requirements are relaxed.
There are a few areas which might need some changes to the Java Client. One of such is the producer backpressure solution. The [Java client "signals" producer backpressure with exceptions](https://github.com/apache/pulsar/blob/34a04b5fa4692cb4716df61e740795467f76451b/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ProducerImpl.java#L754-L780) such as PulsarClientException.ProducerQueueIsFullError and PulsarClientException.MemoryBufferIsFullError. It should be possible to adapt this to the Reactive wrapper, but it's not very optimal.
One detail around "relaxed" reactive streams adaptation: Initially I was thinking of ignoring the requested demand (Subscription's `request(long n)`) completely.
Consumer backpressure doesn't require any special tricks in the adapter library when the requested demand is ignored.
I have previously implemented such an adapter library for Pulsar. I was planning to reimplement a clean room implementation from scratch so that there wouldn't be copyright issues. There would also be the possibility to rethink the design while reimplementing it.
I think that a good starting point would be to start from the design decisions and examples around the API and implemention.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] lhotari commented on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
lhotari commented on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-909270873
> @lhotari
> Thank a lot for the invite. Do you have smth production ready? And also is there any issues that I can help with& =)
> I implemented reactive facade in out company, but it hardly can satisfy others
I've been busy getting the adapter library into a state where it fulfils the promise made [in the conference talk abstract](https://springone.io/2021/sessions/reactive-applications-with-apache-pulsar-and-spring-boot). Conference Driven Development. The code is already available at https://github.com/lhotari/reactive-pulsar and https://github.com/lhotari/reactive-pulsar-showcase .
I have put most of the effort in refactoring the interfaces and packaging so there's not many unit tests currently. However, since it's a thin layer over the Pulsar Client, I don't have huge concerns that there would be major issues in the solution.
Eventually I solved the producer backpressure with a custom ["InflightLimiter" reactive operator](https://github.com/lhotari/reactive-pulsar/blob/master/reactive-pulsar-adapter/src/main/java/com/github/lhotari/reactive/pulsar/internal/adapter/InflightLimiter.java). It was the simplest approach for solving the producer backpressure in a reliable way. This works with the producer cache that is part of the solution. The limiter state is also shared via the cache and limits concurrent sending operations using the same cached producer.
I haven't had the chance to properly organize the project yet. I'm planning to offer the project to be adopted by the Apache Pulsar project. I haven't yet checked what requirements there are for the IPRs and if accepting contributions make it harder to move it under Apache. I'd assume that it would be better to move it under Apache asap and then start accepting contributions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] lhotari edited a comment on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
lhotari edited a comment on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-909270873
> @lhotari
> Thank a lot for the invite. Do you have smth production ready? And also is there any issues that I can help with& =)
> I implemented reactive facade in out company, but it hardly can satisfy others
I've been busy getting the adapter library into a state where it fulfils the promise made [in the conference talk abstract](https://springone.io/2021/sessions/reactive-applications-with-apache-pulsar-and-spring-boot). Conference Driven Development. The code is already available at https://github.com/lhotari/reactive-pulsar and https://github.com/lhotari/reactive-pulsar-showcase . The libraries [have also been published to maven central](https://search.maven.org/search?q=reactive-pulsar).
I have put most of the effort in refactoring the interfaces and packaging so there's not many unit tests currently. However, since it's a thin layer over the Pulsar Client, I don't have huge concerns that there would be major issues in the solution.
Eventually I solved the producer backpressure with a custom ["InflightLimiter" reactive operator](https://github.com/lhotari/reactive-pulsar/blob/master/reactive-pulsar-adapter/src/main/java/com/github/lhotari/reactive/pulsar/internal/adapter/InflightLimiter.java). It was the simplest approach for solving the producer backpressure in a reliable way. This works with the producer cache that is part of the solution. The limiter state is also shared via the cache and limits concurrent sending operations using the same cached producer.
I haven't had the chance to properly organize the project yet. I'm planning to offer the project to be adopted by the Apache Pulsar project. I haven't yet checked what requirements there are for the IPRs and if accepting contributions make it harder to move it under Apache. I'd assume that it would be better to move it under Apache asap and then start accepting contributions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] lhotari commented on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
lhotari commented on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-829081404
@AtticusLv Thanks for the feature request. I have some plans for this. The initial support would be an adapter library which adapts the existing Pulsar Java Client's Async API to Project Reactor / Reactive Streams. This approach isn't perfect, but it's a good starting point.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] codelipenghui commented on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
codelipenghui commented on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-1058890839
The issue had no activity for 30 days, mark with Stale label.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] lhotari commented on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
lhotari commented on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-907069222
@AtticusLv @MaxHub I'll be presenting "Reactive Applications with Apache Pulsar and Spring Boot" virtually on 9/2 starting at 11am PT at SpringOne conference. It is free to attend. Please check the details at https://springone.io/2021/sessions/reactive-applications-with-apache-pulsar-and-spring-boot .
My plan is to iterate a few rounds of evolution on an experimental library to get the API stable and then contribute that to the Apache Pulsar project. I'll present the work at my talk and new contributors are welcome to join the efforts.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] MaxHub commented on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
MaxHub commented on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-909165650
@lhotari
Thank a lot for the invite. Do you have smth production ready? And also is there any issues that I can help with& =)
I implemented reactive facade in out company, but it hardly can satisfy others
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] MaxHub commented on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
MaxHub commented on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-909165650
@lhotari
Thank a lot for the invite. Do you have smth production ready? And also is there any issues that I can help with& =)
I implemented reactive facade in out company, but it hardly can satisfy others
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] lhotari edited a comment on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
lhotari edited a comment on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-870008599
> @lhotari hey, I want to contribute towards reactor client, is there any development currently going on?
@MaxHub I'll soon have time to focus on an adapter library which adapts the existing Pulsar Java Client's Async API to Project Reactor / Reactive Streams. Such an adapter library is fairly simple to implement when the goal isn't to implement a purely reactive library and the requirements are relaxed.
There are a few areas which might need some changes to the Java Client. One of such is the producer backpressure solution. The [Java client "signals" producer backpressure with exceptions](https://github.com/apache/pulsar/blob/34a04b5fa4692cb4716df61e740795467f76451b/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ProducerImpl.java#L754-L780) such as PulsarClientException.ProducerQueueIsFullError and PulsarClientException.MemoryBufferIsFullError. It should be possible to adapt this to the Reactive wrapper, but it's not very optimal.
One detail around "relaxed" reactive streams adaptation: Initially I was thinking of ignoring the requested demand (Subscription's `request(long n)`) completely.
Consumer backpressure doesn't require any special tricks in the adapter library when the requested demand is ignored.
I have previously implemented such an adapter library for Pulsar. I was planning to reimplement a clean room implementation from scratch so that there wouldn't be copyright issues. There would also be the possibility to rethink the design while reimplementing it.
I think that a good starting point would be to start from the design decisions and examples around the API and implemention.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] lhotari edited a comment on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
lhotari edited a comment on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-909270873
> @lhotari
> Thank a lot for the invite. Do you have smth production ready? And also is there any issues that I can help with& =)
> I implemented reactive facade in out company, but it hardly can satisfy others
I've been busy getting the adapter library into a state where it fulfils the promise made [in the conference talk abstract](https://springone.io/2021/sessions/reactive-applications-with-apache-pulsar-and-spring-boot). Conference Driven Development. The code is already available at https://github.com/lhotari/reactive-pulsar and https://github.com/lhotari/reactive-pulsar-showcase . The libraries [have also been published to maven central](https://search.maven.org/search?q=reactive-pulsar).
I have put most of the effort in refactoring the interfaces and packaging so there's not many unit tests currently. However, since it's a thin layer over the Pulsar Client, I don't have huge concerns that there would be major issues in the solution.
Eventually I solved the producer backpressure with a custom ["InflightLimiter" reactive operator](https://github.com/lhotari/reactive-pulsar/blob/master/reactive-pulsar-adapter/src/main/java/com/github/lhotari/reactive/pulsar/internal/adapter/InflightLimiter.java). It was the simplest approach for solving the producer backpressure in a reliable way. This works with the producer cache that is part of the solution. The limiter state is also shared via the cache and limits concurrent sending operations using the same cached producer.
I haven't had the chance to properly organize the project yet. I'm planning to offer the project to be adopted by the Apache Pulsar project. I haven't yet checked what requirements there are for the IPRs and if accepting contributions make it harder to move it under Apache. I'd assume that it would be better to move it under Apache asap and then start accepting contributions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] MaxHub commented on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
MaxHub commented on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-909165650
@lhotari
Thank a lot for the invite. Do you have smth production ready? And also is there any issues that I can help with& =)
I implemented reactive facade in out company, but it hardly can satisfy others
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] lhotari commented on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
lhotari commented on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-909270873
> @lhotari
> Thank a lot for the invite. Do you have smth production ready? And also is there any issues that I can help with& =)
> I implemented reactive facade in out company, but it hardly can satisfy others
I've been busy getting the adapter library into a state where it fulfils the promise made [in the conference talk abstract](https://springone.io/2021/sessions/reactive-applications-with-apache-pulsar-and-spring-boot). Conference Driven Development. The code is already available at https://github.com/lhotari/reactive-pulsar and https://github.com/lhotari/reactive-pulsar-showcase .
I have put most of the effort in refactoring the interfaces and packaging so there's not many unit tests currently. However, since it's a thin layer over the Pulsar Client, I don't have huge concerns that there would be major issues in the solution.
Eventually I solved the producer backpressure with a custom ["InflightLimiter" reactive operator](https://github.com/lhotari/reactive-pulsar/blob/master/reactive-pulsar-adapter/src/main/java/com/github/lhotari/reactive/pulsar/internal/adapter/InflightLimiter.java). It was the simplest approach for solving the producer backpressure in a reliable way. This works with the producer cache that is part of the solution. The limiter state is also shared via the cache and limits concurrent sending operations using the same cached producer.
I haven't had the chance to properly organize the project yet. I'm planning to offer the project to be adopted by the Apache Pulsar project. I haven't yet checked what requirements there are for the IPRs and if accepting contributions make it harder to move it under Apache. I'd assume that it would be better to move it under Apache asap and then start accepting contributions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] MaxHub commented on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
MaxHub commented on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-869928272
@lhotari hey, I want to contribute towards reactor client, is there any development currently going on?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] MaxHub commented on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
MaxHub commented on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-869928272
@lhotari hey, I want to contribute towards reactor client, is there any development currently going on?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] lhotari edited a comment on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
lhotari edited a comment on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-909270873
> @lhotari
> Thank a lot for the invite. Do you have smth production ready? And also is there any issues that I can help with& =)
> I implemented reactive facade in out company, but it hardly can satisfy others
I've been busy getting the adapter library into a state where it fulfils the promise made [in the conference talk abstract](https://springone.io/2021/sessions/reactive-applications-with-apache-pulsar-and-spring-boot). Conference Driven Development. The code is already available at https://github.com/lhotari/reactive-pulsar and https://github.com/lhotari/reactive-pulsar-showcase . The libraries [have also been published to maven central](https://search.maven.org/search?q=reactive-pulsar).
I have put most of the effort in refactoring the interfaces and packaging so there's not many unit tests currently. However, since it's a thin layer over the Pulsar Client, I don't have huge concerns that there would be major issues in the solution.
Eventually I solved the producer backpressure with a custom ["InflightLimiter" reactive operator](https://github.com/lhotari/reactive-pulsar/blob/master/reactive-pulsar-adapter/src/main/java/com/github/lhotari/reactive/pulsar/internal/adapter/InflightLimiter.java). It was the simplest approach for solving the producer backpressure in a reliable way. This works with the producer cache that is part of the solution. The limiter state is also shared via the cache and limits concurrent sending operations using the same cached producer.
I haven't had the chance to properly organize the project yet. I'm planning to offer the project to be adopted by the Apache Pulsar project. I haven't yet checked what requirements there are for the IPRs and if accepting contributions make it harder to move it under Apache. I'd assume that it would be better to move it under Apache asap and then start accepting contributions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar] lhotari commented on issue #10437: pulsar java reactor based client support
Posted by GitBox <gi...@apache.org>.
lhotari commented on issue #10437:
URL: https://github.com/apache/pulsar/issues/10437#issuecomment-909270873
> @lhotari
> Thank a lot for the invite. Do you have smth production ready? And also is there any issues that I can help with& =)
> I implemented reactive facade in out company, but it hardly can satisfy others
I've been busy getting the adapter library into a state where it fulfils the promise made [in the conference talk abstract](https://springone.io/2021/sessions/reactive-applications-with-apache-pulsar-and-spring-boot). Conference Driven Development. The code is already available at https://github.com/lhotari/reactive-pulsar and https://github.com/lhotari/reactive-pulsar-showcase .
I have put most of the effort in refactoring the interfaces and packaging so there's not many unit tests currently. However, since it's a thin layer over the Pulsar Client, I don't have huge concerns that there would be major issues in the solution.
Eventually I solved the producer backpressure with a custom ["InflightLimiter" reactive operator](https://github.com/lhotari/reactive-pulsar/blob/master/reactive-pulsar-adapter/src/main/java/com/github/lhotari/reactive/pulsar/internal/adapter/InflightLimiter.java). It was the simplest approach for solving the producer backpressure in a reliable way. This works with the producer cache that is part of the solution. The limiter state is also shared via the cache and limits concurrent sending operations using the same cached producer.
I haven't had the chance to properly organize the project yet. I'm planning to offer the project to be adopted by the Apache Pulsar project. I haven't yet checked what requirements there are for the IPRs and if accepting contributions make it harder to move it under Apache. I'd assume that it would be better to move it under Apache asap and then start accepting contributions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org