Using the lasp-erlang-client?
mpope9 opened this issue · 18 comments
I am trying to use the lasp-erlang-client, and it looks like the partisan_peer_service_server is expecting a generic erlang term, not a message encoded by lasp_pb. Its just calling term_to_binary instead of lasp_pb:decode_msg/2 Is there a configuration that I am missing to get these two things to talk to each other, or is this yet to be implemented?
What I am seeing after trying to use the client. Basically sending a query(?) over a TCP connection that includes the key and the key type:
11:10:38.450 [error] gen_server <0.682.0> terminated with reason: bad argument in call to erlang:binary_to_term(<<10,20,10,5,111,114,115,101,116,18,11,115,116,97,116,101,95,111,114,115,101,116>>) in partisan_peer_service_server:decode/1 line 142
11:10:38.451 [error] CRASH REPORT Process <0.682.0> with 0 neighbours crashed with reason: bad argument in call to erlang:binary_to_term(<<10,20,10,5,111,114,115,101,116,18,11,115,116,97,116,101,95,111,114,115,101,116>>) in partisan_peer_service_server:decode/1 line 142
11:10:38.457 [error] Supervisor partisan_pool had child {partisan_peer_service_server,{{127,0,0,1},53011},
{{127,0,0,1},53008},
#Ref<0.2197086231.2935226369.252456>} started with {partisan_peer_service_server,acceptor_init,undefined} at <0.682.0> exit with reason bad argument in call to erlang:binary_to_term(<<10,20,10,5,111,114,115,101,116,18,11,115,116,97,116,101,95,111,114,115,101,116>>) in partisan_peer_service_server:decode/1 line 142 in context child_terminated
Where <<10,20,10,5,111,114,115,101,116,18,11,115,116,97,116,101,95,111,114,115,101,116>> can be successfully decoded by lasp_pb.
I see, the partisan_peer_service_server is lacking a check for a valid lasp_pb message.
Would adding something like
try
lasp_pb:decode_msg(Message, req)
catch
_:_ -> term_to_binary(Message).Be an acceptable change to partisan (with the other required changes if needed)?
I'm confused. Partisan is more general purpose than Lasp, so it should not contain any Lasp related code. (in fact, I'm not sure why any of the Lasp protocol buffer code should be going through Partisan itself.)
Yeah that's what I was afraid of. Are the messages encoded by the protocol buffer incompatible with partisan now? I don't really see any kind of optional decode module.
I guess my question here is why are those messages going through Partisan? Partisan is for internode communication only -- I don't see a reason the client should be using it at all.
Maybe I'm communicating with the wrong port then?
lsof -Pan -p <lasp_pid> -i
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
beam.smp 13476 mpope 33u IPv4 0xab667c288b61d1d5 0t0 TCP *:56397 (LISTEN)
beam.smp 13476 mpope 34u IPv4 0xab667c289dc6edf5 0t0 TCP 127.0.0.1:56398->127.0.0.1:4369 (ESTABLISHED)
beam.smp 13476 mpope 40u IPv4 0xab667c28933e0c05 0t0 TCP 127.0.0.1:56399 (LISTEN)
Is how I am finding it, and the bottom port was the only one that I could connect to.
If you're getting a partisan message, you're probably connecting to the wrong port.
The partisan port is under the partisan_config:get(listen_addrs) command you can issue in the remote shell, if you connect.
cc: @goncalotomas
Yeah, that was totally the Partisan port, my mistake. What port would be the one that I would connect to then? The web_port 8080 does not seem to work.
{:ok, socket} = :laspc_pb_socket.start_link({127,0,0,1}, 8080)
** (MatchError) no match of right hand side value: {:error, :econnrefused}
Running lasp using
make shell
From a quick grep, it doesn't look like any of the protocol buffer client stuff was ever pulled into the mainline and I'm not sure why. I wasn't working on it, @goncalotomas was (as part of his Google Summer of Code project), so maybe he can point you to the branch where the work was done.
So is the web_port the intended port to be doing this communication over?
No, the web_port is used for the web interface that Lasp exports for debugging the overlay. You're looking for pb_port, which isn't in the main branch.
Ahh, so if the pb integration isn't finished whats the best way to communicate with the lasp server?
Just connecting a node directly at this point?
Right now, we're assuming nodes are running an instance of Lasp (or, communicate via RPC.)
Hey.
The Lasp Erlang client was designed to interact directly to Lasp nodes via protocol buffer messages, without any interference with/from Partisan. At the time, I was working on defining the messages and Vitor was helping me make sure that popular Lasp operations could be encoded.
The changes to the client were easy since we were working on a separate repository, but at the same time types was undergoing some significant changes if I recall correctly. My work depended on the newer versions of types, but Lasp lagged behind for a while after GSoC ended and that is why these changes never made it in.
I don't recall the full status of the server side, but I can take a look at it later and see if there is an easy way to merge the missing work back into mainline. I was basically adding another process to the Lasp supervisor, a gen_server, which was decoding the operations and calling the appropriate functions.
That would be killer! Let me know if there is anything I can do to help.