If you are working on a latest MacBook pro with M1 chip. Installing Cassandra and starting it might throw an error.
Steps
1: Installed Jdk8
2: Installed Cassandra 4.0.1
How to start: /opt/homebrew/opt/cassandra/bin/cassandra -f
Output:
ERROR [main] 2021-10-08 00:03:12,568 NativeLibraryDarwin.java:64 - Failed to link the C library against JNA. Native methods will be unavailable.
java.lang.UnsatisfiedLinkError: /opt/homebrew/Cellar/cassandra/4.0.1/tmp/jna9964159388012624603.tmp: dlopen(/opt/homebrew/Cellar/cassandra/4.0.1/tmp/jna9964159388012624603.tmp, 1): no suitable image found. Did find:
/opt/homebrew/Cellar/cassandra/4.0.1/tmp/jna9964159388012624603.tmp: no matching architecture in universal wrapper
/opt/homebrew/Cellar/cassandra/4.0.1/tmp/jna9964159388012624603.tmp: no matching architecture in universal wrapper
at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442)
at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498)
at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694)
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2627)
at java.base/java.lang.Runtime.load0(Runtime.java:768)
at java.base/java.lang.System.load(System.java:1837)
at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1018)
at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:988)
at com.sun.jna.Native.<clinit>(Native.java:195)
at com.sun.jna.NativeLibrary.<clinit>(NativeLibrary.java:87)
at org.apache.cassandra.utils.NativeLibraryDarwin.<clinit>(NativeLibraryDarwin.java:55)
at org.apache.cassandra.utils.NativeLibrary.<clinit>(NativeLibrary.java:98)
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:258)
at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:763)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:887)
INFO [main] 2021-10-08 00:03:12,596 MonotonicClock.java:199 - Scheduling approximate time conversion task with an interval of 10000 milliseconds
INFO [main] 2021-10-08 00:03:12,597 MonotonicClock.java:335 - Scheduling approximate time-check task with a precision of 2 milliseconds
WARN [main] 2021-10-08 00:03:12,597 StartupChecks.java:143 - jemalloc shared library could not be preloaded to speed up memory allocations
WARN [main] 2021-10-08 00:03:12,597 StartupChecks.java:187 - JMX is not enabled to receive remote connections. Please see cassandra-env.sh for more info.
ERROR [main] 2021-10-08 00:03:12,597 CassandraDaemon.java:909 - The native library could not be initialized properly.
Solution:
Find where is jna-..*.jar located. you can do this using
find /opt/homebrew/ -name '*.jar' | grep cassandra
Browse to https://search.maven.org/artifact/net.java.dev.jna/jna/5.8.0/jar and download the jar from top-right downloads button on the page.
Replace your jna-..*.jar file with the one you downloaded. In my case i replaced jna-5.6.0.jar. Remember to keep the file name as your previous file name. Example I moved jna-5.8.0.jar and renamed as jna-5.6.0.jar
mv /Users/mansooralikhan/Downloads/jna-5.8.0.jar /opt/homebrew/Cellar/cassandra/4.0.1/libexec/jna-5.6.0.jar
Restart cassandra
To echo Mansoor's answer, I'll add that the version of JNA shipped with Apache Cassandra 4.0 unfortunately is not compatible with the M1 architecture.
To remedy this, head to the "downloads" section of the JNA GitHub repo, where you should find the latest version of the JNA jar file.
https://github.com/java-native-access/jna#jna
Download JNA version 5.8 or higher, and replace the existing jna-5.6.0.jar file in Cassandra's lib/ directory (tarball-based installs).
Just to add to the answers here, I wanted to note for posterity that the issue with arm64 on Apple M1 devices not supported by JNA 5.6.0 has been raised with the Apache Cassandra project previously.
More recently, it has been reported in CASSANDRA-17019. I brought it up with the project devs/contributors and hopefully it gets reviewed and resolved soon. Cheers!
I am writing (hopefully) a simply AWS Lambda that will do an RDS Oracle SQL SELECT and email the results. So far I have been using the Lambda Management Console, but all the examples I've run across talk about making a Lambda Deployment Package. So my first question is can I do this from the Lambda Management Console?
Next question I have is what to import for the Oracle DB API? In all the examples I have seen, they download and build a package with pip, but that would then seem to imply using a Deployment Package (see above). Trying to import any of these modules listed in the examples simply give "No module named "...
After writing the above I dug into the boto3 API referrence and came up with:
import boto3
client = boto3.client('rds-data')
But it gives the error: Unknown service: 'rds-data'.
So I'm still lost.
As you can probably tell, I'm new to the Lambda environment. Any suggestions or examples would be greatly appreciated. Thanks.
This is an update of the solution using the 18c Oracle client libraries. If it wasn't for main solution it would have taken me a lot longer to get my code working. This will hopefully help anyone that follows.
(an aside - I tried getting it working with the instantclient_19_3 but went round in circles for a day, and then tried with instantclient_18_5 and it worked)
Files downloaded and used
instantclient-basic-linux.x64-18.5.0.0.0dbru.zip (all files)
cx_Oracle 7.2.2 (https://cx-oracle.readthedocs.io/en/latest/release_notes.html#releasenotes)
libaio.so.1.0.1 (as described in main answer, renamed to libaio.so.1)
This then gave these files in the zip (lambda_function.py is my python source code)
zip contents
Apparently, AWS Lambda is using an older version of boto3, which does not have rds-data yet.
So I'm afraid you will have to create a deployment package containing a more recent version of boto3.
One way to do this, would be to:
Create your lambda handler file (in this case named index.py).
def my_handler(event, context):
client = boto3.client('rds-data')
print(client)
# do stuff
return "hello world"
Add a requirements.txt file in the same folder, which will contain something like:
awscli >= 1.16.118
boto3 >= 1.9.108
Now run this (depending on the setup on your computer, you can use pip instead of pip3) in the directory/folder of your index and requirement file:
pip3 install -r requirements.txt -t .
zip -r somezipname .
Next, upload this zip and change your handler 'entry point' to index.my_handler. The code should now run without errors.
older version of boto3 does not support rds-data.
but you can deploy package with zip folder.
i recommend you to use import cx-oracle
for that install cx-oracle using pip
and upload zip packages. check this
[How can I access Oracle from Python?
After much groaning and gnashing of teeth I have come up with a successful solution.
rds_data (as confirmed by AWS Support) is only supporting Aurora Databases. Wish the AWS documents mentioned this. 8{(>
Thanks to the answers above as well as Jason Landrey for hints as to the solution.
In order to access RDS/Oracle, you need to use cx_Oracle. But wait, there's more.
cx_Oracle is not in the standard Lambda environment, so you need to bring your own. My development environment is on Windows, but the Lambda environment is Linux. So, you need to download and install in your packaging directory I got mine from https://pypi.org/project/cx-Oracle/#files. Install locally with:
pip install cx_Oracle-7.1.2-cp37-cp37m-manylinux1_x86_64.whl -t .
You will see several file appear in . Then you need to find a Linux system and download /lib64/libaio.so.1.0.1 and call it libaio.so.1 in your packaging directory.
And then you need to download both Oracle instant client basic and SDK packages from http://www.oracle.com/technetwork/topics/linuxx86-64soft-092277.html.
Create a zip file with all these items (including your own Python source). In doing so, rename Oracle instant client files libclntsh.so.11.1 to libclntsh.so and libocci.so.11.1 to libocci.so.
Upload the zip to a S3 bucket as the direct deploy is limited to 66mb and this zip is a bit larger.
Create a Lambda with the appropriate IAM permissions and VPC access, install the package and it should be good to go.
I found that if you don't include all the instant client files you start getting Oracle errors about missing timezone and NLS information.
List of zip contents (for me, YMMV):
7996693 08/24/2013 12:30 libnnz11.so
0 03/11/2019 16:10 cx_Oracle-7.1.1.data/
0 03/11/2019 16:10 cx_Oracle-7.1.1.data/data/
0 03/11/2019 16:10 cx_Oracle-7.1.1.data/data/cx_Oracle-doc/
0 03/11/2019 16:10 cx_Oracle-7.1.1.dist-info/
1325 03/13/2019 12:35 Email.py
1805 02/19/2019 21:11 cx_Oracle-7.1.1.data/data/cx_Oracle-doc/LICENSE.txt
163 02/19/2019 21:11 cx_Oracle-7.1.1.data/data/cx_Oracle-doc/README.txt
851 02/19/2019 21:11 cx_Oracle-7.1.1.dist-info/METADATA
628 02/19/2019 21:12 cx_Oracle-7.1.1.dist-info/RECORD
109 02/19/2019 21:12 cx_Oracle-7.1.1.dist-info/WHEEL
10 02/19/2019 21:11 cx_Oracle-7.1.1.dist-info/top_level.txt
2270301 02/19/2019 21:11 cx_Oracle.cpython-37m-x86_64-linux-gnu.so
2140 03/13/2019 14:21 getSecrets.py
5560 03/12/2019 08:48 libaio.so.1
53865194 08/24/2013 12:30 libclntsh.so
118738042 08/24/2013 12:30 libociei.so
7633 03/13/2019 16:39 scheduleReports.py
I'm suddenly getting the following weird resolution error:
[ERROR] Resolution failed. Capabilities satisfying the following requirements could not be found:
[<<INITIAL>>]
? osgi.identity: (osgi.identity=javafx-osgi)
? [javafx-osgi version=8.0.2]
? osgi.wiring.host: (osgi.wiring.host=system.bundle)
It appears that the system bundle (Apache Felix framework) is no longer being found... Oddly, this error just popped up today. I havent worked on this project for a week. But the last commit ran without a problem. If I revert to an earlier revision of the program, the problem remains...
We are using Java 1.8.0 161-b12; BND Tools 4.0.0 and Apache Felix Framework 1.8.
Our app.bndrun looks like this:
index: target/index.xml
-standalone: ${index}
-runrequires: osgi.identity;filter:='(osgi.identity=org.ops4j.pax.logging.pax-logging-service)', \
osgi.identity;filter:='(osgi.identity=javafx-osgi)', \
osgi.identity;filter:='(osgi.identity=com.foo.bar.command)',\
osgi.identity;filter:='(osgi.identity=com.foo.bar.testservice)', \
osgi.identity;filter:='(osgi.identity=com.foo.bar.main-screen)', \
osgi.identity;filter:='(osgi.identity=com.foo.bar.verify-screen)', \
osgi.identity;filter:='(osgi.identity=com.foo.bar.testclient)'
-runfw: org.apache.felix.framework;version='5.6.8'
-runee: JavaSE-1.8
-runbundles: \
com.foo.bar.testservice;version='[0.0.1,0.0.2)',\
org.apache.felix.scr;version='[2.1.0,2.1.1)',\
org.osgi.service.log;version='[1.4.0,1.4.1)',\
org.osgi.util.function;version='[1.1.0,1.1.1)',\
org.osgi.util.promise;version='[1.1.0,1.1.1)',\
org.osgi.util.pushstream;version='[1.0.0,1.0.1)',\
com.foo.bar.testclient;version='[0.0.1,0.0.2)',\
org.ops4j.pax.logging.pax-logging-api;version='[1.10.1,1.10.2)',\
org.ops4j.pax.logging.pax-logging-service;version='[1.10.1,1.10.2)',\
javafx-osgi;version='[8.0.2,8.0.3)',\
com.foo.bar.launcher;version='[0.0.1,0.0.2)',\
com.foo.bar.main-screen;version='[0.0.1,0.0.2)',\
com.foo.bar.ui-main;version='[0.0.1,0.0.2)',\
com.foo.bar.verify-screen;version='[0.0.1,0.0.2)',\
org.apache.felix.configadmin;version='[1.9.2,1.9.3)',\
com.foo.bar.launcher;version='[0.0.1,0.0.2)',\
com.foo.bar.command;version='[0.0.1,0.0.2)'
-runproperties: felix.cm.dir="${user.home}\\Documents\\Prog731\\config"
This is a small demo program with very few dependencies. As far as I can determine, neither our code nor any the external dependencies have changed. But the problem is reproducible on different development machines...
What could cause a resolution error such as this?
UPDATE:
We are using the latest development snapshots of the bndtools 4.x from the https://bndtools.ci.cloudbees.com repository. Might this be it?
UPDATE #2:
As Requested, the MANIFEST of javafx-osgi-8.0.2.jar:
Manifest-Version: 1.0
Export-Package: com.sun.javafx, com.sun.glass.ui, com.sun.javafx.anima
tion, com.sun.javafx.applet, com.sun.javafx.application, com.sun.java
fx.beans, com.sun.javafx.beans.event, com.sun.javafx.binding, com.sun
.javafx.charts, com.sun.javafx.collections, com.sun.javafx.css, com.s
un.javafx.css.converters, com.sun.javafx.css.parser, com.sun.javafx.c
ursor, com.sun.javafx.effect, com.sun.javafx.embed, com.sun.javafx.ev
ent, com.sun.javafx.font, com.sun.javafx.font.coretext, com.sun.javaf
x.font.directwrite, com.sun.javafx.font.freetype, com.sun.javafx.font
.t2k, com.sun.javafx.fxml, com.sun.javafx.fxml.builder, com.sun.javaf
x.fxml.expression, com.sun.javafx.geom, com.sun.javafx.geom.transform
, com.sun.javafx.geometry, com.sun.javafx.iio, com.sun.javafx.iio.bmp
, com.sun.javafx.iio.common, com.sun.javafx.iio.gif, com.sun.javafx.i
io.ios, com.sun.javafx.iio.jpeg, com.sun.javafx.iio.png, com.sun.java
fx.image, com.sun.javafx.image.impl, com.sun.javafx.jmx, com.sun.java
fx.logging, com.sun.javafx.media, com.sun.javafx.menu, com.sun.javafx
.perf, com.sun.javafx.print, com.sun.javafx.property, com.sun.javafx.
property.adapter, com.sun.javafx.robot, com.sun.javafx.robot.impl, co
m.sun.javafx.runtime, com.sun.javafx.runtime.async, com.sun.javafx.ru
ntime.eula, com.sun.javafx.scene, com.sun.javafx.scene.control, com.s
un.javafx.scene.control.behavior, com.sun.javafx.scene.control.skin,
com.sun.javafx.scene.control.skin.caspian, com.sun.javafx.scene.contr
ol.skin.caspian.images, com.sun.javafx.scene.control.skin.modena, com
.sun.javafx.scene.control.skin.resources, com.sun.javafx.scene.input,
com.sun.javafx.scene.layout, com.sun.javafx.scene.layout.region, com
.sun.javafx.scene.paint, com.sun.javafx.scene.shape, com.sun.javafx.s
cene.text, com.sun.javafx.scene.transform, com.sun.javafx.scene.trave
rsal, com.sun.javafx.scene.web, com.sun.javafx.scene.web.behavior, co
m.sun.javafx.scene.web.skin, com.sun.javafx.sg, com.sun.javafx.sg.pri
sm, com.sun.javafx.sg.prism.web, com.sun.javafx.stage, com.sun.javafx
.text, com.sun.javafx.tk, com.sun.javafx.tk.quantum, com.sun.javafx.u
til, com.sun.javafx.webkit, com.sun.javafx.webkit.drt, com.sun.javafx
.webkit.prism, com.sun.javafx.webkit.prism.resources, com.sun.javafx.
webkit.prism.theme, com.sun.javafx.webkit.theme, javafx, javafx.anima
tion, javafx.application, javafx.beans, javafx.beans.binding, javafx.
beans.property, javafx.beans.property.adapter, javafx.beans.value, ja
vafx.collections, javafx.collections.transformation, javafx.concurren
t, javafx.css, javafx.embed, javafx.embed.swing, javafx.event, javafx
.fxml, javafx.geometry, javafx.print, javafx.scene, javafx.scene.canv
as, javafx.scene.chart, javafx.scene.control, javafx.scene.control.ce
ll, javafx.scene.effect, javafx.scene.image, javafx.scene.input, java
fx.scene.layout, javafx.scene.media, javafx.scene.paint, javafx.scene
.shape, javafx.scene.text, javafx.scene.transform, javafx.scene.web,
javafx.stage, javafx.util, javafx.util.converter, com.sun.deploy.uito
olkit.impl.fx
Fragment-Host: system.bundle; extension:=framework
Bundle-ManifestVersion: 2
Bundle-Name: JavaFX 8 OSGi extension bundle
Bundle-License: The Apache License, Version 2.0
Bundle-SymbolicName: javafx-osgi
Bundle-Version: 8.0.2
UPDATE #3:
I think the javafx-osgi issue is not the real problem. I threw out all FX related stuff and ended up with an error saying "No OSGi framework has been added to the run path"?!
This seems to be a bug in the felix resolver:
Insights from the Bndtools bugtracker: https://github.com/bndtools/bndtools/issues/1877
Felix bugtracker: older issue with felix 5.4.0 and bndtools 3.4.0 ResolverImpl infinite loop
The above felix ticket has been open for over a year and there doesn't seem a solid understanding (yet) what the root cause is.
For those who hit the same roadblock: We ended up switchting to eclipse equinox.
When trying to install my application as an osgi bundle with the install command in karaf on the command line, everything seems fine. When I then type start (id) everything still seems fine, but my application does not seem to accept requests. When I then type log:display, I get this:
2016-04-20 13:49:38,251 | INFO | Thread-19 | bundle | 37 - org.apache.aries.spifly.dynamic.bundle - 1.0.1 | Bundle Considered for SPI providers: oms-integrations
2016-04-20 13:49:38,251 | INFO | Thread-19 | bundle | 37 - org.apache.aries.spifly.dynamic.bundle - 1.0.1 | No 'SPI-Provider' Manifest header. Skipping bundle: oms-integrations
I'm new and I have no clue what this means ("No 'SPI-Provider' Manifest header.") or how to solve it?
This is not a problem. It just means that you have Aries spi-fly installed. It scans all bundles for this header and enhances the ones with the header to be able to use the ServiceLoader in OSGi. If you do not use ServiceLoader then you can safely ignore these messages.
You can also configure this logger to WARN to suppress the messsages.
I have strange problem with Servicemix version Fuse ESB 4.4.1.
Sometimes the part of the commands will not load and be not available. Usually this happens with quite often used by me command, grep. This looks as following:
karaf#root> list | grep spring
Command not found: grep
It seems to be random, restart usually helps. With previous versions of Fuse ESB it happened sometimes, but quite rare, now it happens quite often. Can someone help, what is causing the problem?
Perhaps completely unrelated, but I've encountered a number of boot-time race conditions in Karaf and its dependencies. Most importantly, this one that I filed:
https://issues.apache.org/jira/browse/KARAF-910
"Race between FeatureService and ConfigAdmin for resolving mvn: URLs?"
That particular defect only manifests if you have some non-standard settings for pax-url-mvn, but it's a symptom of the general problem that configadmin applies settings asynchronously, so it matters if the configadmin thread is faster or slower than the main OSGi bundle-starting thread.
I have not seen any Karaf Command problems related to that race, but my problem is superficially similar in that some bundle services randomly don't start.
The 'grep' command has a full name - shell:grep. You might try that to see if e.g. another command has been installed with the same short (unqualified) name and it's getting confused.
The other possibility is that the bundle that provides the grep service has stopped, possibly by accident.
osgi:list -t 0 -s
will show you a list of all the bundles by symbolic name, which includes this one: (the number may be different):
[ 18] [Active ] [Created ] [ 30] org.apache.karaf.shell.commands (2.2.3)
karaf#root> osgi:stop 18
You are about to access system bundle 18. Do you wish to continue (yes/no): yes
karaf#root> help | grep grep
Command not found: grep
karaf#root> osgi:start 18
You are about to access system bundle 18. Do you wish to continue (yes/no): yes
karaf#root> help | grep grep
shell:grep
As for why that bundle is being stopped -- maybe something (or someone) is explicitly stopping it? Or it's being stopped by accident?