I needed update apache storm 1.0.0 to latest version 1.x.x (1.2.3). What is the steps need? What is the changes in storm configuration file? Is there any guide that help (migration)?
thank you so much
I don't believe (but could be wrong) that there are any breaking changes in the configuration file between 1.0.0 and 1.2.3. Migration should follow the usual steps for Storm upgrades:
Upgrade your Storm hosts one at a time by
Downloading the 1.2.3 binary release
Shutting down the Storm services running on the host (e.g. workers, supervisor, Nimbus)
Extracting the 1.2.3 release, and making any adjustments to the configuration files you had in the old install
Restarting your Storm services on that host, using the new install instead of the old install
You may also want to
Upgrade your topologies to build against the version of Storm you're upgrading to (optional, but can help catch any compile-time errors in non-core modules that may have changed within the major version, such as storm-kafka-client)
This way you can upgrade with no downtime. Of course if you don't care about downtime you can just shut down the whole cluster, do the steps outlined above, then restart the cluster using the new installs.
Edit: You're asking about the full diff of configuration options between 1.2.3 and 2.0.0. You can find every configuration option for 1.2.3 here, and the full list of configuration options for 2.0.0 here and here.
Related
We are trying to upgrading from 2.9.1 to 2.11.0 and we have already using org.apache.ignite.transactions.spring.SpringTransactionManager which is now not available in core lib, when we checked docs https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-tx#maven-configuration its suggesting to use ignite-spring-tx-ext. But when we used that in pom.xml, its repository dose not exist in Maven repository. Can some please help us how to solve this.
Starting from Ignite 2.11 several modules have been extracted from the core repository and moved into a separate ignite-extensions project, including Apache Ignite Spring Transactions with its own release cycle.
Unfortunately, I can't see any signs of a new ignite-extensions release (there is only 1.0.0) meaning that only Apache Ignite core project was updated. I suppose for now you have to wait for the new ignite-extensions release or use Ignite 2.10.
I want to install StormCrawler 2.0, but I am unable to locate the appropriate installation instructions. In particular, what versions of Apache Storm, Zookeeper, and Java is StormCrawler 2.0 compatible with?
Thanks!
The POM file for 2.0 contains the information you are after.
Java 8
Apache Storm 2.1 (likely to be upgraded to 2.2 shortly)
according to Storm's documentation ZK 3.3.3
You could have a look at Ansible Storm and see if you can get it to work with Storm 2 with a few changes?
In the process of using WSO2 API Mananger 1.10.0, I scanned out security vulnerabilities. These vulnerabilities occurred on tomcat. The currently embedded version of tomcat is 7.0.59. I want to know how to upgrade this tomcat to solve these security vulnerabilities, such as upgrading the version to 7.0.93 ... I tried to change the pom.xml of product-apim. The version of carbon.kernel.version was updated from 4.4.3 to 4.4.37, but there were new problems in the packaging process. I don't know whether I should update the variables of carbon.commons.version, carbon.registry.version, etc. at the same time.
You shouldn't be upgrading the tomcat version directly as you are doing.
Your WSO2-APIM is very old version which is 1.10.
At that time that tomcat 7.0.59 version was used by wso2. It's better to upgrade your WSO2-APIM to latest 2.1.0 version. Here is the link for the same.
I am in a bit of a jam.
I am working on upgrading our software to have Kettle 6.1. Specifically, we need the feature of S3FileOutput. Meanwhile, our application was already using the aws-sdk for other things.
So I am running into a problem: Pentaho Kettle requires version 1.0.something of aws-sdk. Our application, on the otherhand needs 1.9.6 of the aws-sdk.
To give more details, the feature of Kettle we require is in the pentaho-big-data-legacy plugin. Even if I upgrade to the latest version of Kettle, pentaho-big-data-legacy still uses the old version of the aws-sdk.
I've read a bit about plugins having special classloaders, so one option I was considering is that maybe I am not downloading the right dependency. However, when I tried downloading pentaho-big-data-plugin instead of pentaho-big-data-legacy, I got weird errors, so I stopped going down this path.
I was wondering if there is any way I could put the Kettle Libs in one folder, and my application libs in another folder, and then set some sort of a PENTAHO environment variable to pick up the libraries from the alternative folder.
Another option is if I could somehow set the pentaho classloader, but I don't know if this is possible.
What are my options for having 2 versions of the aws-sdk in my application, with regards to Kettle?
Maven can do much more than download dependencies.
The Maven Shade plugin can help with your current predicament. During a build, it can rename packages.
You would make a project that builds a "fat jar" (or "uber jar") with Pentaho Kettle and its version of the aws-sdk re-packaged as appropriate. That dependency would be handled before your project is built, so you are free to use whatever version of aws-sdk you like since there is no longer a conflict on package names.
We are developping a GWT 2.4 application using Maven. Due to the problem described here we tried to switch to GWT 2.5. We also switched to version 2.5 for maven-gwt-plugin from org.codehaus.mojo. We had no problems with this arrangement (I mean running and debugging the GWT 2.5 application - using goals gwt:run and gwt:debug) until we decided to build a new war. For this we are using maven-war-plugin version 2.3. To our surprise the war file building runs out of memory no matter how much memory we allow in the vm arguments - we increased those until the limit of the physical memory (about 4 GB) but to no result. The combination of goals we use to build our war is "compile gwt:compile war:war", the sources are compiled correctly, but then the building process does not create even the first permutation as it runs out of memory.
If we go back to version 2.4 both for gwt and maven-gwt-plugin the war is built correctly with no other changes. Has anyone been faced with this problem before? Any suggestions for a proper solution that would allow us to build a 2.5 gwt war would be greatly appreciated.
How do you change JVM memory configuration? MAVEN_OPTS? gwt-maven-plugin forks a new process so make sure you use extraJvmArgs of the gwt-maven-plugin.