I want to run a programme that loads a data into riak database, but the process is stopping suddenly when i gave range about 10. if i gave 5-8 it is taking and loading the data, when i give range more than 10 it was hanging up. what was happening.
test(X,Y) ->
if X < Y ->
{ok,Pid} = riakc_pb_socket:start_link("127.0.0.1",10017),
Val = X,
io:format("~p",[Pid]),
Object = riakc_obj:new(<<"test_age">>,undefined,Val),
riakc_pb_socket:put(Pid,Object),
test(X+1,Y);
true -> []
end.
The function will take a range of numbers and just insert into the riak database with adding the numbers to the old number.
when i run this programme from the erlang shell it is stopping after taking the range about 10:
erlriak:test(1,5)
<0.50.0><0.51.0><0.52.0><0.53.0><0.54.0>[]
erlriak:test(5,15)
<0.62.0><0.63.0><0.64.0><0.65.0><0.66.0><0.67.0><0.68.0><0.69.0><0.70.0>|
It was hanging after the <0.70.0> for minutes and nothing is returning.I am getting the following:
=ERROR REPORT==== 19-May-2014::17:29:54 ===
** Generic server <0.104.0> terminating
** Last message in was {req_timeout,#Ref<0.0.0.423>}
** When Server state == {state,"127.0.0.1",10017,false,false,undefined,false,
gen_tcp,undefined,
{[],[]},
1,[],infinity,undefined,undefined,undefined,
undefined,[],100}
** Reason for termination ==
** disconnected
** exception exit: disconnected
I suspect you are exceeding the limit for simultaneous connections to Riak's PB port. Possible solutions:
call riakc_pb_socket:stop(Pid) to close the connection before recursing
move the call to start_link outside the test function so all requests share the same socket
increase pb_backlog in your app.config so you can have more simultaneous connections
Related
I access the Break Menu of eix 1.8.2 by pressing CTRL + C. It looks like this:
BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded
(v)ersion (k)ill (D)b-tables (d)istribution
At first I assumed kill would be similar to abort (ie, just ends the session), but no. Instead, pressing k produces a core dump and offers more options:
iex(1)>
BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded
(v)ersion (k)ill (D)b-tables (d)istribution
k
Process Information
--------------------------------------------------
=proc:<0.105.0>
State: Waiting
Spawned as: erlang:apply/2
Spawned by: <0.75.0>
Message queue length: 0
Number of heap fragments: 1
Heap fragment data: 5
Link list: [{to,<0.64.0>,#Ref<0.720592203.270008322.27074>}]
Reductions: 4202
Stack+heap: 233
OldHeap: 0
Heap unused: 177
OldHeap unused: 0
BinVHeap: 1
OldBinVHeap: 0
BinVHeap unused: 46421
OldBinVHeap unused: 46422
Memory: 2804
Stack dump:
Program counter: 0x000000001f8230e0 (io:execute_request/2 + 200)
CP: 0x0000000000000000 (invalid)
arity = 0
0x000000001ddcee08 Return addr 0x000000001f8a4ba0 ('Elixir.IEx.Server':io_get/3 + 96)
y(0) #Ref<0.720592203.270008322.27074>
y(1) {false,{get_line,unicode,<<"iex(1)> ">>}}
y(2) <0.64.0>
0x000000001ddcee28 Return addr 0x000000001d53ecf8 (<terminate process normally>)
y(0) <0.105.0>
y(1) <0.75.0>
Internal State: ACT_PRIO_NORMAL | USR_PRIO_NORMAL | PRQ_PRIO_NORMAL
(k)ill (n)ext (r)eturn:
If I press k again, I get another core dump. Pressing n also gives me a core dump and I think it's the same as pressing k. The final option, r, does different things depending on what I've done previously. If I've only pressed k or n a few times, it just ignores it and I have to press enter twice. iex interprets the second enter as it normally would and returns nil.
(k)ill (n)ext (r)eturn:
r
nil
If I've pressed k and n a bunch of times, it either does this:
(k)ill (n)ext (r)eturn:
r
** (EXIT from #PID<0.104.0>) shell process exited with reason: killed
Interactive Elixir (1.8.2) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)>
09:39:57.929 [info] Application iex exited: killed
or this:
(k)ill (n)ext (r)eturn:
r
09:46:20.268 [info] Application iex exited: killed
09:46:20.269 [info] Application elixir exited: killed
09:46:20.274 [error] GenServer IEx.Pry terminating
** (stop) killed
Last message: {:EXIT, #PID<0.88.0>, :killed}
State: 1
or this:
(k)ill (n)ext (r)eturn:
r
Logger - error: {removed_failing_handler,'Elixir.Logger'}
Logger - error: {removed_failing_handler,'Elixir.Logger'}
Logger - error: {removed_failing_handler,'Elixir.Logger'}
I am unsure how it decides which of those messages should be displayed.
I'm really curious what (k)ill and it's suboptions do and look forward to learning about it. Any direction is appreciated, thanks!
Looking at the source code:
case 'k':
process_killer();
and
switch(j) {
case 'k':
ASSERT(erts_init_process_id != ERTS_INVALID_PID);
/* Send a 'kill' exit signal from init process */
erts_proc_sig_send_exit(NULL, erts_init_process_id,
rp->common.id, am_kill, NIL,
0);
case 'n': br = 1; break;
case 'r': return;
default: return;
}
k seems to be for enumerating and killing individual processes by sending them a kill signal. The different output is because it depends how each processes handles the signal.
The kill command goes through all running processes, and for each of them displays a bunch of information and asks you whether to:
kill it and go to the next process (k)
go to the next process without killing this one (n), or
stop killing processes and go back to the shell (r).
It might be tricky to identify the process you want to kill. One thing you can look at is the Dictionary line, which for most long-running processes has an $initial_call entry telling you which module contains the code that this process is running. For example:
Dictionary: [{'$ancestors',[<0.70.0>]},{iex_evaluator,ack},{'$initial_call',{'Elixir.IEx.Evaluator',init,4}}]
The different messages are displayed depending on which process(es) you killed. For example, it seems like Elixir.IEx.Evaluator is the process running the Elixir shell, which gives you the shell process exited with reason: killed error message.
A way of looking at this is that it shows the fault tolerance of an Elixir application: even if a process somewhere within the system has an error (in this case caused by explicitly killing the process), the supervisors try to restart the process in question and keep the entire system running.
Actually, I've never used this way of killing processes in a running system. If you know the process id ("pid") of the process you want to kill, you can type something like this into the shell:
Process.exit(pid("0.10.0"), :kill)
without having to step through the list of processes.
I had ejabberd 13.12, all works great until I physically moved server machine to another network, then jabber server start encounting crashes. (the same types and details of networks)
CRASH REPORT Process <0.4260.0> with 0 neighbours exited with reason: call to undefined function
ejabberd_socket:get_conn_type({socket_state,gen_tcp,#Port<0.5852>,<0.4259.0>}) in p1_fsm:terminate/7 line 733
2014-01-23 09:34:42.548 [error] <0.330.0> Supervisor ejabberd_c2s_sup had child undefined started with
{ejabberd_c2s,start_link,undefined} at <0.4260.0> exit with reason call to undefined function
ejabberd_socket:get_conn_type({socket_state,gen_tcp,#Port<0.5852>,<0.4259.0>}) in context child_terminated
after machine migration the statuses of users was changed randomly.
I tried reinstall jabber server and I used ejabberd 2.1.13 compiled from scratch - what give me the same errors while using jabber.
function is:
get_conn_type(StateData) ->
case (StateData#state.sockmod):get_sockmod(StateData#state.socket) of
gen_tcp -> c2s;
p1_tls -> c2s_tls;
ezlib ->
case ezlib:get_sockmod((StateData#state.socket)#socket_state.socket) of
gen_tcp -> c2s_compressed;
p1_tls -> c2s_compressed_tls
end;
ejabberd_http_poll -> http_poll;
ejabberd_http_bind -> http_bind;
_ -> unknown
end.
I want understand this function (good pythoner, never erlang) and add hack or pinpoint the issue: is sth ejabberd specific or sth with sockets (but others network tools/services works perfect).
a) how can I insert to that function interactive debugger and get interactive introspection of stack and variables there.
The error message you're seeing says that the get_conn_type function doesn't exist in the ejabberd_socket module. And this is true; in the standard ejabberd distribution, get_conn_type lives in the ejabberd_c2s module.
If you are positive that neither you nor anyone else has modified the sources, then I would check your installation of Erlang. Perhaps it's broken, or you're using different versions to compile and run the code.
This is an interesting situation, focused on the behavior of erlang ssh modules. I had spent a few hours troubleshooting a problem that turned out to reveal that the Erlang ssh_connection *exec/4* function operates asynchronously.
If you issue the ssh_connection:exec/4 function to run a script that takes several seconds to complete, and then in your erlang program you close the ssh connection, the script execution will terminate. My expectation was that the ssh_connection:exec would be synchronous rather than asynchronous.
Because the time to complete the remote script invoked by ssh_connection:exec is unknown, I chose to not issue the closure ssh:close(). I would like to understand the consequences of that:
Will the gc clear it at some point ?
Will it stay open for good during the whole node existence ?
Is there a way to make the ssh_connection:exec synchronous, as I would believe it should be.
Here is an example of the test erl program that I used to verify this issue. As a script you can run a simple sleep 10 (sleep 10 seconds) to emulate a slow running program.
-module(testssh).
-export([test/5]).
test (ServerName, Port, Command, User, Password) ->
crypto:start(),
ssh:start(),
{ok, SshConnectionRef} = ssh:connect(ServerName, Port, [ {user, User}, {password, Password} , {silently_accept_hosts, true} ], 60000 ),
{ok, SshConnectionChannelRef} = ssh_connection:session_channel(SshConnectionRef, 60000),
Status = ssh_connection:exec(SshConnectionRef, SshConnectionChannelRef, Command, 60000),
ssh:close(SshConnectionRef).
Remote script:
#!/bin/sh
sleep 10
I never had to use the ssh application myself, but you should be reading something wrong, it is clear in the doc that the result will be delivered as messages to the caller:
[...] the result will be several messages according to the following pattern. Note that the last message will be a channel close message, as the exec request is a one time execution that closes the channel when it is done[...]
See http://www.erlang.org/doc/man/ssh_connection.html#exec-4
So after you call ssh_connection:exec/4 , test with a loop like this:
wait_for_response(ConnectionRef) ->
receive
{ssh_cm, ConnectionRef, Msg} ->
case Msg of
{closed, _ChannelId} ->
io:format("Done");
_ ->
io:format("Got: ~p", [Msg]),
wait_for_response(ConnectionRef)
end
end.
You should receive the command output, and other ssh messages, and finally a 'closed' message that is your signal that the ssh command has properly finished.
(Also available on Erlang's mailing list.)
Is it possible to write a function that waits for every process running on an Erlang node to reach a point where it is blocked, waiting for a message?
The function should return only when every process is waiting for a message that has not yet been sent to it. Assume that no process is in a time-related suspension (receive with an after clause, timer-related operations etc). The process running this function is, of course, excluded.
Obviously wrong answer:
erlang:yield/0: This gives a chance to every other process to run, but not necessarily until it is blocked.
Not 100% correct approach:
only_one_not_waiting() ->
Running =
[P || P <- processes(), process_info(P, status) =/= {status, waiting}],
length(Running) == 1
end.
everyone_blocked() ->
case only_one_not_waiting() of
true -> ok;
false -> everyone_blocked()
end.
Ignoring timers, running only_one_not_waiting/0 repeatedly until it returns true (as everyone_blocked/0 does) should indicate the desired system state, if this state is eventually reached.
However I am not sure how much trust one should put on the return value of process_info(P, status).
Im using a port to run a pipeline with uncompresses and dd's some data:
Port = open_port({spawn, "bzcat | sudo dd of=/dev/foo},
[stream, use_stdio, exit_status]),
What I would like to do is produce a end-of-file situation on the output which causes the pipeline to complete and eventually exit.
I would like to wait for this completion and also capture the exit_status.
When I just call port_close it looks to me as if the pipeline is just terminated and there is no wait for completion. Also I don't get any exit_status ....
How can I accomplish waiting for exit before my next step (which requires the dd to have completed).
Did some experiments and it looks like at least port_close doesn't kill the process, you just don't find out when its done. Is this correct?
If you just need to wait for spawned by open_port command to complete you need to wait for exit_status message:
1> Port = open_port({spawn, "sleep 7"}, [exit_status]).
#Port<0.497>
2> receive {Port, {exit_status, Code}} -> Code after 10000 -> timeout end.
0
Update (about to say a port just close the output pipe): I think you can't just close the output pipe with the default spawn driver. Default driver doesn't have any control commands and port_close although don't kill spawned command but completely erase all port's state.
Possible solutions:
Write input stream to a file first and then run bzip/dd sequence on that file;
Write your own driver or NIF (Maybe some open source implementations already exist?)
Use some external script and control protocol, for example full (or chunk) length can be transferred before the actual content so the script will know when to close the connection
Several rather ugly workarounds to this problem can be found here: limitations of erlang:open_port() and os:cmd()
Some even use netcat to map the problem to a tcp connection.