I understand that the exchange type x-modulus-hash has given its place to x-consistent-hash. I am trying to deploy an app, the source code for which uses x-modulus-hash and I can't change it.
Which version of RabbitMQ should I revert back to? I am deploying the app using the stolon/rabbitmq-ha helm chart. It would be more useful to know the suitable version for this chart.
Alright, my bad! x-modulus-hash has not been discontinued. It is an exchange type that will be add when the sharding plugin is enabled using the following command:
rabbitmq-plugins enable rabbitmq_sharding
Related
Does anyone have an idea how to "undeploy" an API proxy from an "archive" type Apigee-x environment? It seems like it can't be done from the Apigee UI, it throws an error:
"This operation is not supported. The Environment DeploymentType is ARCHIVE. The required Environment DeploymentType is PROXY".
The environment type can't be changed. The available CLI commands are "delete", "deploy", "describe", "list", "update" (no "undeploy" command found), "delete" doesn't work as it can't delete an active deployment. The final goal is to be able to delete the environment, which requires to remove/undeploy all API proxies from it first.
I found a solution. The "undeploy" feature I was looking for is not included in the current Apigee-x release. On the Apigee community, Google staff stated that they are looking into implementing it at some point. Until then there is a workaround, where one can deploy an archive with no deployments defined to the environment. Once this is done the Proxy is "undeployed" and the environment could be deleted. Here is the step-by-step process of doing it.
In our application a Node.js front end talks to a Java Spring backend. Everything is containerized and running in Kubernetes. Some time ago we added support for Jaeger distribtued tracing across the front end and back end services. Jaeger has been running fine until recently.
Our Elasticsearch cluster was out of date so we upgraded. That mandated an upgrade of Jaeger--we ended up with the following bits:
Jaeger Helm Chart: 0.13.3 from https://github.com/helm/charts/tree/master/incubator/jaeger
Jaeger Client for Node: 3.17.1
Jaeger Client for Java:
opentracing-spring-jaeger-cloud-starter 2.0.3
opentracing-spring-jaeger-web-starter 2.0.3
Both of the opentracing libraries have a dependency on the version 0.35.1 of the Jaeger Java client.
Since upgrading, traces that are created on one side or the other seem to be fine. But traces that span the boundary (i.e. start on the Node.js front end and complete on the Java backend) generate errors in the jaeger-agent pod like this:
{"level":"error","ts":1574224941.7531824,"caller":"processors/thrift_processor.go:119",
"msg":"Processor failed","error":"*jaeger.Batch error reading struct: *jaeger.Span error
reading struct: *jaeger.Log error reading struct: *jaeger.Tag error reading struct:
error reading field 3: Invalid data length","stacktrace":"github.com/jaegertracing/jaeger/cmd/agent/app/processors.
(*ThriftProcessor).processBuffer\n\t/home/travis/gopath/src/github.com/jaegertracing/jaeger/cmd/
agent/app/processors/thrift_processor.go:119\ngithub.com/jaegertracing/jaeger/cmd/agent/app/proc
essors.NewThriftProcessor.func2\n\t/home/travis/gopath/src/github.com/jaegertracing/jaeger/cmd/a
gent/app/processors/thrift_processor.go:83"}
For these traces, the Jaeger UI shows us the spans that were created by the front end before invoking the backend API, but the child backend spans do not show up as you would expect.
What might cause this sort of processor error?
It looks like you have different versions of opentracing. The spring-starter-jaeger version 2.x upgrade the version of opentracing, so you might have introduced this breaking changes when you upgraded the dependency version.
I followed the instructions to install Dinghy on my Spinnaker installation using https://docs.armory.io/spinnaker/install_dinghy. But I don't see my pipelines being updated.
I see the spin-clouddriver showing the webhooks are being received but nothing else.
How do I check the logs for Dinghy so I can troubleshoot this?
I needed to run hal deploy apply and enable the Github service. Then I started seeing updates to my Spinnaker pipelines.
Does anyone know how to configure NServiceBus (v6.2) using the AzureServiceBusTransport to not attempt to create namespaces?
I'd like to configure NServiceBus the use a connection string which only has permissions to send (the queue's should already be there and if not an error is more appropriate than creation) but whenever I configure it this way I get the following error:
Pre start-up check failed: Configured to create topology, but have no manage rights for the following namespace(s): xxxxxxxxxxxxxx
This error message suggests the functionality is configurable but having looked through the code and the documentation for the mechanism I can't find it.
Many thanks
Adam
Looks like I answered my own question - a bug was raised against the AzureServiceBusTransport and subsequently fixed a little while ago:
https://github.com/Particular/NServiceBus.AzureServiceBus/issues/528
As the bug says upgrading to version 7.1.8 or 7.2.3 and not enabling installers fixes the issue.
I use GlassFish 4.1 single cluster with two instances on same node.
My steps for rolling upgrade:
deploy app with old version ClusterTest:1.0
(asadmin deploy --target=cluster1 --enabled=true --availabilityenabled=true --name=ClusterTest:1.0 ClusterTest.ear)
deploy new version app with disabled state ClusterTest:1.1
(asadmin deploy --target=cluster1 --enabled=false --availabilityenabled=true --name=ClusterTest:1.1 ClusterTest.ear)
enable app on 1st instance
(asadmin enable --target=instance1 ClusterTest:1.1)
On 1st instance new app is available, but on 2nd: 404 error (i expect available old version)
what i do wrong?
There are a lot of problems with rolling upgrades on GlassFish. Many of these problems have been fixed in the latest version of Payara Server. It may be that you aren't hitting any of these issues, but there is a very detailed discussion on the Payara GitHub repository:
https://github.com/payara/Payara/issues/455
You may also want to look at this video which describes basic application versioning which may contain the information you need
https://www.youtube.com/watch?v=6QVBsH6IjEA