Kibana is not loading and giving below error .. restarted the elasticsearch/Logstash service ..but issue still exist ..Memory/Sapce available on the node
Error: Request Timeout after 30000ms
at https://X.X.X.X:5601/bundles/kibana.bundlenter image description heree.js?v=10000:78465:16
What is the kibana version you are using?
Because v5.1.1 seems to have solved the issue.
You could probably remove JS client timeout, rely on backend for timeout.
As per Kibana git commit, the client timeout need not be relied upon. It could rely on backend for timeout.
So, all you need to try is:
Go to : src/kibana/services/es.js
Set requestTimeOut to 0, as shown in the git commit.
Related
I'm using nifi in version 1.14.0 and facing a very weird situation.
I have a loadbalanced connection and after disconnection in the cluster (due to out of memory errors)
I'm getting the following error:
Error load balance server -
standartLoadBalanceProtocol attempted to receive flowfile from peer for connection with id xxx but no connection exists with that ID
Did anyone experience anything familiar? Thanks for the help!
I think it relates to this ticket https://issues.apache.org/jira/plugins/servlet/mobile#issue/NIFI-9695. Please upgrade to NiFi version 1.16 and see if this error happens again.
I see errors like this when issuing ddev commands:
segment 2020/03/31 11:30:15 ERROR: sending request - Post https://api.segment.io/v1/batch: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
segment 2020/03/31 11:30:15 ERROR: 2 messages dropped because they failed to be sent and the client was closed
Does it matter? What can I do about it?
This is usually a result of either really bad internet or pi-hole (or similar DNS interceptor) being active and preventing proper lookup of api.segment.io (it returns 0.0.0.0 as the IP address instead of the real address)
It does no harm but it's certainly annoying.
There are at least two solutions if pi-hole is the culprit:
Whitelist api.segment.io in pi-hole; use this command: pihole -w api.segment.io
Tell ddev not to send instrumentation messages via segment: ddev config global --instrumentation-opt-in=false
Hi have a slightly different error message:
segment 2020/08/17 09:39:08 ERROR: sending request - Post "https://api.segment.io/v1/batch": x509: certificate is valid for *.ddev.local, *.ddev.site, localhost, ddev-router, ddev-router.ddev_default, not api.segment.io
segment 2020/08/17 09:39:08 ERROR: 2 messages dropped because they failed to be sent and the client was closed
But it has the same reason: pi-hole is blocking segment.io.
I can find the blocked requests in the pi-hole log (pihole -t). And I found the domains segment.io and segment.com in one of the pi-hole default blocklists on GitHub. This list is genereated automatically and the segment.io entry comes from adaway.org. Seems like the lines where added ~8 month ago.
Like described in this answer it helps to whitlist segment.io in pi-hole or disable the reporting feature in ddev.
My app was rejected today due to 'not supporting IPv6'. I've attached screenshots of the error they received which comes from a Parse.com API call.
I could really use some help on this, as I have no clue where to start with this.
Does anyone know if Parse.com supports IPv6? Or do I need to add something to my code? Do I need to migrate to Parse Server?
Please help =\
---- EDIT ---- 9/22/16
OK so, after my first rejection due to "IPv6" issues, I re-submitted and the app was approved. I'd still like to understand if Parse.com and Parse Server are officially IPv6 compatible but as for now, I'm just happy my app was approved. I'll keep this thread open and will edit it when I find the answer.
I have a parse server hosted on Heroku which doesn't support IPv6 yet (see here). But your server is not the reason why the app is rejected. It is your app which should support IPv6.
A possible solution is to download the latest Parse framework from https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/releases/tag/1.14.2 and replace the old ones. I think it should work.
Below is my comparison with the logs in the console for my app with the two different versions of Parse framework.
I have used Parse.framework and Bolts.framework from Feb 2016 in my Apple TV app and also just got rejected also for not supporting IPv6. I checked the log and found that
nw_resolver_start_crazy_eyeballs_timer Received IPv4 result first, performing crazy eyeballs: waiting 50ms on IPv6 for myapp.herokuapp.com:0.
__nw_resolver_start_crazy_eyeballs_timer_block_invoke Crazy eyeballs timer fired: did not receive IPv6 in time, reporting only IPv4 result for myapp.herokuapp.com:0
nw_resolver_cancel_crazy_eyeballs_timer Cancelling crazy eyeballs timer for myapp.herokuapp.com".
It seems the performance issue comes from the 50ms when the app loads.
I use the latest Parse framework and no "crazy_eyeballs_timer" shows up. The log seems more promising because I can see a IPv6 address in the log now.
nw_resolver_create_dns_service_on_queue Starting host resolution myapp.herokuapp.com:0, flags 0x4000d000
nw_resolver_host_resolve_callback flags=0x3 ifindex=0 error=NoSuchRecord(-65554) hostname=myapp.herokuapp.com. addr=0.0.0.0:0 ttl=60
nw_resolver_host_resolve_callback flags=0x2 ifindex=0 error=NoError(0) hostname=us-east-1-a.route.herokuapp.com. addr=88:ffff::bbbb:afb9.0 ttl=74
Here I changed the addr of my server in the log for security reason.
I will send a new update of my app to review and I believe that it should work. I will leave a comment when it gets accepted :)
There is a problem with Graphite Docker images I try to run on my PC. Containers start up gracefully but I'm not able to send any message so that it would be displayed under "Metrics" tab. Volumes Mounting doesn't help either. Default storage-schema.conf should accept all messages.
The message used for testing is such:
echo "test.bash.stats 42 date +%s" | nc localhost 2003.
Moreover, most of the time (but not always) after sending above listed message "400 Bad request" error is responded.
Following images has been tested:
https://hub.docker.com/r/hopsoft/graphite-statsd/
https://hub.docker.com/r/kamon/grafana_graphite/
Any ideas, I'm missing something to configure additionally?
Despite the above explained issue there is is question related to Spring Boot Metrics export to Graphite over StatsD.
As described here http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-metrics.html in section 49.8.3 Example: Export to Statsd there is a requirement only to add com.timgroup:java-statsd-client as dependency and add property spring.metrics.export.statsd.host.
Unfortunately nothing is send to Graphite (docker image running on local PC https://github.com/kamon-io/docker-grafana-graphite). I have checked network with Wireshark (udp.port=8125). Is there maybe something missing to add into Spring boot project with metrics?
We are attempting to connect to a WebDAV server using net use over SSL. On some servers we're seeing an issue in which this connection only succeeds if we specify port 443 in the URL.
Does Map
net use * "https://example.com:443/folder"
net use * "\\example.com#SSL#443\folder"
and, bizarrely, so does this:
net use * "\\example.com#SSLasdf\folder"
Does Not Map
net use * "https://example.com/folder"
net use * "\\example.com#SSL\folder"
In the non-working cases we consistently receive the following error:
System error 67 has occured.
The network name cannot be found.
We have noticed some things that might be useful information:
We have a test server that's configured the same way as the prod server and it works as expected.
In the non-working cases, no incoming requests are ever seen at the prod server from the failing host.
All clients are based on the same image.
The problem does not manifest uniformly on all clients -- some work, some don't.
There is an existing, valid entry for example.com in the client DNS cache.
Flushing the client DNS cache of the affected servers does not resolve the problem.
Once the problem appears, it seems to stick. That is, if I execute one of the working mappings, delete it, and then immediately execute one of the non-working mappings, the problem persists.
We are utterly stumped. Any theories?
You are seeing different behaviors because you are connecting using different names. Once a name has been attempted and failed, the WebClient (this is the service that enables WebDAV) will cache the response for a period. To clear the cache, locate the WebClient service in the Services console and restart it. Or from an administrative command prompt execute the following command:
net.exe stop webclient && net.exe start webclient
We ultimately determined that we were mis-interpreting the System Error 67 that net use was returning. We discovered two interesting things:
In the event that the WebDAV returns a 404 or a 50x on the initial, root folder PROPFIND, net use will (rightly) interpret this as the root folder being unavailable. The fact that it says the network name could not be found let us to believe that the problem was with the name resolution, but it was really just saying, 'hey, I couldn't find anything at this path.'
If 'net use' fails due to a 404/50x, it appears that for a brief period of time it will automatically fail any additional mappings for that same host without issuing a request. For example, if net use http://me.com/foo returns a 404, then net use http://me.com/bar will instantly fail if made in rapid succession to that first call, and no request record will be seen in the WebDAV server logs.
My best guess is that appending the #443 port didn't make any real difference. What it perhaps did do was to trick net use into thinking it was talking to a different host, at least for the purposes of its 'auto-fail' feature. But that's just a guess.