Using the lasp-erlang-client? about lasp HOT 18 CLOSED

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.

from lasp.

I see, the partisan_peer_service_server is lacking a check for a valid lasp_pb message.

from lasp.

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)?

from lasp.

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.)

from lasp.

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.

from lasp.

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.

from lasp.

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.

from lasp.

If you're getting a partisan message, you're probably connecting to the wrong port.

from lasp.

The partisan port is under the partisan_config:get(listen_addrs) command you can issue in the remote shell, if you connect.

cc: @goncalotomas

from lasp.

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 lasp.

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.

from lasp.

So is the web_port the intended port to be doing this communication over?

from lasp.

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.

from lasp.

Ahh, so if the pb integration isn't finished whats the best way to communicate with the lasp server?

from lasp.

Just connecting a node directly at this point?

from lasp.

Right now, we're assuming nodes are running an instance of Lasp (or, communicate via RPC.)

from lasp.

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.

from lasp.

That would be killer! Let me know if there is anything I can do to help.

from lasp.