Parameters weren't properly deserialized in MTG (tenants.gateway LATEST 3.4.1-SNAPSHOT)

[uzi0espil]

I have encountered the following issue, when client tries to connect to the server using MTG in both the client and server logs:

Exception in thread "pool-25-thread-1" java.lang.RuntimeException: Parameters weren't properly deserialized
        at org.universAAL.ri.gateway.protocol.ImportMessage.getParameters(ImportMessage.java:129)
        at org.universAAL.ri.gateway.Importer$ImportRequestTask.run(Importer.java:114)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)

I am running both universAAL spaces locally. The server has the following properties:

remote-gateway-host=localhost
socket-port=8888
security-definition-file=none
hash-key=1ccc9120c4aac043c8a8d96a5cb9509b
connection-mode=server

While the client has the following properties:

remote-gateway-host=127.0.0.1
socket-port=8888
security-definition-file=none
hash-key=1ccc9120c4aac043c8a8d96a5cb9509b
connection-mode=client

I have also added The AcceptALL.ttl as explained in the documentation which accepts all ContextEvents.
but same issue. When I try to publish a context event from server to the client, the event fails due to permission deny.

Hope someone can help me see what is the problem.

[amedranogil]

are you running server and client in different instances of universAAL?
If so, have you prepared both instances so they do not connect through the MW networking feature (i.e: if you run universaal:peers do you se one or 2 peers)?
You may be creating a loop; and this is the way the MTGW has to tell you about it.

[uzi0espil]

@amedranogil I can see 2 peers.. The weird thing is that each space finds the other even with the mentioned error. I can even verify it using tools.log bundle

karaf@uAAL>universAAL:peers
 Found: 2 Peers
 ----------------------------------------
Peer ID: 013b0e90-15bf-4410-8bb0-27d3376d9b18 - Peer Role: COORDINATOR
 * Peer ID: 90bd39e7-4959-4459-882e-6cd21ee31762 - Peer Role: COORDINATOR

[amedranogil]

this is precisely your problem, the MTGW is used to connect UNCONNECTED spaces. if your spaces are already connected you will cause message loops: SpaceA.event -> MTGW.A -> SpaceB.Event -> MTGW.B -> SpaceA.event ....

To test MTGW in local you need to properly prepare both instances so they don't connect (they only connect through the MTGW connection). @kismet long ago prepared this testing environment for me, But I do not have clear exactly what kind of magict it is. There should be a section in the wiki pages explaining how to do this. In MW there is a section on disabling the discovery and peering, but you'll probably need to change some ports too so they don't connect through the localhost interface.

[uzi0espil]

Ah I see now... Actually I have prepared the properties as suggested by the doc where it says:

* If you want to test a GW server and a client in the same machine, you should set the server host as "localhost" and the client as the loopback address "127.0.0.1" or else it may not work.

I will try to set up both instances in different device and let you know how this works.

[Alfiva]

This is not related, as far as I know. To make sure both instances do not see each other, you should change the SLP port to be different in each. In /etc/system.properties put the property net.slp.port=5555 (to different values in each). I think it should be enough.

[Alfiva]

I see that in the latest versions of distributions, the system.properties file says this:

##uncomment to disable universAAL networking
#net.slp.interfaces=127.0.0.1
#jgroups.bind_addr=127.0.0.1

So maybe uncommenting that helps. In any case, in my experience, changing the slp port as I said before usually does the job.

[saiedt]

Thanks Alvaro. According to Ousama, it seems that all the three parameters are essential for solving this problem. I have updated the document to include this hint.

[uzi0espil]

@Alfiva Thanks what you have provided helped me to make them both undiscovered by SLP.. but the problem is still there.. when I try to connect them through MTG I still receive the following at both server and client:

unException in thread "pool-36-thread-1" java.lang.RuntimeException: Parameters weren't properly deserialized
        at org.universAAL.ri.gateway.protocol.ImportMessage.getParameters(ImportMessage.java:129)
        at org.universAAL.ri.gateway.Importer$ImportRequestTask.run(Importer.java:114)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)

[uzi0espil]

Still couldnt make it work.. is there any hints or updates on this issue?

[Alfiva]

I am not familiar with the importer, maybe @amedranogil can help

[cstockloew]

Ousama gave me the serialized parameters and I tried to deserialize them. It works just fine with 3.4.1-S.

So, I tried to recreate the scenario (but with Pax and 3.4.2-S). This was not so easy because the GW is karaf-dependent (because of the shell command).
Some Info:

I separated the spaces as mentioned here:
https://github.com/universAAL/platform/wiki/Configuration-Parameters#isolating-multiple-universaal-instances

Client:

remote-gateway-host=localhost
socket-port=8181
security-definition-file=none
cipher.class=org.universAAL.ri.gateway.communication.cipher.LegacyBlowfishCipher
server-threads=1
hash-key=1ccc9120c4aac043c8a8d96a5cb9509b
connection-mode=server

Server:

remote-gateway-host=127.0.0.1
socket-port=8181
security-definition-file=none
cipher.class=org.universAAL.ri.gateway.communication.cipher.LegacyBlowfishCipher
server-threads=1
timeout=5000
cache-max-size=-1
hash-key=1ccc9120c4aac043c8a8d96a5cb9509b
connection-mode=client

I had to provide ALL info. If I miss one of the infos (like cache-max-size), I get an Exception in ConfigurationFile, e.g. for Long.parseLong(getProperty(QUEUES));. This happens although the doc mentions that there would be a default value.

The method ConfigurationFile.getCipher() calls Class.forName(CHIPER_CLASS); but it probably should be Class.forName(getProperty(CHIPER_CLASS));.

Then I got an Exception in constructor of class Session: it first starts the Thread messagequeuetask and then creates the variable messagequeue, but the thread accesses this variable -> race condition that can easily be solved by changing the order.

When I finally had everything running without Exception, the server prints:
Got new incoming connection
and the client prints:
FIRST loading trying to create a SESSION
but nothing happens. I also tried the ClearTextCipher and found that the client successfully sends a ConnectionRequest and then tries to read the Serializable(!) Message in ClearTextCipher.readMessage(): (Message) is.readObject(); That's when it stops.

Any ideas?

[cstockloew]

Update: it stopped at the end because I did not have the tenant manager. It is now added to mw.composite.

However, it still does not work:

• The ProxyContextSubscriber tries to send a message, but when ClearTextCipher.sendMessage is called, the output stream is null (not sure how this can happen).
• In MessageQueueTask.run there is a line Message m = messagequeue.peek(); : sometimes the message is null and this null object is transferred which causes an exception on the other end. There should be a check for null.

But I still could not recreate the error Ousama had ;-)

[amedranogil]

Hello,
sorry for the VERY late reply, I have been swamped.
I will get on it today.

[amedranogil]

Version 3.4.2-SNAPSHOT was work in progress, I stopped short of testing it out. So 👍 to Carsten for ironing out many of the stupid bugs.

[amedranogil]

I suspect the problem might be related to the ontologies; I had this kind of problems long before the MTGW, when the ontologies where not define correctly, they worked locally but could not serialize/deserialize correctly, so when working in multi node environment there where problems. Particularly look into the Class, properties, and instances' URIs and check only Class URIs have upercase after the #; the rest should be lowercase

[ShahzadAmeen]

Is the issue presented by Ousama ironed out both in 3.4.1 and 3.4.2 karaf distribution ???

[amedranogil]

Work on the MTGW is expected to start on September. Our intention is to solve many, if not all, of the open issues regarding MTGW. Unfortunately this work will focus on 3.4.2-SNAPSHOT as it is our development version, and MTGW has already had some fixes done in this version.