thetumbled commented on PR #21030:
URL: https://github.com/apache/pulsar/pull/21030#issuecomment-1687306983
> From my understanding now. It should be a problem like a dirty reading.
Right?
>
> Since the design of the topic policy mechanism is the final consensus,
it's a little bit hard for us to fix this kinda situation.
>
> IMO, we can try to define a redirect logic here.
>
> 1. non-partitioned topic policy redirect to owner broker.
> 2. partitioned topic policy redirects to the `partition-0`'s owner broker
as a logical topic leader.
Yes, it is dirty reading problem.
Actually, we have such redirection logic in:
`org.apache.pulsar.broker.admin.impl.PersistentTopicsBase#preValidation`
```
return getPartitionedTopicMetadataAsync(topicName,
false, false)
.thenCompose(metadata -> {
if (metadata.partitions > 0) {
return
validateTopicOwnershipAsync(TopicName.get(topicName.toString()
+ PARTITIONED_TOPIC_SUFFIX + 0),
authoritative);
} else {
return
validateTopicOwnershipAsync(topicName, authoritative);
}
});
```
So we do not need to consider distributed situations. @codelipenghui
> * Defining a `sync` method to let the reader read the end of the topic at
that moment is better than saving the operation future everywhere from my point
of view.
Currently, we have two places need to read the messages, the first one is in
the backgroup thread triggered by reader.readNextAsync() asynchronously, the
second one is here.
To achieve strong concurrency control, maybe we could make the whole setting
logic running synchronously in same thread for each topic, which will make
break change.
IMO, i don't see any drawback of this solution in synchronous requests
situations, which is the basic situations and enough for users.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
