Is AMQP transport 3.6.2 compatible with Mule 3.7.*? - mule

I've got some strange unexplained problems with a couple of apps after upgrading to Mule 3.7.0. I haven't conclusively proven that they fail because of anything to do with AMQP - the error messages are really nondescript and don't point the finger at any particular component, but AMQP is the only additional component I'm using, and although I see that it's been upgraded to 3.7.0-SNAPSHOT, that version doesn't seem to have been published anywhere yet.
Does anyone have experience running like this, either good, or bad?

The answer is yes, it's completely compatible.
As mentioned in my comment above, my problem was actually ApiKit which needed manually upgrading. Now my apps deploy and run correctly again on Mule 3.7.1

Related

NETCORE ConfigurationRoot Memory Leak

We are facing memory leak issue with ConfigurationProviders ConfigurationRoot.
Looks like this issue may have been fixed
https://github.com/aspnet/Extensions/issues/861
However, Microsoft.Extensions.Configuration 3.0.0 requires NETCORE 3.0. Can someone please confirm how this fix can be applied with .NETCore 2.2.7? We do not want to upgrade to NETCORE 3 yet, as we have time constraints for project delivery.
This is specifically related to the reload change token, so I would assume disabling reload on the JSON files would negate the issue. That means you'd have to restart your app if you made any changes to the JSON files, but that really shouldn't be much of an issue, as you should really only be making configuration changes as part of a new build and deployment anyways (via your CI/CD pipeline).
Otherwise, no, you'd have to upgrade to Core 3.0, unless this fix gets back-ported into the 2.1 LTS release. That's actually a possibility, so it might be worth calling it out on the issue, since a memory leak is a pretty serious issue to leave unchecked in an LTS release. It might have just flown under the team's radar.
The other possibility is that is is back-ported into 2.1, but since you're on 2.2, it's not there. I'm not sure if they'd necessarily back port it into 2.2, since that's not an LTS. As such, your choice may boil down to down-grading to 2.1 or upgrading to 3.0. That's the breaks of the game when you're not not on the LTS release - upgrading may be required.
This issue has been sorted, see details here
https://github.com/aspnet/Extensions/issues/2576

Is UniObjects supported in UniData 8.x?

We integrated with UniData in 2013 using UniObjects for .net and we tested against UniData 7.3. We now have a client on a newer versions of UniData (8.1) and we are having new problems with the integration.
I dug through the documentation on RocketSoftware's website and found the UniObject documents were no longer listed under the documentation for UniData 8.1 and 8.2. I also couldn't find any recent threads via search engine around UniObjects.
"UniObjects for .net Developer's Guide" is listed here:
https://www.rocketsoftware.com/products/rocket-u2/UniData-v7.2
Not listed here:
https://www.rocketsoftware.com/products/rocket-u2/rocket-unidata-v821-technical-documentation
I'm not sure if the documentation just moved and I am overlooking it on the site or if it went away entirely. My suspicion is that it's not supported anymore or won't be supported soon.
Does anyone know definitively that UniObjects is supported or not supported in 8.x versions of UniData?
Any insight around this is greatly appreciated!
Yes, it's definitely supported. I work with an application that uses Uniobjects for integration extensively and it works the same as ever with 8.1 on Linux. The documentation is kind of a mess and keeps moving around, but the functionality is definitely still there.
There were security/encryption changes a few years ago, so the parameters around that are a good place to start looking. There's also a debug flag to check what's happenning - serverdebug.
https://groups.google.com/forum/#!topic/u2-users/okE3-TL_mvE was a recent thread on u2users group, it may be worth asking in that forum to get more responses too. It's a friendly bunch.

Erlang/OTP upgrade lose existing RabbitMQ messages

I had Erlang/OTP 17 and RabbitMQ Server 3.4.3 installed on my local windows box. Before upgrading to the newer versions in production, I wanted to give it a try on my local box to see if upgrade won't cause any problem. I am trying to upgrade them to the latest versions - Erlang/OTP 21 and RabbitMQ Server 3.7.8. When I do upgrade, I lost all my existing messages.
I had some existing messages in multiple queues. As soon as I upgraded Erlang/OTP (21), I see all my existing messages are gone. I even tried installing the newer RabbitMQ Server (3.7.8), still I don't see my old messages in the queues. I thought mnesia database would help in restoring the messages. I guess either I don't understand the concept or I am missing some settings.
I don't want our production clients complain about the messages being lost. I couldn't find much help online on this topic. But, surely RabbitMQ documentation talks about Blue-Green Deployment Strategy, never did that, so was not sure if that would help in our case, or it is an overkill and has a simpler solution. Also, want to add that I did all manual upgrade. If anyone know a better process of upgrade for single node without losing the existing messages, please guide and help me.
The documentation clearly states that you can't upgrade directly from version 3.4.3 to version 3.7.8: link. You must first upgrade to 3.6.16.
In your case, using a blue-green upgrade would be the only way to avoid having to first upgrade to version 3.6.16 prior to 3.7.8.

about BRO: how to intercept AMQP messages(RabbitMQ) in OpenStack

I've been doing some experiment with BRO in OpenStack, and first of all, i need to intercept all the RabbitMQ messages with BRO, but i'm not really familiar with this tool and I've followed the step of the following git blog
https://github.com/packetsled/bro_amqp_plugin
and there is an error
the error
Do anyone know what's wrong with my step? Thank you very much!
Sorry for the delayed response, but that version of the plugin is quite old, and not maintained. An updated version for Zeek (formally known as Bro) 3.x is available at https://github.com/mixmodeai/bro_amqp_plugin. I'm working on updating to 4.x, but it is a background task.
Please post the full text of the command you used for configuration and make, as well as the output.

When do we get an "AssertionError: HDF dataset not available. Check your clearsilver installation"

I am trying to install a dbauth plugin for trac. I know that I probably should be chasing this on other trac and trac-hacks related forums but still I am wondering, why do one get this error? What exactly is happening?
In my case the dbauth plugin is trying to read things like: "trac_permissions" and "trac_users" from a sqlite or mysql database. I have checked the databases, the values are in there but neither of them work. clearsilver is installed and running as well.
So what is usually causing this error? Is it that the HDF parser is receiving wrong info? Please do not take this as a trac question, just explain me why these types of errors occur.
Thanks.
a Google Search should get you started. You should also consider an alternative, because DbAuth is deprecated.
What version of Trac are you running? Recent versions use Genshi instead of Clearsilver, which means that Clearsilver-based plugins likely won't work correctly (not without modifications, at least). According to the Trac wiki, Trac version 0.11 still had the infrastructure to support Clearsilver-based plugins, version 0.12 retained this support in an unsupported form (meaning use at your own risk, you're on your own if something doesn't work), and version 0.13 dropped support for Clearsilver-based plugins entirely. Unless you're still running an older Trac install that's version 0.10 or 0.11, I'm inclined to say that this problem is due to the phasing out of Clearsilver support.
According to this trac-hacks ticket, you may want to try re-compiling Clearsilver with the Python bindings (this would only be useful if you're running Trac 0.11 or older).