I am trying to connect RabbitMQ from Python. Here is the below code I am using
connection = pika.SelectConnection(parameters, self.on_connection_open, self.on_open_error_callback,
stop_ioloop_on_close=False)
I setup the configuration in RabbitMQ and copied the same in Python code also. But when running it throws the below error.
TypeError: _ _init_ _() got an unexpected keyword argument 'stop_ioloop_on_close'
Can anyone help me to fix this issue. For your information, I am using the latest versions of all the softwares.
Thanks in advance!!
For this issue, need to downgrade pika version to 0.11.2 and the recent versions throwing this error.
The problem is that the argument was removed in version 1.0.0 because of this issue. You should lock down the requirements to always make sure a version older than 1.0 is installed.
e.g.
Add something like this to the requirements file of your project.
pika<1.0
In addition it's probably worth looking into having the code fixed, and then removing the version restriction.
If you don't want to downgrade your version you can just remove the stop_ioloop_on_close argument. Since the functionality should have remained the same (i.e. now it's no longer checking what to do on close, so it will keep running).
If you want do want to close the connection you can use the on_close_callback parameter to call connection.ioloop.stop() yourself if needed.
Related
I have uwsgi==2.0.20 and python[CPython 3.10.4]. And I can't execute the following code:
uwsgi.cache_get(key, 'mycache')
Error:
PY_SSIZE_T_CLEAN macro must be defined for '#' formats.
Is there any way to fix this for myself by setting PY_SSIZE_T_CLEAN to a Dockerfile or something?
Because in the latest version of uwsgi it is not fixed yet, as I understand it.
There is a merged pull request, but the new version containing that fix isn't released yet. What we ended up doing in our company is using the source code from the development branch. You can install it from GitHub using pip. Though it isn't the best idea to have a dependency from a development version of a package.
another solution is to use Redis directly, I decided to use Redis
I have the following code...
It compiles and functions just fine with the --experimental-json-modules flag but it still shows the following error on the red tilda...
I am already configured to use ECMAScript6+ so what else do I need?
Import assertions proposal is supported since version 2021.3, see WEB-52552; please consider upgrading IDEA to the most recent version
While using cargo install spl-stake-pool-cli
I am getting issues with the last step. Please check the attached screenshot.
so for now you'll need to be using strictly version 1.6.11 of the SDK and it should work. These dependency changes will also be added to the next release so you can expect it moving forward.
I am occasionally getting the above error logged in AWS lambda. Just curious about it and want to know how can I replicate it locally in nodejs12.
This means that one of your packages or yourself are using a deprecated feature as of that version of node.
You would need to figure out which module it is and see if there is a fix for the issue.
The packages themselves can fix the issue by changing anywhere they use ._headers to .getHeaders
That said, this is only a warning, this wont currently break anything but it's always better to upgrade.
I've been trying to work through an issue that developed while attempting to upgrade our testing environment from 12.04 to 14.04 ubuntu on aws. Prior to this, the Package repository version of solr was 1.4.1 which matched our 1.4.1 solrj client integrated with our application.
Changing the base AMI to the 14.04 latest and running our default deploy caused solr 3.6.2 server to be installed. It appears it was accepting our configs without issue, however when our client tried to connect we received different errors:
The first was an unknown custom field, which we traced back to our deployment scripts not moving our schema.xml and solrconfig.xml to /etc/solr/conf/ but keeping it in the base directory.
We corrected this issue, and then ran into the following:
'exception: Invalid version or the data in not in 'javabin' format'
This was generated by a wrapper ontop of solrj, but I'll be honest and say I know nothing regarding Solr and that this may be on our end. I've asked our dev team to look at 2 options:
1) enabling: 'server.setParser(new XMLResponseParser());'
Which is the recommendation on the backwards compatibility for an older client.
2) updating our client in the application to 3.6.2
-I know less about the requirements on this.
My fall back is to revert to 1.4.1, but it appears it hasn't been touched since 2011, which makes me hesitant.
Any thoughts / suggestions would be appreciated!
Thanks!
I think the best option is to maintain the same version of Solr and Solrj.
I used for a lot of time Solr 1.4.1 and, while as you said, the most part of it works with newer versions without any problem, actually a lot of things have been changed since 1.4.*
I did your same porting last year, (from 1.4.1 to 3.6.1) and I can confirm you that the 2nd way is the right one: all changes you must do in your client code are just "formal" and very very quick.
Any workaround you could do for being able to communicate with a different version (between Solrj and Solr) is just, as the word says, a "workaround" and it could lead to unexpected (hidden) side-effects later.