I have 3 marathon servers running in HA. when i reach the rest api on the leader, it returns good data. But when i try it against one of the non leader nodes, I do not get any data back...no strings at all. The headers say 200...but no data. Has anybody experienced this before?
here is what i see on the leader
# curl -i http://10.0.0.1:8080/v2/apps
HTTP/1.1 200 OK
X-Marathon-Leader: http://x1-master-0:8080
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Content-Type: application/json; qs=2
Connection: close
Server: Jetty(8.y.z-SNAPSHOT)
{"apps":[]}
here is the data from the non leader
# curl -i http://10.0.0.2:8080/v2/apps
HTTP/1.1 200 OK
Connection: close
Server: Jetty(8.y.z-SNAPSHOT)
the problem was that the marathon servers could not resolve each other by name. Adding the hostnames of the other marathon servers to each marathon's /etc/hosts file fixed the problem.
Related
I'm interacting with a server (that is out of my control) in which protocol upgrade is not performed by the server if a request contains content (POST, PUT, PATCH with payload). It's unclear exactly what the issue with the server is, but I noticed that when I query with --http2-prior-knowledge, the protocol is upgraded:
❯ curl -i -PUT --http2-prior-knowledge http://localhost:8081/document/v1/foo -d '{"fields": {"docid": "123"}}'
HTTP/2 200
date: Tue, 08 Nov 2022 13:26:50 GMT
content-type: application/json;charset=utf-8
vary: Accept-Encoding
content-length: 78
The same request without --http2-prior-knowledge is stuck at HTTP/1.1. This seems closer to the default behaviour of Go's HTTP client
❯ curl -i -PUT --http2 http://localhost:8081/document/v1/foo -d '{"fields": {"docid": "123"}}'
HTTP/1.1 200 OK
Date: Tue, 08 Nov 2022 01:37:17 GMT
Content-Type: application/json;charset=utf-8
Vary: Accept-Encoding
Content-Length: 78
When I call this same API using Go's default client, the protocol is not upgraded. I've tried setting ForceAttemptHTTP2: true on the transport, but each http.Response contains a .Proto of HTTP/1.1
I think what I need to understand is how I can mimic curl's prior-knowledge flag in Go. Is this possible?
I solved this issue by specifying a custom http2.Transport which skipped TLS dial. The ideal solution, in retrospect, is to use an SSL certificate (self-signed is sufficient) which would better guarantee the use of HTTP2. Leaving some links for posterity
c := &http.Client{
// Skip TLS Dial
Transport: &http2.Transport{
AllowHTTP: true,
DialTLS: func(netw, addr string, cfg *tls.Config) (net.Conn, error) {
return net.Dial(netw, addr)
},
},
}
And links:
Why do web browsers not support h2c (HTTP/2 without TLS)?
https://github.com/golang/go/issues/14141
I am using a consul client to deregister a service from my junit tests. I am using vert-consul-client . the consul version i am using is 1.11.1 . the service is not registered with the consul , but just testing what will happen if we try to deregister a service that is not registered.
from the logs i get this error
Status message: 'Not Found'. Body: 'Unknown service "BadService"'
strangely i dont get this error when testing with 1.10.6 consul version.
appreciate if you can help
thanks
strangely i dont get this error when testing with 1.10.6 consul version.
Consul recently changed the HTTP response code that is sent when an attempt is made to deregister a non-existent service.
Prior to Consul 1.11.0, and when ACLs were disabled, Consul would respond with a HTTP 200 response code and no response body when deregistering a non-existent service.
$ curl --include \
--request PUT http://localhost:8500/v1/agent/service/deregister/test
HTTP/1.1 200 OK
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: allow
Date: Wed, 05 Jan 2022 03:07:35 GMT
Content-Length: 0
This behavior was changed in Consul 1.11.0 by PR hashicorp/consul#10632 wherein Consul now returns a HTTP 404 response code if a service does not exist, regardless of whether ACLs are enabled. (See diff of consul/agent/acl.go).
$ curl --include \
--request PUT http://localhost:8500/v1/agent/service/deregister/test
HTTP/1.1 404 Not Found
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: allow
Date: Wed, 05 Jan 2022 03:24:21 GMT
Content-Length: 22
Content-Type: text/plain; charset=utf-8
Unknown service "test"
You're obviously not seeing an error in vertx-consul-client when communicating to Consul 1.10.6 because the HTTP 200 code indicates that the request was successful, whereas the HTTP 404 response correctly signals that the resource does not exist, and an error is correctly raised (see vert-consul-client/src/main/java/io/vertx/ext/consul/impl/ConsulClientImpl.java#L1320-L1333).
Interestingly in Consul 1.10.x, when ACLs are enabled on the cluster, Consul would reply with a HTTP 500 error code and a corresponding error message instead of the 200 response code. This is because when ACLs are enabled, the vetServiceUpdateWithAuthorizer function does not prematurely return (if authz == nil { return nil }) and proceeds with checking whether service exists, then raising an error because it does not (see consul/agent/acl.go#L96-L104).
$ curl --include \
--header "X-Consul-Token: $CONSUL_HTTP_TOKEN" \
--request PUT http://localhost:8500/v1/agent/service/deregister/test
HTTP/1.1 500 Internal Server Error
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: deny
Date: Wed, 05 Jan 2022 03:14:52 GMT
Content-Length: 22
Content-Type: text/plain; charset=utf-8
Unknown service "test"
If you had tested 1.10.6 with ACLs enabled, you would've also received a similar error as you are seeing with 1.11.1.
I seem to be having some problems with my Varnish set up. I have a clean install of Varnish and Nginx running on ubuntu, everything seems to be running, but I don't seem to be actually caching anything.
This is what im seeing:
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
X-Powered-By: PHP/5.5.9-1ubuntu4.14
Cache-Control: no-cache
Date: Tue, 02 Feb 2016 10:15:17 GMT
Content-Encoding: gzip
X-Varnish: 196655
Age: 0
Via: 1.1 varnish-v4
Accept-Ranges: bytes
Connection: keep-alive
I'm almost certain the problem is to do with the "age" response being 0. I have read that the Cache-Control header can be the culprit and have spent some time configuring both nginx and my vcl file with solutions I have read on-line, none of which have worked.
I'm open to any ideas even ones I have tried before (hence why im not listing the steps I have already taken).
Thanks in advance for any thoughts you might have.
Remove "no-cache" and set "max-age=120" (in seconds) in the Cache-Control header instead.
Also note that if the request contains any cookies or if the response sets any cookies than by default varnish is not gonna cache.
I have read about Web Hdfs in all this links
link1 link2 link3
checking with telnet - the port is OPEN
made the needed settings in cloudera ( virtual box) to make webhdfs enable
testing directly on cloudera works:
[cloudera#quickstart ~]$ curl -i -L "http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN"
HTTP/1.1 307 TEMPORARY_REDIRECT
http://quickstart.cloudera:50075/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN&namenoderpcaddress=quickstart.cloudera:8020&offset=0
Content-Length: 0
Server: Jetty(6.1.26.cloudera.4)
HTTP/1.1 200 OK
Cache-Control: no-cache
Expires: Tue, 01 Dec 2015 14:08:07 GMT
Date: Tue, 01 Dec 2015 14:08:07 GMT
Access-Control-Allow-Methods: GET
Access-Control-Allow-Origin: *
Server: Jetty(6.1.26.cloudera.4)
trying directly on cloudera web browser also work for :
http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN
I am able to send PING C:\Users\User>ping 10.0.0.88
Telnet working for port 50070.
But when trying this command outside the cluster it dosnt work (HOST)
"http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN"
more info
LISTSTATUS works from HOST
http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFileop=LISTSTATUS&user.name=hadoop`
returns
{"FileStatuses":{"FileStatus":[
{"accessTime":1448982310759,"blockSize":134217728,"childrenNum":0,"fileId":26625,"group":"cloudera","length":47,"modificationTime":1448978300739,"owner":"cloudera","pathSuffix":"","permission":"644","replication":1,"type":"FILE"}
]}}
but op=OPEN from HOST
"http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN&user.name=hadoop"
returns
This webpage is not available
what could be the problem ?
It seems there is syntax problem in
http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?`op=OPEN&user.name=hadoop`
Try
http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN
I have a problem with HttpFS service of hadoop.When i try to curl some resource:
curl -i http://192.168.4.180:14000/webhdfs/v1/user/hadoop/?op=LISTSTATUS
the response i get is:
HTTP/1.1 404 Not Found
Server: Apache-Coyote/1.1
Content-Length: 0
Date: Mon, 17 Aug 2015 08:57:47 GMT
But when i try to do the same with webhdfs it works:
curl -i http://192.168.4.180:50070/webhdfs/v1/user/hadoop/?op=LISTSTATUS
HTTP/1.1 200 OK
and so on ....
Httpfs service is running on port 14000, i have checked it via nmap.
Any suggestions or ideas what might be the problem?
I meet the same problem. And solved by this link
In brief, you need to add the symbol link:
# Point to the 'webapps' in current.
cd /etc/hadoop-httpfs/tomcat-deployment
ln -s /usr/hdp/current/hadoop-httpfs/webapps webapps