+1
On 01/28/2019 10:43，Shannon wrote：
Hello RocketMQ Community,
This is the vote for the kickoff of RIP-10 RocketMQ Unit Test.
You can find the detail of the RIP-10 by below link:
https://docs.google.com/document/d/1DG3nR1j_eQu61mlGa2SLvLDoRfamSVX7Xo8CSJnKE98/
For RocketMQ project, Unit T
某些操作绕过了“自动创建”这个触发导致走了not
exist分支，下次再出现我们再细查一下
best regards,
Jason
> On Sep 4, 2018, at 14:09, 亓杨 wrote:
>
> `2018-09-03 17:53:28 INFO StoreScheduledThread1 - physic disk maybe full
> soon, so reclaim space, -1.0`
> 错误日志 so reclaim space, -1.0.
> -
hi, will,
以下两点需要注意：
1. 检查配置文件命令参数是否正确
2. 这种情况下启动前需要删除整个store数据目录，"refresh" boot
best regards,
Jason
> On Sep 4, 2018, at 09:59, will.happy.will...@gmail.com wrote:
>
> Hi, Jason
> 十分抱歉还得打扰您，我把我们用的所有虚拟机全都重启了一次，然后将数据清理，重新启动集群，发现这个问题还是重在，我们用的是
> 2m-2s-async的，只有其中一个主
对，物理重启
之前强删数据的时候碰过一次，删了shm也不管用，当时没去细查具体机制，索性做了重启快速恢复服务节点。
best regards,
Jason
> On Sep 3, 2018, at 18:39, will.happy.will...@gmail.com wrote:
>
> 刚想起来，我没有重启namesrv，但应该和namesrv无关吧，我只重启了broker并且清了数据。
>
> On 2018/09/03 10:22:55, Jason Joo wrote:
>> 应该是某处缓存没清，一般发生在强停后强删
应该是某处缓存没清，一般发生在强停后强删数据文件之后，一般重启节点（系统）即可解决
best regards,
Jason
> On Sep 3, 2018, at 18:04, will.happy.will...@gmail.com wrote:
>
>
>
> On 2018/09/03 10:01:33, will.happy.will...@gmail.com
> wrote:
>> 具体日志如下：
>> 2018-09-03 17:53:18 WARN StoreScheduledThr
tmq/nsaddr
(唯一的问题是端口固定为8080，之前是fork分支另行维护，现在在生产直接配了8080彻底妥协了)
改变nsaddr文件的内容（或是接口方式），即可实现动态ns服务器列表
但这里需要注意一点，对于broker端与使用端，最好做一个隔离，因为改变地址列表后，broker端注册至新的ns需要一定的时间，而这期间就不保证调用端会不会利用到新的ns服务器，最后导致会出现一些找不到route的错误，而隔离开可以先更新borker端的列表，之后等待新的ns状态一致，再更新调用端的列表定义。
best regards,
Jason
> On Jul 4, 2018,
集即可。
best regards,
Jason
> On Jul 2, 2018, at 15:20, 王伟 wrote:
>
> hi, jason
>
> 我们的服务是分布式布署接收客户端的请求并作响应（移动终端），服务端在收集到数据后发往rocketmq（内网布署，提供外网ip），然后内部程序（内网布署）消费rocketmq拿去数据做后续分析处理，由于数据量较大，所以想尽可能的多利用内网资源以节流量，所以才有这个问题的提出，看看你们是否有这方面成功的方法可分享。
>感谢您的回复。
>
> best wishs。
>
will,
首先我觉得这样的场景并不常见，因为broker并不适合直接公网暴露，容易造成安全问题，所以不知您这是基于什么场景，是否需要变换。
如果场景是异地机房互联，那么可以考虑走一个内网打通，类似ipsec/tunnel相关的方式。
best regards,
Jason
> On Jul 2, 2018, at 14:10, 王伟 wrote:
>
> 您好
>首先，非常感谢您百忙之中这么及时的回复。
>Tcp proxy之前我们有考虑过，但是由于broker的ip是由namesrv返回的，所以这里一直想不通tcp
>
tcp proxy
best regards,
Jason
> On Jul 2, 2018, at 11:30, will.happy.will...@gmail.com wrote:
>
> hi，各位rocketmq的大大位，先简单描述一下应用场景：
>
> 我们使用的模式是 外网生产数据，内网消费数据，这样 broker与 namesrv配置外网IP，是可以解决我们的使用场景的，但是，我们的consumer与
> broker及 namesrv是在同一内网环境的，由于数据量较大，我们想
> 生产的时候使用外网ip，消费的时候
maybe you forgot to set the ENV:
export NAMESRV_ADDR=172.24.150.158:9876
best regards,
Jason
> On Jun 15, 2018, at 15:15, 鳞波微步 <371887...@qq.com> wrote:
>
> Hi,
>
> I follow http://rocketmq.apache.org/docs/quick-start/ to setup RocketMQ and
> test message s
e
time(ms)=1436, bodyLength=907
So the question is:
Is batch sending recommended?
It maybe "slower" compared to simple sending, should i increase the
in-lock-timeout?
how we can solve the performance problem(many REJECTREQUEST will generated in
producers), add new Master into the cluster?
My question
best regards,
Jason
11 matches
Mail list logo
