问题
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
回答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.
来源：https://stackoverflow.com/questions/34343357/connectivity-problems-between-filab-vms-and-cosmos-global-instance