Re: [GSOC2018][ROCKETMQ-379] Support AMQP protocol for RocketMQ-Proposal

[Ratnasingam Kasthuriraajan]

Thank you so much yukon.

I'll upload it. i'm eagerly waiting to work with you on this project.

Thank you.

On Mon, Mar 26, 2018 at 9:01 AM, yukon  wrote:

> Looks great, let's upload it.
>
> On Mon, Mar 26, 2018 at 6:21 AM, Ratnasingam Kasthuriraajan <
> kasthuriraaja...@gmail.com> wrote:
>
>> Hi Yukon, Von
>>
>> I have updated my draft proposal in a new link with the appropriate
>> could you please check it.
>>
>> https://docs.google.com/document/d/1YOFbdlfPrels6A9lHMqDTdJ6
>> VjPF_XRBgVj7S_oEVtI/edit?usp=sharing
>>
>> Once you check it, I can upload it into the GSOC page.
>>
>> Thanks & Reegards
>> R.Kasthuriraajan
>> --
>> R.Kasthuriraajan.
>> Undergraduate student | Department of Computer Science,
>> Faculty of Science | University of Jaffna.
>>
>> LinkedIn: https://www.linkedin.com/in/ratnasingam-kasthurira
>> ajan-2a6892121/
>> 
>> stackoverflow: https://stackoverflow.com/users/8870269/
>> kasthuriraajan?tab=profile
>> GitHub: https://github.com/kasthuriraajan
>> Medium: https://medium.com/@Kasthuriraajan
>>
>>
>


-- 
R.Kasthuriraajan.
Undergraduate student | Department of Computer Science,
Faculty of Science | University of Jaffna.

LinkedIn: https://www.linkedin.com/in/ratnasingam-kasthuriraajan-2a6892121/

stackoverflow:
https://stackoverflow.com/users/8870269/kasthuriraajan?tab=profile
GitHub: https://github.com/kasthuriraajan
Medium: https://medium.com/@Kasthuriraajan

Re: [GSOC2018][ROCKETMQ-379] Support AMQP protocol for RocketMQ-Proposal

[yukon]

Looks great, let's upload it.

On Mon, Mar 26, 2018 at 6:21 AM, Ratnasingam Kasthuriraajan <
kasthuriraaja...@gmail.com> wrote:

> Hi Yukon, Von
>
> I have updated my draft proposal in a new link with the appropriate  could
> you please check it.
>
> https://docs.google.com/document/d/1YOFbdlfPrels6A9lHMqDTdJ6VjPF_
> XRBgVj7S_oEVtI/edit?usp=sharing
>
> Once you check it, I can upload it into the GSOC page.
>
> Thanks & Reegards
> R.Kasthuriraajan
> --
> R.Kasthuriraajan.
> Undergraduate student | Department of Computer Science,
> Faculty of Science | University of Jaffna.
>
> LinkedIn: https://www.linkedin.com/in/ratnasingam-
> kasthuriraajan-2a6892121/
> 
> stackoverflow: https://stackoverflow.com/users/8870269/kasthuriraajan?tab=
> profile
> GitHub: https://github.com/kasthuriraajan
> Medium: https://medium.com/@Kasthuriraajan
>
>

Re: The State of RocketMQ Streaming Integration

[Xin Wang]

Hi folks,

I'm glad to say that the RocketMQ-Flink module has been merged into master.
https://github.com/apache/rocketmq-externals/tree/master/rocketmq-flink

Here is the state of rocketmq streaming integration:
   ModuleStatus
* RocketMQ-Storm*Available*
* RocketMQ-Spark*Available*, *The improvements will be available soon*.
* RocketMQ-Flink *Available*
* RocketMQ-Serializer(including JSON, Apache Avro)*Available*, *Not
merged yet*.

And, some new modules on the road:
* RocketMQ-SQL  https://issues.apache.org/jira/browse/ROCKETMQ-357
* RocketMQ-Beam(Beam IO)


Anybody who is interested in these tasks too, please join me. Let's fight
together.


Thanks,
Xin Wang



2018-01-27 19:35 GMT+08:00 Xin Wang :

> Hi devs,
>
> I'd like to update the state of RocketMQ Streaming Integration:
> Now the task for RocketMQ-Flink  integration is completed and  patch is
> available here: https://github.com/apache/rocketmq-externals/pull/45
> Following is the brief changelog:
>
>- RocketMQSource - The RocketMQSource is based on RocketMQ pull
>consumer mode, and provides exactly once reliability guarantees when
>checkpoints are enabled.
>Otherwise, the source doesn't provide any reliability guarantees.
>- RocketMQSink - The RocketMQSink provides at-least-once reliability
>guarantees when checkpoints are enabled and withBatchFlushOnCheckpoint
>(true) is set.
>Otherwise, the sink reliability guarantees depends on rocketmq
>producer's retry policy, for this case, the messages sending way is sync by
>default,
>but you can change it by invoking withAsync(true).
>- KeyValueDeserializationSchema - The main API for deserializing topic
>and tags is the org.apache.rocketmq.flink.common.serialization.
>KeyValueDeserializationSchema interface.
>rocketmq-flink includes general purpose KeyValueDeserializationSchema 
> implementations
>called SimpleKeyValueDeserializationSchema.
>- KeyValueSerializationSchema - The main API for serializing topic and
>tags is the org.apache.rocketmq.flink.common.serialization.
>KeyValueSerializationSchema interface.
>rocketmq-flink includes general purpose KeyValueSerializationSchema 
> implementations
>called SimpleKeyValueSerializationSchema.
>- TopicSelector - The main API for selecting topic and tags is the
>org.apache.rocketmq.flink.common.selector.TopicSelector interface.
>rocketmq-flink includes general purpose TopicSelector implementations
>called DefaultTopicSelector and SimpleTopicSelector.
>- RocketMQFlinkExample - which receive messages from RocketMQ brokers
>and send messages to broker after processing.
>
> Any comments are welcome. And anybody who is also interested in these
> tasks, please join me. Let's fight together.
>
> Thanks,
> Xin Wang
>
>
> 2018-01-19 21:47 GMT+08:00 yukon :
>
>> Cool, thanks for your outstanding contribution, to help RocketMQ community
>> integrate with other streaming platforms.
>>
>> On Fri, Jan 19, 2018 at 7:52 PM, Xin Wang  wrote:
>>
>> > Hi devs,
>> >
>> > I have finished the improvements for integrating RocketMQ with Apache
>> > Storm.
>> > Main changes are as following:
>> >
>> >- Upgraded RocketMQ version to 4.2.0 which brings improvements and
>> new
>> >features like batch sending
>> >- Imporved retry policy for RocketMQ consumer push mode to avoid data
>> >loss in some scenes
>> >- Batch sending supported for bolt and trident state
>> >- Allow running several consumer instances in one process, that is to
>> >say, different topics in one worker is possible
>> >
>> > PR: https://github.com/apache/storm/pull/2518
>> >
>> > And I submit the `RocketMQ-Serializer` patch several days ago. This
>> module
>> > includes several serialization formats, especially Apache Avro which I
>> > stated before[1].
>> >
>> >- Raw String
>> >- JSON
>> >- Avro Generic
>> >- Avro Specified
>> >
>> > PR: https://github.com/apache/rocketmq-externals/pull/42
>> >
>> > Any comments for these PRs are welcome. BTW here is the state of
>> rocketmq
>> > streaming integration:
>> >ModuleStatus
>> > * RocketMQ-StormPatch Available
>> > * RocketMQ-SparkTo Refactor
>> > * RocketMQ-Flink Patch Available Soon
>> > * RocketMQ-Serializer Patch Available
>> >
>> > Anybody who is also interested in these tasks, please join me. Let's
>> fight
>> > together.
>> >
>> >
>> > [1] https://issues.apache.org/jira/browse/ROCKETMQ-157
>> >
>> >
>> > Thanks,
>> >
>> > Xin Wang (vesense)
>> >
>>
>
>
>
> --
> Thanks,
> Xin
>



-- 
Thanks,
Xin

[GSOC2018][ROCKETMQ-379] Support AMQP protocol for RocketMQ-Proposal

[Ratnasingam Kasthuriraajan]

Hi Yukon, Von

I have updated my draft proposal in a new link with the appropriate  could
you please check it.

https://docs.google.com/document/d/1YOFbdlfPrels6A9lHMqDTdJ6VjPF_XRBgVj7S_oEVtI/edit?usp=sharing

Once you check it, I can upload it into the GSOC page.

Thanks & Reegards
R.Kasthuriraajan
-- 
R.Kasthuriraajan.
Undergraduate student | Department of Computer Science,
Faculty of Science | University of Jaffna.

LinkedIn: https://www.linkedin.com/in/ratnasingam-kasthuriraajan-2a6892121/

stackoverflow:
https://stackoverflow.com/users/8870269/kasthuriraajan?tab=profile
GitHub: https://github.com/kasthuriraajan
Medium: https://medium.com/@Kasthuriraajan

Re: [GSOC|ROCKETMQ-122] Support Global Ordered Messaging

[sowmya s]

Hi Yukon,

I am sorry for the confusion regarding the google doc, here is the link
again, https://drive.google.com/file/d/1nXktUO_TF9-
rSHSnGj5z5QZoHzMhosxm/view?usp=sharing

Regarding the hotpot issue, In my document, under the section Optimizing
for performance, I had a similar approach to what you mentioned, If the
Producer or the implementation of a Global Ordered Producer, attaches to
the Message or message properties, an additional attribute which is an
atomic counter that gets incremented for every message sent, in combination
with the topic and the unique producer group, the messages get to
potentially different brokers under different queues.

>From the consumer perspective, having a custom RebalanceImplementation and
also a custom Implementation for a MQConsumer which can be a Pull or push
consumer that orders based on the property we set above in the Global
Ordered Producer and sort by producer group, topic all the messages.

thanks,
Sowmya

On Fri, Mar 23, 2018 at 4:48 AM, yukon  wrote:

> Hi,
>
> I added some comments, but it seems your google doc link isn't shared:
>
> ```
> To resolve this issue, we need a global ordered messaging mechanism to have
> a good scalability without hot-pot issue.
>
> A practical proposal is that sending messages to distributed
> queue/partition with an ordered key. Messages are ordered in the same
> queue, then implement an OrderConsumer to pull messages from these queues
> then perform merge sort, finally deliver these ordered messages to users.
> ```
> As mentioned in ROCKETMQ-122, we should address the hot-pot issue.
>
> That means the messages can be sent to multiple distributed
> queues/partitions and still can be consumed in order manner.
>
> A simple explanation of hot-pot issue:
>
> Assume that all the generated messages in a hot shop of taobao/amazon
> should be consumed in order, in the current state, these massive messages
> should be sent to a fixed queue/partition, surely to a fixed server which
> may cause high pressure in this server. You can easily infer that we can't
> resolve this issue through extending the scale of broker cluster.
>
> Could your arch resolve this hot-pot issue?
>
> Regards,
> yukon
>
>
> On Thu, Mar 22, 2018 at 2:15 PM, sowmya s  wrote:
>
> > It's going great.
> > In the DefaultMessageStore, there is a class
> > CommitLogDispatcherBuildConsumeQueue, I think that a variant of that
> class
> > or another implementation which are merged from the commitlog,
> > Since the DispachRequest has a store timestamp, the queue can be
> populated
> > based on that time stamp.
> >
> > Also, I have some more questions,
> > Does the fleet of broker slaves all store the various commit logs that
> are
> > received by them or is the commit log store, replication managed by the
> > broker controller?
> >
> > The other direction I was thinking about is adding/modifying the
> > PullAPIWrapper, since the DefaultMQPushConsumerImpl uses the
> > DefaultMQPullConsumerImpl and that uses the PullAPIWrapper, maybe adding
> > this change there will solve the merge issue for the consumers.
> >
> > Do you think I am on the right track?
> >
> > thanks,
> > Sowmya
> >
> >
> >
> > On Mon, Mar 19, 2018 at 8:15 PM, yukon  wrote:
> >
> > > Hi,
> > >
> > > Sorry for the late reply.
> > >
> > > As for:
> > >
> > > ```
> > > I'm looking at the BrokerController and MessageStore implementation and
> > > hooks to understand where the merge logic will best fit.
> > > ```
> > >
> > > how is it going?
> > >
> > > Regards
> > >
> > > On Sat, Mar 17, 2018 at 11:30 AM, sowmya s 
> wrote:
> > >
> > > > Thank you yukon,
> > > >
> > > > I'm done with my coursework for this semester and have more time now
> to
> > > > improve my proposal.
> > > > I'm looking at the BrokerController and MessageStore implementation
> and
> > > > hooks to understand where the merge logic will best fit. So far I've
> > > looked
> > > > at the codebase from a Producer and Consumer perspective and looked
> at
> > > the
> > > > DefaultMQProducerImpl and  DefaultMQPushConsumerImpl for
> understanding
> > > the
> > > > link between how Producers send and Consumers receive messages.
> > > >
> > > > thanks,
> > > > Sowmya
> > > >
> > > > On Fri, Mar 16, 2018 at 8:07 PM, yukon  wrote:
> > > >
> > > > > Cool, let's focus on it and see whether is there anything can be
> > > > polished.
> > > > >
> > > > > Regards
> > > > >
> > > > > On Fri, Mar 16, 2018 at 11:54 PM, sowmya s 
> > > wrote:
> > > > >
> > > > > > Hey yukon,
> > > > > > I submitted my draft on the summer of code homepage a couple of
> > days
> > > > ago,
> > > > > > also attaching the link here for reference,
> > > > > >
> > > > > > https://docs.google.com/file/d/1nXktUO_TF9-
> > > rSHSnGj5z5QZoHzMhosxm/edit?
> > > > > > usp=docslist_api=msword
> > > > > >
> > > > > > Thanks,
> > > > > > Sowmya
> > > > > >
> > > > > > On Thu, Mar 

[GitHub] 1061235166 opened a new issue #251: cant start broker.sh

[GitBox]

1061235166 opened a new issue #251: cant start broker.sh
URL: https://github.com/apache/rocketmq/issues/251
 
 
   version：4.2.0
   enviroment：centos7 at vmAware
   memory size：2G
   can start namesvr，but cant start broker.sh，there is log
   ---
   OpenJDK 64-Bit Server VM warning: If the number of processors is expected to 
increase from one, then you should configure the number of parallel GC threads 
appropriately using -XX:ParallelGCThreads=N
   OpenJDK 64-Bit Server VM warning: INFO: 
os::commit_memory(0x0005c000, 8589934592, 0) failed; error='Cannot 
allocate memory' (errno=12)
   #
   # There is insufficient memory for the Java Runtime Environment to continue.
   # Native memory allocation (mmap) failed to map 8589934592 bytes for 
committing reserved memory.
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: [GSoC][ROCKETMQ-372] Providing a REST Proxy to Support HTTP/2 Protocol

[Menuka Warushavithana]

Hi,
I have updated the project proposal [1]
.
Please let me know if there's any section that needs to be improved.

[1] https://goo.gl/rsrNgz


Thanks and Regards,
Menuka

On 25 March 2018 at 11:41, Menuka Warushavithana 
wrote:

> Hi,
> Thanks for the information. I have shared a draft proposal through the
> official GSoC site. I would be much obliged if you could help me improve it.
>
> Thank you
>
> On 23 March 2018 at 17:32, yukon  wrote:
>
>> Hi,
>>
>> There are many restful style APIs can be good references, include the
>> commercial messaging products(aws, azure, etc).
>>
>> Regards
>>
>> On Wed, Mar 21, 2018 at 6:38 PM, Menuka Warushavithana <
>> menuka...@cse.mrt.ac.lk> wrote:
>>
>>> Hi,
>>> Just to get an idea, will this API [1] used in RabbitMQ be a good
>>> reference when writing the proposal?
>>>
>>>
>>> [1] https://www.cloudamqp.com/docs/http.html
>>> 
>>>
>>> Thank you,
>>> Menuka
>>>
>>> On 20 March 2018 at 08:43, yukon  wrote:
>>>
 Hi,

 Some concepts in Linkerd are very valuable and can be used as a
 reference.

 But, It's ok if you want to use Linkerd directly for some necessary
 reasons.

 Regards

 On Mon, Mar 19, 2018 at 10:59 PM, Menuka Warushavithana <
 menuka...@cse.mrt.ac.lk> wrote:

 > Hi,
 > Thanks for the info. Are we going to use Linkerd [1] directly in
 > implementing the proxy server, or is it only to be used as a
 reference?
 >
 > [1] https://linkerd.io/
 > 
 >
 > Best Regards,
 > Menuka
 >
 > On 19 March 2018 at 07:13, yukon  >
 > wrote:
 >
 > > Hi, the current protocol is customized, please see:
 > >
 > >  2Frocketmq%2Ftree%2Fmaster%2Fremoting%2Fsrc%2Fmain%2Fjava%2F
 org%2Fapache%
 > 2Frocketmq%2Fremoting%2Fprotocol/QE9YmLinIw2A3pLINZj4>
 > > https://github.com/apache/rock
 > >  2Frock/QE9YmLinIw2A3pLINZj4>
 > > etmq/tree/master/remoting/src/main/java/org/apache/rocketmq/
 > > remoting/protocol
 > >
 > > On Mon, Mar 19, 2018 at 2:06 AM, Menuka Warushavithana <
 > > menuka...@cse.mrt.ac.lk
 > >  QE9YmLinIw2A3pLINZj4>>
 > > wrote:
 > >
 > > > Hi Yukon,
 > > > It is mentioned in the JIRA issue [1] that, "So far, RocketMQ
 uses a
 > > > customized communication protocol between client and server which
 is
 > > > efficient but limited". However, I could not find the said method
 in
 > the
 > > > documentation. It would be appreciated if you could help me
 understand
 > > the
 > > > current communication protocol, please.
 > > >
 > > >
 > > > [1]
 > >  2Fjira%2Fbrowse%2FROCKETMQ-372/QE9YmLinIw2A3pLINZj4>
 > > https://issues.apache.org/jira
 > >  2Fjira/QE9YmLinIw2A3pLINZj4>
 > > /browse/ROCKETMQ-372
 > > > <
 > >  2Fjira%2Fbrowse%2FROCKETMQ-372/QItHTjI9X8newkTsyIw0>
 > > https://mltrk.io/link/https%3A%2F%2Fissues.apache.org%2Fjir
 > > a%2Fbrowse%2FROCKETMQ-372/QItHTjI9X8newkTsyIw0>
 > > >
 > > > Best Regards,
 > > > Menuka
 > > >
 > > > On 17 March 2018 at 14:19, Menuka Warushavithana <
 > > menuka...@cse.mrt.ac.lk
 > >  QE9YmLinIw2A3pLINZj4>
 > > >
 > > > wrote:
 > > >
 > > >> Hi Yukon,
 > > >> I will continue the discussion (which was started on JIRA) here.
 I
 > went
 > > >> through all examples described in the docs [1] and I'm currently
 > > studying
 > > >> Linkerd [2] to get an idea of implementing the proxy server.
 > > >>
 > > >> In the meantime, I would appreciate your ideas on designing the
 REST
 > > APIs
 > > >> to produce/consume messages.
 > > >>
 > > >>
 > > >> [1]
 > >  2Fdocs%2Fquick-start%2F/QE9YmLinIw2A3pLINZj4>
 > > https://rocketmq.apache.org/do
 > >  2Fdo/QE9YmLinIw2A3pLINZj4>
 > > cs/quick-start/
 > > >> <
 > > 

Re: [GSOC][ROCKETMQ-380] Provide a modern and friendly console for RocketMQ

[Ahmed Ifhaam]

hi yukon,


I have started implementation. So far i have successfully integrated Apache
Shiro in to current console. APIs for login, logout and current user
details has been created. [1]

Here
you can find my progress. Since this is working successful any current API
or a future API can be easily updated to work with Authentication and
Access control with a single annotation.

I kindly request you to take a look at my proposal and give a feedback if
any changes needed. [2]


[1]
https://github.com/ahmedifhaam/rocketmq-externals/tree/release-rocketmq-console-1.0.0
[2]
https://docs.google.com/document/d/1NlhrthJd8b7CsZOqZ1tZpinz35k_DqSDYev52rtS7iU/edit?usp=sharing

Thank you.

On Fri, Mar 23, 2018 at 2:30 PM, Ahmed Ifhaam 
wrote:

> hi yukon,
>
> I didn't get any feedback for my last reply, I have prepared the draft
> proposal selecting Apache Shiro.
> Please help me finalizing the proposal, I would love to get some feedback
> from you for the proposal.
> https://docs.google.com/document/d/1NlhrthJd8b7CsZOqZ1tZpinz35k_
> DqSDYev52rtS7iU/edit?usp=sharing
>
>
> Thank you.
>
> On Tue, Mar 20, 2018 at 11:21 PM, Ahmed Ifhaam 
> wrote:
>
>> hi again,
>>
>> I'm drafting my proposal which will introduce my design of the system i'm
>> planning to work on.
>> Regarding the ACL integration, i have few choices since this product
>> should evolve more i would love to get the suggestions and decide one.
>>
>> Four options:
>>
>> 1. Apache Shiro [1] 
>>
>> As everyone knows a framework developed usability in mind, capable of
>> incorporating into spring-boot applications are very high
>>
>> Also this product has proven quality. Main pro i see in this is
>> extendability in future.
>>
>> 2. SPRING ACL [2] 
>>
>> Something developed and evolved specially for spring. Has most of the
>> required features built in already.
>>
>> But this product has been declared as not very capable to extend in
>> future and not user friendly in most blog posts and stack-overflow questions
>>
>> People have written sometimes they had to rollback and move to a custom
>> ACL module later (ex : [3]
>> 
>> )
>>
>> 3. Custom ACL from scratch
>>
>> Fourth option is to develop one module which will cover the requirement
>> from the scratch.
>>
>> 4. Custom ACL Module using JAVA ACL [4]
>> 
>>
>> This option which i will design and develop a simple ACL module for our
>> need using ACL packages built in with java. Wont be having all the features
>> and capabilities of the above mentioned frameworks but will simple and will
>> only serve the purpose
>>
>>
>> I have mentioned these in the order i prefer to use and this link has few
>> more frameworks and a small comparison [5]
>> 
>> .
>> I'm very much interested in using Shiro. I'm kindly requesting you to
>> help me select one on of these or suggest anything better if there is.
>>
>> [1] http://shiro.apache.org/web-features.html
>> [2] http://www.baeldung.com/spring-security-acl
>> [3] https://stackoverflow.com/questions/3976486/is-spring-ac
>> l-a-good-acl-implementation
>> [4] https://docs.oracle.com/javase/7/docs/api/java/security/acl/Acl.html
>> [5] http://are-you-ready.de/blog/2017/01/25/apache-shiro-par
>> t-1-selecting-a-java-security-framework/
>>
>>
>> Thank you.
>>
>> On Tue, Mar 20, 2018 at 3:53 PM, Ahmed Ifhaam 
>> wrote:
>>
>>> Yeah,
>>> I'm already working on it. Doing some search on how to integrate user
>>> management and authentication to the system, once its done i'll draft the
>>> design.
>>> Thank you
>>>
>>> On Tue, Mar 20, 2018 at 8:36 AM, yukon  wrote:
>>>
 Hi,

 I think it's acceptable, and it's time to draft the proposal, right?

 Regards

 On Mon, Mar 19, 2018 at 6:23 PM, Ahmed Ifhaam 
 wrote:

 > hi Gosling,Yukon,
 >
 > On my understanding even if we implement two different consoles we
 should
 > implement an authentication method because most of these commands may
 cause
 > considerable problems if used without proper understanding. And then
 we
 > have to implement the same already available features in the new
 console as
 > well. so i think its better to implement role based one in the same
 console
 > I had a doubt and i was waiting to clarify from you,Currently
 > Authentication is optional, so if we are to do role based one, the
 idea i
 > 

Re: [GSoC][ROCKETMQ-372] Providing a REST Proxy to Support HTTP/2 Protocol

[Menuka Warushavithana]

Hi,
Thanks for the information. I have shared a draft proposal through the
official GSoC site. I would be much obliged if you could help me improve it.

Thank you

On 23 March 2018 at 17:32, yukon  wrote:

> Hi,
>
> There are many restful style APIs can be good references, include the
> commercial messaging products(aws, azure, etc).
>
> Regards
>
> On Wed, Mar 21, 2018 at 6:38 PM, Menuka Warushavithana <
> menuka...@cse.mrt.ac.lk> wrote:
>
>> Hi,
>> Just to get an idea, will this API [1] used in RabbitMQ be a good
>> reference when writing the proposal?
>>
>>
>> [1] https://www.cloudamqp.com/docs/http.html
>> 
>>
>> Thank you,
>> Menuka
>>
>> On 20 March 2018 at 08:43, yukon  wrote:
>>
>>> Hi,
>>>
>>> Some concepts in Linkerd are very valuable and can be used as a
>>> reference.
>>>
>>> But, It's ok if you want to use Linkerd directly for some necessary
>>> reasons.
>>>
>>> Regards
>>>
>>> On Mon, Mar 19, 2018 at 10:59 PM, Menuka Warushavithana <
>>> menuka...@cse.mrt.ac.lk> wrote:
>>>
>>> > Hi,
>>> > Thanks for the info. Are we going to use Linkerd [1] directly in
>>> > implementing the proxy server, or is it only to be used as a reference?
>>> >
>>> > [1] https://linkerd.io/
>>> > >> w2A3pLINZj4>
>>> >
>>> > Best Regards,
>>> > Menuka
>>> >
>>> > On 19 March 2018 at 07:13, yukon >> > >> w2A3pLINZj4>>
>>> > wrote:
>>> >
>>> > > Hi, the current protocol is customized, please see:
>>> > >
>>> > > >> > 2Frocketmq%2Ftree%2Fmaster%2Fremoting%2Fsrc%2Fmain%2Fjava%2F
>>> org%2Fapache%
>>> > 2Frocketmq%2Fremoting%2Fprotocol/QE9YmLinIw2A3pLINZj4>
>>> > > https://github.com/apache/rock
>>> > > >> > 2Frock/QE9YmLinIw2A3pLINZj4>
>>> > > etmq/tree/master/remoting/src/main/java/org/apache/rocketmq/
>>> > > remoting/protocol
>>> > >
>>> > > On Mon, Mar 19, 2018 at 2:06 AM, Menuka Warushavithana <
>>> > > menuka...@cse.mrt.ac.lk
>>> > > >> > QE9YmLinIw2A3pLINZj4>>
>>> > > wrote:
>>> > >
>>> > > > Hi Yukon,
>>> > > > It is mentioned in the JIRA issue [1] that, "So far, RocketMQ uses
>>> a
>>> > > > customized communication protocol between client and server which
>>> is
>>> > > > efficient but limited". However, I could not find the said method
>>> in
>>> > the
>>> > > > documentation. It would be appreciated if you could help me
>>> understand
>>> > > the
>>> > > > current communication protocol, please.
>>> > > >
>>> > > >
>>> > > > [1]
>>> > > >> > 2Fjira%2Fbrowse%2FROCKETMQ-372/QE9YmLinIw2A3pLINZj4>
>>> > > https://issues.apache.org/jira
>>> > > >> > 2Fjira/QE9YmLinIw2A3pLINZj4>
>>> > > /browse/ROCKETMQ-372
>>> > > > <
>>> > > >> > 2Fjira%2Fbrowse%2FROCKETMQ-372/QItHTjI9X8newkTsyIw0>
>>> > > https://mltrk.io/link/https%3A%2F%2Fissues.apache.org%2Fjir
>>> > > a%2Fbrowse%2FROCKETMQ-372/QItHTjI9X8newkTsyIw0>
>>> > > >
>>> > > > Best Regards,
>>> > > > Menuka
>>> > > >
>>> > > > On 17 March 2018 at 14:19, Menuka Warushavithana <
>>> > > menuka...@cse.mrt.ac.lk
>>> > > >> > QE9YmLinIw2A3pLINZj4>
>>> > > >
>>> > > > wrote:
>>> > > >
>>> > > >> Hi Yukon,
>>> > > >> I will continue the discussion (which was started on JIRA) here. I
>>> > went
>>> > > >> through all examples described in the docs [1] and I'm currently
>>> > > studying
>>> > > >> Linkerd [2] to get an idea of implementing the proxy server.
>>> > > >>
>>> > > >> In the meantime, I would appreciate your ideas on designing the
>>> REST
>>> > > APIs
>>> > > >> to produce/consume messages.
>>> > > >>
>>> > > >>
>>> > > >> [1]
>>> > > >> > 2Fdocs%2Fquick-start%2F/QE9YmLinIw2A3pLINZj4>
>>> > > https://rocketmq.apache.org/do
>>> > > >> > 2Fdo/QE9YmLinIw2A3pLINZj4>
>>> > > cs/quick-start/
>>> > > >> <
>>> > > >> > 2Fdocs%2Fquick-start%2F/lFINZX2DO0vBptcSPse6>
>>> > > https://mltrk.io/link/https%3A%2F%2Frocketmq.apache.org%2Fd
>>> > > ocs%2Fquick-start%2F/lFINZX2DO0vBptcSPse6>
>>> > > >> [2] https://linkerd.io/
>>> > > >> w2A3pLINZj4>
>>> > > >> <
>>> > > >> 0vBptcSPse6>
>>> > > https://mltrk.io/link/https%3A%2F%2Flinkerd.io%2F/lFINZX2DO0
>>> vBptcSPse6>
>>> > > >>
>>> > > >> Thank You,
>>> > > >> --
>>>