I have some problems with HTTP API:

When i send this:

(It is for my domotic system)

I receive this:

{"msgId":1501790559340,"name":"WebGui","sender":"WebGui","sendingMethod":"","historyList":[],"method":"onStatus","data":[{"level":"error","key":"IOException - invalid api","detail":" invalid api\r\n\tat org.myrobotlab.service.WebGui.handle(\r\n\tat org.atmosphere.nettosphere.Config$Builder$1.onRequest(\r\n\tat org.atmosphere.cpr.AsynchronousProcessor.action(\r\n\tat org.atmosphere.cpr.AsynchronousProcessor.suspended(\r\n\tat org.atmosphere.nettosphere.BridgeRuntime$2.suspended(\r\n\tat org.atmosphere.container.NettyCometSupport.service(\r\n\tat org.atmosphere.cpr.AtmosphereFramework.doCometSupport(\r\n\tat org.atmosphere.nettosphere.BridgeRuntime.handleHttp(\r\n\tat org.atmosphere.nettosphere.BridgeRuntime.messageReceived(\r\n\tat\r\n\tat\r\n\tat$DefaultChannelHandlerContext.sendUpstream(\r\n\tat\r\n\tat\r\n\tat$DefaultChannelHandlerContext.sendUpstream(\r\n\tat org.jboss.netty.handler.codec.http.HttpChunkAggregator.messageReceived(\r\n\tat\r\n\tat\r\n\tat$DefaultChannelHandlerContext.sendUpstream(\r\n\tat\r\n\tat org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(\r\n\tat org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(\r\n\tat org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(\r\n\tat\r\n\tat\r\n\tat\r\n\tat\r\n\tat\r\n\tat\r\n\tat\r\n\tat\r\n\tat\r\n\tat\r\n\tat\r\n\tat org.jboss.netty.util.internal.DeadLockProofWorker$\r\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(\r\n\tat java.util.concurrent.ThreadPoolExecutor$\r\n\tat\r\n"}]}

Before DL4J service, i receive this:

{"session":"default","msg":"","payloads":[{"serviceName":"python","methodName":"exec","params":["eveDomotic(1)"]}],"timestamp":"Aug 3, 2017 10:00:53 PM"}

and it works...

I don't know why ? Do you have an idea ?

Thank you.


AutonomicPerfectionist's picture

HTTP Issues

Hi Dom!

I've ran into similar issues before. MRL doesn't automatically expand the escape codes as far as I can tell from the source code (unless Atmosphere handles this internally, which doesn't seem to be the case). It also hates quotes, as I found out while trying to test ProgramAB! Looking at the stacktrace, it looks like there are extra characters in the /api/ bit, which would cause it freak out because technicaly it's not the same as just /api/, even though those characters are invisble. Strangely though, the /t is a tab and should show up quite easily...

I switched over to HTTP method PUT instead of GET and formatted the arguments into a json body. Took awhile to figure out, but now I've created a very easy-to-use command-line script to do exactly what you want. It's in my mrlpy Python package, installable via pip (mrlpy), and the source code is on Github at (also includes usage examples and extra features such as service creation and compatibility mode for running scripts meant for MRL's Python service). Requires Python 2.7 and various libraries. Installing through pip will automatically install dependencies. Supports both asynchronous (no return values) and synchronous (with return values) API modes. 

Mrlpy is still under development, so it might not work for everything, but hopefully it will work for you!


The extra characters in /api/ worries me though, so I'll have to run some tests to see if something broke on MRL-side

AutonomicPerfectionist's picture

My mistake, those characters

My mistake, those characters are part of the stacktrace ending character sequence, not part of the actual error. I would try removing the trailing s on services, but I'm pretty sure it doesn't matter (new check in webgui should have fixed that). If that doesn't work, then it's likely the escape characters. GET method has limitations in MRL http API, and escape codes was one of them, along with no quotes, special URL charactes, or spaces.

Hope this helps!

kwatters's picture

CLI works, http API is no worky

So, intresting, I was able to reproduce this error pretty easily..  using the CLI on the agent,  I was able to get the response, but another interesting error cropped up when I did that which is 


16:41:55.170 [cli-decoder-cli] ERROR c.myrobotlab.codec.ApiService - could not serialize return from public org.myrobotlab.service.ProgramAB$Response org.myrobotlab.service.ProgramAB.getResponse(java.lang.String) class class org.myrobotlab.service.ProgramAB$Response
..  So, this seems to say that there's some reason that the Response is not able to be converted into a JSON string to be returned.   You mention this is related / started happening when I added DL4j...  so my initial guess is that something in the classpath has conflicted with the json serialization in the webgui / atomosphere.. as a result it's blowing up.  I'm not sure, but this is just my initial guess.  
I also know that there's been a bit of refactoring there, so it might be completely unrelated to the dl4j stuff.
dom14's picture

Thank you KWatters.    

Thank you KWatters.



GroG's picture

I think this would be pretty

I think this would be pretty easy and quick to figure out if a noWorky was submitted.

AutonomicPerfectionist's picture


Okay, I looked into it and the WebGui has been refactored again. It looks like the alias for services API has been dropped, so just change the "services" in the URL to "service". However, that might not fix your problem. The WebGui has been refactored to send the data to an ApiFactory, which doesn't seem to be receiving the necessary data. For example: Any data in the JSON header is ignored and passed in as null. I don't know Atmosphere very well, so I couldn't really tell you why this is happening, only that it's likely related to the last refactor.

Hope this helps!

dom14's picture

OK, it works when i change

OK, it works when i change "services" to "service" but answer is NULL, it's not a problem for me.

Thank you  AutonomicPerfec..


GroG's picture

AutonomicPerfectionist is

AutonomicPerfectionist is completely correct ..  
There has been a large refactoring of the WebGui,  it's a "very good thing".  Previously, decoding was done differently in different services.  (Cli, WebGui, Xmpp, Mqtt & RemoteAdapter).  The refactoring is a first attempt to get them all to start using the same mechanism to decode & encode messages, making the MRL API more "standardized"

In the process, "services" was dropped.  There currently only 2 apis which use JSON.  They are "message" & "service

services - is no longer supported.