I'm having a project using both HBase 1.0.0 (Cloudera version) and Elasticsearch. With the upgrade to ES 2.0 I'm experiencing a problem with guava version. ES 2.0 requires guava version 18.0, but Cloudera requires guava 14.0.1.
No matter what version I define in my dependency management in my parent pom one of the two won't work.
Looking around I see that this problem occurs quite some time (e.g. http://gbif.blogspot.co.at/2014/11/upgrading-our-cluster-from-cdh4-to-cdh5.html)
1) Any ideas on how to solve this problem without any complex re-design of my application?
If not, I'm thinking of doing all the ES-stuff in a separate application. Communicating via messaging (already using AMQ) for indexing. Not sure though how to communicate for search/filter requests (at the moment implemented via Java API).
2) Any other ideas?
3) Any ideas/hints on how to solve the communication issue?
I found this blog post when googling in combination with maven-shade plug-in, so this might be another option.
https://www.elastic.co/blog/to-shade-or-not-to-shade
Related
My system currently uses a gemfire cache and uses the io.pivotal.gemfire dependencies. Two of the dependencies, geode-core and geode-management both use org.jgroups (jgroups) as a runtime dependency. Currently I am using version 9.10.13 of the io.pivotal.gemfire dependencies (geode-core, geode-wan, geode-management etc. (see code snippet below)) and version 3.6.14.Final of jgroups.
Due to a vulnerability in the current version of jgroups, I want to upgrade to a newer version (any in version 4 would be sufficient but the newer the better (versions)). The problem I am having is that when I attempt to upgrade to a newer version (3.6.17 or newer), I get the following error when attempting to start-up the cache server:
java.lang.NoSuchMethodError: org.jgroups.View.<init>(Lorg/jgroups/ViewId;Ljava/util/List;)V
at org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.installView(JGroupsMessenger.java:459) ~[geode-membership-9.10.13.jar:?]
When I actually go to investigate the issue, it looks as though it is referencing a line where the View class constructor was changed to take in a "Collection" instead of a "List", which seemed like a strange error since a List is a Collection.
I have tried using different combinations of jgroups and gemfire going up to 4/5 and 9.10.17 respectively without success. If anyone has any recommendations on how to move past (solve) this jgroups vulnerability while using a gemfire cache it would be much appreciated. Also, is there a table that lists gemifre versions vs. supported versions of jgroups?
Was able to get in contact with VMware Tanzu. All 9.* versions of gemfire require jgroups 3.6.14.Final. The new version of gemfire (10.*) which is currently in beta, is supposed to remove all dependencies on jgroups.
My company's Sonatype scan shows Spring-Web is vulnerable even for the latest version (currently 5.2.3.RELEASE).
It reads:
"Found security vulnerability CVE-2016-1000027 with severity 9.8".
I noticed CVE-2016-1000027 is added to the NATIONAL VULNERABILITY DATABASE
on 01/02/2020, and it is in regards to
"Spring Framework 4.1.4 suffers from a potential remote code execution
(RCE) issue if used for Java deserialization of untrusted data".
Is this an obsolete ticket or has it not be resolved after 4 years?
This issue is resolved from a Spring Framework point of view, see my latest comment summarizing the situation on that issue. Your application is only vulnerable if you're using HTTPInvokerServiceExporter or RemoteInvocationSerializingExporter and reading data from untrusted sources.
Deserializing Java code from untrusted sources is a well-known problem in Java (so, all Java applications and Frameworks!), and this feature might be removed in future Java versions.
Given the nature of this security problem (there's no way to "fix it" besides removing the classes, which will be done in the next major version of Spring Framework), contacting your vendor or your security team is the best course of action. The Spring team is happy to help the community with this matter by providing more context on that issue if needed.
I was reading https://www.elastic.co/blog/deprecating-rivers which stats that ES rivers (plugin) are getting deprecated. i.e. any plugin directly integrated with ElasticSearch server will no longer work beyond ES 3.x onwards.
Couchbase plugin is one of those kind.
I searched all the documents of couchbase plugin at http://developer.couchbase.com/documentation/server/4.5/connectors/elasticsearch-2.1/elastic-intro.html but could not find if they are using deprecated way or not?
Does anyone know? Should we keep using couchbase plugin or should start planning to write data directly to ES using our application.
We have couchbase data getting replicated to ES using couchbase plugin and XDCR.
I'm the maintainer of the Couchbase ES transport plugin. As Roi mention in his answer, the plugin doesn't use rivers, so it won't be deprecated. It currently supports any version of ES from 1.3 to 2.x, and I'm working on adding support for 5.x. It's taking a bit longer, because ES 5.x broke some configuration sharing features in unexpected ways.
I'd suggest always looking at our github repo for the latest plugin releases:
https://github.com/couchbaselabs/elasticsearch-transport-couchbase
The Couchbase plugin is not using Rivers, there is another River plugin which is not longer valid.
take a look here: https://github.com/couchbaselabs/elasticsearch-transport-couchbase
In my project I am forced to use these packages:
com.sparkjava:spark-core:2.3, which ends up using jetty-server:9.3.2.v20150730
org.apache.spark:spark-core_2.10:1.2.0, which ends up using jetty-server:8.1.14.v20131031
Note that com.sparkjava and org.apache.spark have nothing to do with each other. They are called both spark funnily.
The issue here is that both jetty versions are incompatible, so if I force jetty 8.X the system crashes, if I force jetty 9.X the system crashes again, I get java.lang.NoClassDefFoundError: org/eclipse/jetty/server/ServerConnector in one case and java.lang.NoClassDefFoundError: org/eclipse/jetty/server/bio/SocketConnector in the other.
What I am expected to do in such a situation ?
Note: I've tried to shadow jetty, but the dependency manager resolves just one (9.X by default, or 8.X if I force it) and then it shadows it, so it's really not helping.
It would be exceedingly difficult to resolve this situation.
Jetty 8.1 is about 4 major version behind Jetty 9.3, which represents many hundreds of releases of difference.
Note: Jetty versioning is [servlet_support].[major_ver].[minor_ver].
Jetty 8.x is Servlet 3.0, while Jetty 9.x is Servlet 3.1
The architecture of the connectors has evolved tremendously in that time frame, from being old school blocking Sockets in Jetty 8 to no blocking connectors at all in Jetty 9, with Jetty 9 needing to evolve the connectors to support features in TLS/1.2, and ALPN in order to properly support HTTP/2, and the internal I/O handling to support the new Servlet 3.1 Async I/O feature set.
Solution #1:
You won't be able to have both versions running in the same VM without some sort of classloader isolation, and careful configuration to ensure they don't claim the same resources (listening ports, temp files, etc)
Solution #2:
Upgrade (or downgrade) one or the other spark dependency till you hit a common jetty version. (Spark_2.11 / 2.0.0 seems to support Jetty 9.2.x)
Solution #3:
Apache Spark is open source, go submit a patch that upgrades its use of Jetty to 9.3 (this might be difficult as Apache Spark isn't ready to use Java 8 yet, which is a requirement for Jetty 9.3)
Our application is having issue with rendering time on various part. We have been able to pin point the performance issue with a profiler (YourKit Java Profiler) within the JSF restoreView phase (lifecycle). Since, we use a lot of components in some pages the rendering of the tree must be the source of the problem. Some question on stackoverflow looks pretty much like what we are dealing. Also, we can see the same slow speed in dev and production.
Some specs:
MyFaces 2.1.7
javax.el 2.1.0
Profiler (CTRL+SCROLL to see details):
We are trying to find solutions. So far, we came up with those:
Use less composition/components (which is not that great, because we liked to make generic component).
We could also go into JSF stateless mode.
Find the actual problem with JSF (IN DEEP).
Recently, we found out that some JUEL library (expression language) could greatly increase the rendering time.
I've been dealing with making JUEL works with Spring 3 (with OSGI). Here's the spec:
JUEL 2.1.3.1 bundle (note: this bundle use a different version of javax.el than the one I use in my application will that cause clash?)
I have found another maven repo which only does Juel Implementation and a more recent version.
Update:
Found a solution for javax.el clashing, since there was a lot of problems in the juel-api (because it's export his own javax.el) I modified the manifest with that line Fragment-Host: javax.el to eliminate it.
Is there a configuration/set up to enable better performance?
Or, how to you actually configure JUEL with MyFaces and Spring?
I would say that the problem is caused by Spring Web Flow. I remember this issue SWF-1540. First check if you are using the right version (2.4.0.M1 or upper). Note personally I have not tested if that configuration has a performance issue, but I can say that MyFaces 2.1.7 an upper versions does not have any issues. It is known that some EL versions has perf issues, so try with juel or with apache EL (jasper-el, bundled with Tomcat).
As a personal opinion, watch out for Spring proxies, it is known that in some cases, when the pages are very big and complex, the proxies has a significant impact over performance. The suggested solution is use Apache OpenWebbeans, which is a very fast CDI implementation, optimized for those cases when you have a lot of beans interconnected.
You can check this article too "Understanding JSF 2 and Wicket: Performance Comparison" for tips about MyFaces performance.
You have to try by yourself what will work for your case, but I hope with these advices you can focus better your search.