ion. And the session id should be
> >> persistent
> >>>> on the disk for producer. So the broker only need to maintain a map
> >>> between
> >>>> session id to expected message id(And this is how Kafka do it). Since
> >>>> messages a
to expected message id(And this is how Kafka do it). Since
>>>> messages are much more than producers. However, there's still a K/V
>> store
>>>> needed. So we have to ask RocketMQ team about how many producers in the
>>>> same time while in practical situation.
>>>>
&
Hi Yukon,
Thanks for your reply. Yes, it would be nice to concretely define the scope
of this project as the doc is a bit ambitious for just a summer. Should you
(or anyone else) have questions/suggestions/clarifications I'd be glad to
discuss more details.
Thanks,
Sohaib
On Wed, Mar 7, 2018 at
Hi,
Google doc is better for discussion, your design is great, now we could
discuss more details base on it.
Any advice is welcome from RocketMQ community.
Appreciate your efforts.
Regards,
yukon
On Wed, Mar 7, 2018 at 5:15 AM, Sohaib Iftikhar
wrote:
> Hi,
>
> @Yukon Thank you for your reply
Hi,
@Yukon Thank you for your reply. This clears some doubts.
Sorry for the delay as I was somewhat occupied with another project. I have
created an initial design doc. Email is a bit cumbersome for feedback I
wrote this document in two formats:
1. In the form of a Google document:
https://docs.
Hi Sohaib,
Sorry for the late reply, we could move this project forward now ~
```
I would at some point like to post
design ideas to this problem privately to get it reviewed by the
development community but not make it publicly available so that it cannot
be plagiarised.
```
You can send your d
@Zhanhui Thanks for the response. This is not a campaign its just part of
GSoC (https://summerofcode.withgoogle.com/). And community help is gladly
welcomed. In fact, it is recommended :)
@KaiYuan Thanks for your suggestions. I will come up with a flow chart for
the proposed solution this weekend.
Hi Sohaib,
I have been sort of busy this these days. Sorry to reply you so late!
So sure what “deadline” you are referring to. If this is part of a campaign, I
have to admit I am not aware of the regulations and what kind of help I should
offer to maintain fairness considering other arising sim
solution with a flow chart first.
Then that's convenient for other people to give their opinion.
Regards,Mark--发件人：Sohaib
Iftikhar 发送时间：2018年3月1日(星期四) 03:43收件人：dev
主 题：Re: [GSOC|ROCKETMQ-124] Support non-redundant
message del
Hi guys,
Would be nice to have some feedback on this as the deadline is not too far
:)
Thanks,
Sohaib
Regards,
Sohaib Iftikhar
-- Man is still the most extraordinary computer of all.--
On Mon, Feb 26, 2018 at 10:36 AM, Sohaib Iftikhar
wrote:
> Thank you for the pointers to the code. This was
Thank you for the pointers to the code. This was super helpful. The
multiple keys can probably be serialized better than separating them with a
space but that is already legacy I suppose.
Firstly filters like bloom or cuckoo are heuristic. They can help make
things faster but definitely cannot be
Hi Zhanhui,
I have a doubt about these multiple keys. If I am wrong in any of the
assumptions I make please point it out.
If there is support for multiple keys I cannot see this in the code. The
class Message only stores a single key in the property map against the
property name "KEYS". Is this a
Hi Sohaib,
Happy to know you are interested in RocketMQ.
First, let me answer questions you raised.
— can there be multiple tags?
No. At present, the storage engine allows single tag only. Subscriptions are
allowed to use combination of tags. The current model should meet your business
develop
My earlier email message seems to have gotten lost. So I will try again.
Please see the original message for the discussion.
Regards,
Sohaib Iftikhar
-- Man is still the most extraordinary computer of all.--
On Tue, Feb 20, 2018 at 1:54 AM, Sohaib Iftikhar
wrote:
> Hi,
>
> I am interested in w
14 matches
Mail list logo
