appulse-projects / encon-java

Java based Erlang Node Connector. https://appulse.io

Overview

Java implementation of Erlang Node CONnector (using Eralng Distribution Protocol). For more information, visit the site.

Sub-modules descriptions:

• Encon common - the set of common classes for all subprojects;
• Encon terms - Erlang's terms classes and different helpers;
• Encon config - configuration builder classes;
• Encon - the lib itself;
• Encon databind - serializers/deserializers from/to Java/Eralng objects;
• Encon handler - helpers for handling received messages in mailbox;
• Encon Spring - Spring Boot integration;
• Encon examples - different encon's examples;
• Encon benchmark - encon's benchmarks;

Development

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes.

Prerequisites

For building the project you need only a Java compiler.

IMPORTANT: the project requires Java version starting from 8

And, of course, you need to clone the project from GitHub:

$> git clone https://github.com/appulse-projects/encon-java
$> cd encon-java

Building

For building routine automation, I am using maven.

To build the project, do the following:

$> mvn clean compile
...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] encon 1.6.10 ........................................ SUCCESS [  1.210 s]
[INFO] encon-common ....................................... SUCCESS [ 25.693 s]
[INFO] encon-terms ........................................ SUCCESS [ 27.517 s]
[INFO] encon-config ....................................... SUCCESS [ 18.707 s]
[INFO] encon-databind ..................................... SUCCESS [ 22.462 s]
[INFO] encon .............................................. SUCCESS [ 36.247 s]
[INFO] encon-handler ...................................... SUCCESS [ 17.436 s]
[INFO] encon-spring ....................................... SUCCESS [ 11.516 s]
[INFO] examples ........................................... SUCCESS [  0.024 s]
[INFO] simple ............................................. SUCCESS [  5.337 s]
[INFO] echo-server ........................................ SUCCESS [  5.840 s]
[INFO] echo-server-spring ................................. SUCCESS [  7.716 s]
[INFO] custom-queue ....................................... SUCCESS [  3.920 s]
[INFO] databind ........................................... SUCCESS [  5.045 s]
[INFO] handler-basic ...................................... SUCCESS [  6.443 s]
[INFO] handler-advanced ................................... SUCCESS [ 11.289 s]
[INFO] load-config ........................................ SUCCESS [  3.725 s]
[INFO] load-config-spring ................................. SUCCESS [  6.420 s]
[INFO] benchmark 1.6.10 .................................... SUCCESS [  5.594 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:15 min
[INFO] Finished at: 2020-08-20T18:36:04+03:00
[INFO] ------------------------------------------------------------------------

Running the tests

To run the project's test, do the following:

$> mvn clean test
...
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
...
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 67, Failures: 0, Errors: 0, Skipped: 0
[INFO]
...

Also, if you do package or install goals, the tests launch automatically.

Built With

• Java - is a systems and applications programming language

• Lombok - is a java library that spicing up your java

• Junit - is a simple framework to write repeatable tests

• AssertJ - AssertJ provides a rich set of assertions, truly helpful error messages, improves test code readability

• Maven - is a software project management and comprehension tool

Changelog

To see what has changed in recent versions of the project, see the changelog file.

Contributing

Please read contributing file for details on my code of conduct, and the process for submitting pull requests to me.

Versioning

We use SemVer for versioning. For the versions available, see the tags on this repository.

Authors

• Artem Labazin - creator and the main developer

• Sokol Andrey - texts corrector and mastermind

License

This project is licensed under the Apache License 2.0 License - see the license file for details

encon-java's Issues

Encode/Decode error for nonode@nohost PIDs

It seems encon doesn't survive while decoding->encoding+serializing PIDs in format of #PID<0.639.0>

Exception:

io.appulse.encon.terms.exception.IllegalErlangTermTypeException: Class io.appulse.encon.ter
ms.type.ErlangAtom doesn't fit to term type ATOM

Steps to reproduce:

1. In Elixir: File.write!("pid.term", :erlang.term_to_binary(self))
2. On Java side:
   Read the first byte of "pid.term" file (it's 131)
3. Read the rest into ByteBuf
4. Decode bytebuf into proper java class with ErlangTerm/newInstance
5. Encode/serialize it to another ByteBuf. Get the error above.

I suspect that the atom for node name of such PID constructs with incorrect value field:

#object[io.appulse.encon.terms.type.ErlangAtom 0x1c433450 "ErlangAtom(value=nu
ll, bytes=[110, 111, 110, 111, 100, 101, 64, 110, 111, 104, 111, 115, 116], ch
arset=ISO-8859-1)"]

ErlangString proposal

When value.length() > 65535 || !is8bitString() consider to encode such string in ErlangBinary (BINARY_EXT) rather than in list. It's way more easier to handle binaries on a erlang/elixir side. Especially when such string is somewhere inside a nested data structure.
Thanks!

ErlangPid lombok-generated hash code is inconsistent wrt PID types

Since there is an @EqualsAndHashCode(callSuper = true) annotation on ErlangPid, type field is considered for hashcode & equals, which means otherwise identical but different in PID/NEW_PID ErlangPids would be considered different, which means we don't get replies.
I bumped into this by simply launching elixir (iex --sname foo) and then doing ping from JVM.
After building locally with hashcode() defined as

@Override
  public int hashCode() {
    return Objects.hash(descriptor, id, serial, creation);
  }

message exchange works. I can submit a PR if this is the right solution or I would be happy to hear your thoughts on this in general.

:up: netty version

Hey.
Is it possible to bump up netty version to the latest one (4.1.34.Final as for now)?

ErlangPid.cached weak hash funciton

Starting from some point, the encon library decodes PID's incorrectly and returns previously cached PID instead of creating the new one:

"ENCON GOT: [\"#PID<0.671.0>\"]
while
JInterface got: #Pid<[email protected]>

896 is the right id of a PID that was sent from Elixir side.

Could you also ditch the caching function while creating atom return (T) ErlangAtom.cached(type, buffer) in ErlangTerm newInstance function? Just in case.

GPG key error

It seems there is an error with a downloading and installing the Encon's jar from Maven Central without GPG key.

Weak hashing function for ErlangInteger::cached

The function ErlangInteger::cached is used inside string serialization mechanism. But it's internal hashing mechanism is too weak. For instance hash for ErlangInteger::cached(1273) and ErlangInteger::cached(117) in both cases is equal to 923638.

As a result the resulting string which has both symbols with code 1273 and 117 when in LIST mode becomes corrupted.

Please fix it or rather change string serialization to use non-cached constructor of ErlangInteger