my trusty couchbase cluster (version 4.6) is emitting an "auto_failover_node" alert. I think I understand what auto-failover means, but I dont understand the meaning of the alert.
does it mean that the cluster has performed auto-failover? documentation on this topic is very scarce.
ok. I did find an answer in the alert email that couchbase sent:
"Node ('ns_1#ip-10-32-3-207.ec2.internal') was automatically failovered."
so I guess the alert is raised whenever a node is auto-failovered.
Related
I am doing a lookup operation Couchbase Java SDK 3.0.9 which looks like this:
// Set up
bucket = cluster.bucket("my_bucket")
collection = bucket.defaultCollection()
// Look up operation
val specs = listOf(LookupInSpecStandard.get("hash"))
collection.lookupIn(id, specs)
The error I get is BUCKET_NOT_AVAILABLE. Here are is the full message:
com.couchbase.client.core.error.UnambiguousTimeoutException: SubdocGetRequest, Reason: TIMEOUT {"cancelled":true,"completed":true,"coreId":"0xdb7f8e4800000003","idempotent":true,"reason":"TIMEOUT","requestId":608806,"requestType":"SubdocGetRequest","retried":39,"retryReasons":["BUCKET_NOT_AVAILABLE"],"service":{"bucket":"export","collection":"_default","documentId":"export:main","opaque":"0xcfefb","scope":"_default","type":"kv"},"timeoutMs":15000,"timings":{"totalMicros":15008977}}
The strange part is that this code hasn't been touched for months and the lookup broke out of a sudden. The CB cluster is working fine. Its version is
Enterprise Edition 6.5.1 build 6299.
Do you have any ideas what might have gone wrong?
Note that in Couchbase Java SDK 3.x, the Cluster::bucket method returns instantly, and continues opening a bucket in the background. So the first operation you perform - a lookupIn here - needs to wait for that resource opening to complete before it can proceed. It looks like it took a little longer to access the Couchbase bucket than usual and you got a timeout.
I recommend using the Bucket::waitUntilReady method after opening a bucket, to block until the resource opening is complete:
bucket = cluster.bucket("my_bucket")
bucket.waitUntilReady(Duration.ofMinutes(1));
This problem can occur because of firewall. You need to allow these ports.
Client-to-node
Unencrypted: 8091-8097, 9140 [3], 11210
Encrypted: 11207, 18091-18095, 18096, 18097
You can check more from below
https://docs.couchbase.com/server/current/install/install-ports.html#_footnotedef_2
This issue has taken up all my day, and I can't figure out whats going on
I can see that my service worker is registered , however "sometimes" when I click offline in developer tools the ServiceWorker for my domain just disappears!!
But this is the main problem when I reload the app I see the following behaviour.
You can see the ngsw.json is loaded twice and the main.js is loaded 3 times! main.d3ae2084xxxx && main.bbe5073dxxxx && then main.d3ae2084xxxx again!
If I inspect the response of both ngsw.json requests you can see that both show main.d3ae2084xxxx as the correct version of main.js but it still loads main.bbe5073dxxxx...
First ngsw.json request
Second ngsw.json request
Whats even more frustrating is the actual loaded version is the previous main.bbe5073dxxxx...!!!!
If anyone has any ideas how this can be happening please let me know.
Update... So found out about this excellent little endpoint
https://you-app-url/ngsw/state
This will give you lots of debug information about your service worker.
In my case this
Driver state: EXISTING_CLIENTS_ONLY (Degraded due to failed
initialization: Hash mismatch (cacheBustedFetchFromNetwork):
https://dev-xxxx.net/main.eb8468bb3ed28f02d7c2.js: expected
b5601102b721e0cf777691d327dc965d40d1c96e, got
83c18fdb4a5942c964a31c119a57e0b8e16fe46e (after cache busting)
So looks like this is going to be a CDN issue of some sort in my case, will update with an answer when I know for sure.
You've probably resolved this by now, but I had the same issue which turned out to be due to the CDN (Cloudflare in my instance) was optimising the content.
In Cloudflare the key option is 'Auto minify' that needs to be disabled.
I browsed through the other threads - there was no concrete answer.
I implemented a service worker for notifcations
http://docs.pushwoosh.com/docs/chrome-web-push
I checked everything - all scripts are in root, the keys are well implemented. However, I do not get prompted to allow notifs.
Console output reads:
GET https://mydomain/service-worker.js net::ERR_FILE_EXISTS
Note: I do have the correct URL (just changed it here).
What causes the service worker error? How do I fix this?
It isn't anything to worry about. See the internal bug report: https://code.google.com/p/chromium/issues/detail?id=541797 the TL'DR is that when Chrome tries to fetch a new SW if there is no change and thus nothing to install it throws this error message to indicate that state. There is nothing that you need to do.
I am planning to add in the message carbon function(when a user is logged into multiple device and send a message or/receive a message, it will sync between all devices) for a chat server, i am running on Ejabberd and using strophe.js...
I am wondering if there are plugin written for Ejabberd that i can install and also for strophe.js???
I looked over https://github.com/processone/ejabberd-contrib and the github for strophe.js
None of them seem to have plugins for message carbon. Wondering if anyone has this implemented before??
I have read that if it doesnt, i should treat it as a groupchat??? I am not sure why that would work??? And not exactly sure if thats good for the resources, and what if it scales up, would that have impact on the overall structure.
If it is treated as a group chat, then i assume each resource/session would be treated as a different user? Then when a message is sent into that group, all of those other session/users are updated, so even there are 2 users??
ejabberd supports message carbons as default in latest version.
This feature is unrelated to groupchat and cannot and should not be treated similarly.
If you read XEP-0280 Message Carbons you should see that sending a packet similar to the following is enough to enable it:
<iq id='enable1' type='set'>
<enable xmlns='urn:xmpp:carbons:2'/>
</iq>
You may find also valuable information in XMPP Academy video #2 at 27m30s.
In developing in Fi-Cloud's CEP I've been having an issue that has been happening repeatedly. As I'm trying to develop a definition to perform a task, CEP's server and Authoring Tool stop responding, although ssh is still responsive.
This issue happens as I develop. I'm using the AuthoringTool to alter the definition bit by bit and then I re-upload it to the server through the authoring tool's export feature.
To reinitiate the proton with the new definition each time I alter it, I use Google's Postman with this single operation:
-PUT (url:http://{ip}:8080/ProtonOnWebServerAdmin/resources/instances/ProtonOnWebServer)
header: 'Content-Type' : 'application/json'; body : {"action": "ChangeDefinitions","definitions-url" : "/ProtonOnWebServerAdmin/resources/definitions/Definition_Name"}
At the same time, I'm logged in with three ssh intances, one to monitor the files being created on /opt/tomcat10/sample/ and other things, and the other two to 'tail -f ' log files the definition writes to, as events are processed: one log for events recieved and another log for events detected by the EPAgent.
I'm iterating through these procedures over and over as I'm developing and eventualy CEP server and the Authoring Tool stop responding.
By "tailing" tomcat's log file (# tail -f /opt/tomcat10/logs/catalina.out) I can see that, when under these circumstances, if I attemp a:
-GET (url: http://{ip}:8080/ProtonOnWebServerAdmin/resources/instances/ProtonOnWebServer)
I get no response back and tomcat logs the following response:
11452100 [http-bio-8080-exec-167] ERROR org.apache.wink.server.internal.RequestProcessor - An unhandled exception occurred which will be propagated to the container.
java.lang.OutOfMemoryError: PermGen space
Exception in thread "http-bio-8080-exec-167" java.lang.OutOfMemoryError: PermGen space
Ssh is still responsive and I can look at tomcat's log this way.
To get over this and continue, I exit ssh connections and restart CEP's instance in the Fi-Cloud.
Is the procedure I'm using to re-upload and re-run the definition inapropriate? Should I take a different approach to developing?
When you update a definition that the CEP is already working with, and you want the CEP engine to work with the updated definition, you need to:
Export the definition using the authoring tool export (as you did)
Stop the engine run, using REST PUT
PUT //host:8080/ProtonOnWebServerAdmin/resources/instances/ProtonOnWebServer
{"action":"ChangeState","state":"stop"}
Start the engine, using REST PUT
PUT //host:8080/ProtonOnWebServerAdmin/resources/instances/ProtonOnWebServer
{"action":"ChangeState","state":"start"}
You don't need to activate the "ChangeDefinitions" action, since it is the same definition name that the engine is already working with.
Activating "ChangeDefinitions" action, only influences the next run of the CEP, and has no influence on the current run.
This answer your question about how you should update a CEP definition.
Hope it will solve your issue.