Re: is it possible to use FQDN instead of IP in riak.conf for "listener.http.$name” field?
Hi Roman,
my guess is that you can use 0.0.0.0 as IP address which means "listen on
every network device", so if the IP address changes you don't need to
change anything in the config. Please double check this.
Richard
On Wed, Jul 22, 2015 at 7:03 PM, Nick Marino wrote:
> Hi Roman,
>
> I took a quick look at the riak_api code, and unfortunately it doesn't
> look like there's an easy way to do this right now. The code assumes you'll
> enter an IP address, and there's no place where it would attempt to resolve
> a hostname if you passed that in instead.
>
> That said, this does seem like it would be a nice feature to have, and
> probably shouldn't be terribly difficult to implement. If you have a GitHub
> account you could try logging a feature request under the issues section
> for the riak_api project (https://github.com/basho/riak_api). I can't
> make any guarantees as to whether/when anyone will have time to look into
> it, but hopefully it's something that could be done in the short to medium
> term. If you don't have a GitHub account and would like me to enter this
> for you, send me an email and I can get a request filed.
>
> In the mean time, your best bet is probably to write a script to
> automatically regenerate your config file with the correct IP addresses as
> needed. Not the prettiest solution, but unfortunately that's the best
> suggestion I have for the time being.
>
> Thanks,
> Nick
>
> On Mon, Jul 20, 2015 at 4:48 PM, ROMAN SHESTAKOV <
> romanshesta...@yahoo.co.uk> wrote:
>
>>
>> Hello,
>>
>> is there any way to specify in riak.conf in field "listener.http.$name”
>> FQDN instead of IP address?
>>
>> >>>listener.http.$name This is the IP address and TCP port to which the
>> Riak HTTP interface will bind. {"127.0.0.1",8098}<<<
>>
>> why is it required to use IP address instead of a host name? In my
>> setting RIAK_KV is deployed on dynamic VMs and IP could be changed if the
>> VM is launched on a different hypervisor.
>>
>> Regards, Roman
>>
>>
>> ___
>> riak-users mailing list
>> riak-users@lists.basho.com
>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>
>
>
> ___
> riak-users mailing list
> riak-users@lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>
>
--
Richard Jonas
Erlang Solutions Hungary Kft
Address:
Riverpark Office K.32
Közraktár street 32. 3/1.
1093 Budapest
Hungary
Phone/fax:
+36-1-7000-654
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: Undiagnosed High FSM Time
You may want to monitor - node_put_fsm_rejected (and get, too) to if overload protection rejected put or get requests - node_put_fsm_active, node_put_fsm_active_60s (to see how many active put requests are being served now and in the last minute) there is metrics for get, too. A spike of those metrics can show you a hint that something unusual happens. A big object can cause a lot of put fsms, since big object can cause head-of-line-blocking inside the cluster. So the problem is not with serving the get/put for the big objects, but the puts/gets coming after that. Like during driving pushing a hard brake won't cause you traffic jam, but the others behind you. On Tue, Jan 26, 2016 at 10:43 PM, Alex Wolfe wrote: > Thanks for your reply. > > We are. We sort of expected an anomaly in the object size, but there was > none. We found the root cause. It was a large number of additions to a > single set. It’s not clear to me which metric reveals that problem, but it > appears as though object size doesn’t. > > Alex > > > > On Jan 26, 2016, at 3:40 PM, Luke Bakken wrote: > > > > Hi Alex - > > > > Are you monitoring any of Riak's statistics? Specifically object size > > and sibling count, though all of the stats are useful. > > > > -- > > Luke Bakken > > Engineer > > lbak...@basho.com > > > > On Tue, Jan 26, 2016 at 11:40 AM, Alex Wolfe > wrote: > >> We have a 5 node Riak cluster running 2.1.1. This morning FSM Time > (99th percentile) went way up. We couldn't find any clear signs of trouble > with the cluster and ultimately chose to move the data files and restart > the nodes. Once we started with an empty DB, the FSM Time normalized. But > now it's headed back up again. We're stumped on how to trouble shoot this > issue. Any suggestions? > >> ___ > >> riak-users mailing list > >> riak-users@lists.basho.com > >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > ___ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > -- Richard Jonas Erlang Solutions Hungary Kft Address: Riverpark Office K.32 Közraktár street 32. 3/1. 1093 Budapest Hungary Phone/fax: +36-1-7000-654 ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
riak-erlang-client
Guys, most of the examples I can see that riak erlang client processes cannot be shared with multiple processes. Is it safe if more processes use the same riak connection? So in other words: is riak erlang client thread-safe? Thanks -- Richard Jonas Erlang Solutions Hungary Kft Address: Riverpark Office K.32 Közraktár street 32. 3/1. 1093 Budapest Hungary Phone/fax: +36-1-7000-654 ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: riak-erlang-client
Thank you for the quick answer. On Wed, May 25, 2016 at 4:13 PM, Nick Marino wrote: > Hi Richard, > > Yes, sharing a riak-erlang-client connection process among multiple Erlang > processes should not cause any problems. The riak_pb_socket processes are > implemented using a gen_server, and they use a queuing mechanism to handle > concurrent requests. If process A has sent a request and is waiting for a > response, and process B tries to send a request using the same connection > process, its request will get queued up and will be sent once process A's > request gets a reply. > > Keep in mind though that this queuing mechanism could cause suboptimal > performance if you have many processes competing for use of a single > connection: users of the connection may end up spending a lot of time > blocked, waiting for requests from other processes to finish. Depending on > the circumstances, you may find that it's better to open multiple > connections than to share a single connection among multiple processes. > > Nick > > On Wed, May 25, 2016 at 6:28 AM, Richard Jonas < > richard.jo...@erlang-solutions.com> wrote: > >> Guys, >> >> most of the examples I can see that riak erlang client processes cannot >> be shared with multiple processes. Is it safe if more processes use the >> same riak connection? So in other words: is riak erlang client thread-safe? >> >> Thanks >> >> -- >> Richard Jonas >> Erlang Solutions Hungary Kft >> >> Address: >> Riverpark Office K.32 >> Közraktár street 32. 3/1. >> 1093 Budapest >> Hungary >> Phone/fax: >> +36-1-7000-654 >> >> ___ >> riak-users mailing list >> riak-users@lists.basho.com >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> >> > -- Richard Jonas Erlang Solutions Hungary Kft Address: Riverpark Office K.32 Közraktár street 32. 3/1. 1093 Budapest Hungary Phone/fax: +36-1-7000-654 ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
