initial bulk publish impl for java

[mukundansundar]

Signed-off-by: Mukundan Sundararajan 65565396+mukundansundar@users.noreply.github.com

Description

initial bulk publish implementation for Java SDK

Issue reference

We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.
Since bulk subscribe is already implemented, this PR closes #778

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation

[artursouza]

This is a problem we need to fix in other places in the SDK. Using the default serializer should not trigger different behavior. It should be based on the content-type only.

[mukundansundar]

this is a change that needs to be done SDK wide and not only for one api ... If it is is only changed here that might cause serialized events from this API to become incompatible with the other normal publish API ...

[johnewart]

Just a few questions / observations, mostly for my own edification - you don't need to block on them

[mukundansundar]

The build failures here are wrt Config API changes which is handled in the PR #740.

Locally also verified that the PubsubIT passes as expected ....
cc @dapr/maintainers-java-sdk

[mukundansundar]

As discussed offline, this PR only contains the gRPC implementation for Bulk Publish

[artursouza]

I assume this will be implemented next, right?

[mukundansundar]

@artursouza as we discussed previously, we were saying that HTTP impl is not needed, and that HTTP Client is going to be deprecated. #790

[mukundansundar]

@dapr/maintainers-java-sdk see the latest checks for this PR itself. It required only 2 runs.
The older one https://github.com/dapr/java-sdk/actions/runs/3871888965 required 4 attempts. (Before adding doc content)

For some reason the Kafka subscription is flaky.

Additionally I am seeing flakiness in other validations as well. Please see the logs

[mukundansundar]

@artursouza any updates on this PR?

[mukundansundar]

@dapr/maintainers-java-sdk see the latest checks for this PR itself. It required only 2 runs. The older one https://github.com/dapr/java-sdk/actions/runs/3871888965 required 4 attempts. (Before adding doc content)

For some reason the Kafka subscription is flaky.

Additionally I am seeing flakiness in other validations as well. Please see the logs

Changed the examples to use Redis, that removes the flakiness.

[codecov]

Codecov Report

Merging #789 (99639df) into master (b83661d) will increase coverage by 0.35%.
The diff coverage is 67.56%.

@@             Coverage Diff              @@
##             master     #789      +/-   ##
============================================
+ Coverage     77.62%   77.97%   +0.35%     
- Complexity     1161     1258      +97     
============================================
  Files           105      116      +11     
  Lines          3647     3887     +240     
  Branches        419      457      +38     
============================================
+ Hits           2831     3031     +200     
- Misses          603      625      +22     
- Partials        213      231      +18     

Impacted Files	Coverage Δ
.../client/domain/BulkPublishResponseFailedEntry.java	0.00% <0.00%> (ø)
...o/dapr/client/domain/BulkSubscribeAppResponse.java	0.00% <0.00%> (ø)
...r/client/domain/BulkSubscribeAppResponseEntry.java	0.00% <0.00%> (ø)
.../client/domain/BulkSubscribeAppResponseStatus.java	0.00% <0.00%> (ø)
...va/io/dapr/client/domain/BulkSubscribeMessage.java	0.00% <0.00%> (ø)
.../dapr/client/domain/BulkSubscribeMessageEntry.java	0.00% <0.00%> (ø)
sdk/src/main/java/io/dapr/utils/TypeRef.java	78.33% <44.44%> (-5.99%)	⬇️
...ava/io/dapr/client/domain/BulkPublishResponse.java	50.00% <50.00%> (ø)
...c/main/java/io/dapr/client/AbstractDaprClient.java	84.76% <55.55%> (-2.74%)	⬇️
...n/java/io/dapr/client/domain/BulkPublishEntry.java	58.82% <58.82%> (ø)
... and 14 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[mukundansundar]

@dapr/maintainers-java-sdk Had a discussion with @shubham1172 on whether to merge BulkSubscribeMessageEntry and BulkPublishEntry classes into a single class or not. As of now what we feel is that it is clearer to have two different set of classes for BulkPublish and BulkSubscribe and not have a common class in-between. There is some duplication, but since the APIs are orthogonal they can be used independently of each other and it will be clearer if we have two sets of classes and not have a common BulkMessageEntry class which will be used by BulkPublish and BulkSubscribe APIs.