Connectivity problems between FILAB VMs and Cosmos global instance - fiware

Question

I have the same kind of connectivity problem discussed in the question "Cygnus can not persist data on Cosmos global instance". However, I have found no solution after read it.
Nowadays, I have recently deployed two virtual machines in FILAB (both VMs contain Orion ContextBroker 0.26.1 and Cygnus 0.11.0).
When I try to persist data on Cosmos via Cygnus, I get the following error message (the same in both VMs) :
2015-12-17 19:03:00,221 (SinkRunner-PollingRunner-DefaultSinkProcessor)
[ERROR - com.telefonica.iot.cygnus.sinks.OrionSink.process(OrionSink.java:305)]
Persistence error (The /user/rmartinezcarreras/def_serv/def_serv_path/room1_room
directory could not be created in HDFS. Server response: 503 Service unavailable)
On the other hand, when I try to fire a request from the command line of whatever VM, I get the next response:
[root#orionlarge centos]# curl -v -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/rmartinezcarreras/?
op=liststatus&user.name=rmartinezcarreras" -H "X-Auth-Token: XXXXXXX"
* About to connect() to cosmos.lab.fiware.org port 14000 (#0)
* Trying 130.206.80.46... connected
* Connected to cosmos.lab.fiware.org (130.206.80.46) port 14000 (#0)
> GET /webhdfs/v1/user/rmartinezcarreras/?
op=liststatus&user.name=rmartinezcarreras HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: cosmos.lab.fiware.org:14000
> Accept: */*
> X-Auth-Token: XXXXX
>
* Closing connection #0
* Failure when receiving data from the peer
curl: (56) Failure when receiving data from the peer
Nevertheless, from an external VM (outside FILAB):
[root#dsieBroker orion]# curl -v -X GET
"http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/rmartinezcarreras/?
op=liststatus&user.name=rmartinezcarreras" -H "X-Auth-Token: XXXXX"
* About to connect() to cosmos.lab.fiware.org port 14000 (#0)
* Trying 130.206.80.46... connected
* Connected to cosmos.lab.fiware.org (130.206.80.46) port 14000 (#0)
> GET /webhdfs/v1/user/rmartinezcarreras/?
op=liststatus&user.name=rmartinezcarreras HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: cosmos.lab.fiware.org:14000
> Accept: */*
> X-Auth-Token: XXXXXX
>
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: HEAD, POST, GET, OPTIONS, DELETE
< Access-Control-Allow-Headers: origin, content-type, X-Auth-Token, Tenant-
ID, Authorization
< server: Apache-Coyote/1.1
< set-cookie:
hadoop.auth="u=rmartinezcarreras&p=rmartinezcarreras&t=simple&e=XXXXXX&s=
XXXXhD 8="; Version=1; Path=/
< Content-Type: application/json; charset=utf-8
< transfer-encoding: chunked
< date: Thu, 17 Dec 2015 18:52:46 GMT
< connection: close
< Content-Length: 243
< ETag: W/"f3-NL9+bYJLweyFpoJfNgjQrg"
<
{"FileStatuses":{"FileStatus":
[{"pathSuffix":"def_serv","type":"DIRECTORY","length":0,"owner":
"rmartinezcarreras","group":"rmartinezcarreras","permission":"740",
"accessTime":0,"modificationTime":1450349251833,"blockSize":0,
"replication":0}]}}
* Closing connection #0
Also get good results from my Cosmos account.
How can I solve this? It seems a connectivity problem. Could you help me?
Thank you in advance

Answer 1

Finally, this was a problem with the OAuth2 proxy we are using for Authentication and Authorization. The underlying Express module it is based was adding a content-length header when another transfer-encoding: chunked header was present. As researched in this other question, this combination is not according to the RFC, and was causing certain fully compliant client implementations were reseting the connection.