Command Strategy Class Not found in Spark 1.3 - sql

I am using spark 1.3 and am able to create spark context . when i try to access a Cassandra DB using CassandraSQL context. I get the below error.
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/spark/sql/execution/SparkStrategies$CommandStrategy
at org.apache.spark.sql.cassandra.CassandraSQLContext$$anon$1.(CassandraSQLContext.scala:67)
at org.apache.spark.sql.cassandra.CassandraSQLContext.(CassandraSQLContext.scala:64)
at SparkSample$.main(SparkSample.scala:28)
at SparkSample.main(SparkSample.scala)
I use the spark-cassandra connector from Datastax. Also that I am not able to see any documentation related to SQL Execution
https://spark.apache.org/docs/1.2.0/api/java/index.html?org.apache.spark.sql.execution in spark 1.3 version. Any thoughts ?

First, if you look at the Cassandra readme you will see that they do not support 1.3 yet. I'm sure they would accept PR's though :)
Now, to the crux of the matter; they are using package private pieces so they are prone to these types of breaking changes. If you look at SparkStrategies in the 1.2 branch, you will see the CommandStrategy at the bottom. However, in SparkStrategies 1.3, the last object has become DDLStrategy, which does not even look the same at a glance. So, they might have removed this altogether. Your best bet is to report this to the Cassandra connector project and wait for official support of 1.3

Related

Reactor Retry: reactor.retry.Retry vs. reactor.util.retry.Retry

First time I use retry pattern in reactor.
I have got totally confused with the management of retrying in reactor. The main source of confusion is the existing 2 Retry classes in the same package!
I want to retry a Mono/Flux process when specific exceptions happens, during a max number of times.
My first step is create a reactor.retry.Retry in this way.
reactor.retry.Retry retry = reactor.retry.Retry
.anyOf(
WebClientResponseException.BadRequest.class,
WebClientResponseException.BadGateway.class)
.retryMax(nRetries);
And then, I want to parameterize my mono with
mymono.retryWhen(utilRetry);
Following the documentation in Interface Retry I have to convert the reactor.retry.Retry object in a reactor.util.retry.Retry using the method withThrowable, but there is no sample (and the sample in the doc doesn't work because the objects are not compatible).
So, I'm looking for something like
utilRetry=retry.somemethod()
Any comment for newbie will be welcome!
UPDATE:
I have found this issue reactor.retry.Retry does not provide methods for Mono.retryWhen(Retry retrySpec) #231 where it seems there is some migration conflics, but does not provide a canonical solution

SonarQube: How to suppress a warning in Kotlin code

I'm using SQ 7.3-alpha1 with sonar-kotlin-plugin-1.0.1.965.jar. However, I cannot deactivate a special warning inside my Kotlin code for repositories in Spring Data where I need an "_" in a method name.
I tried both //NOSONAR and #Suppress("kotlin:S100") and #SuppressWarnings("kotlin:S100"). Any hint is appreciated.
You're not able to deactivate that issue because none of the mechanisms you're trying to use have been implemented for Kotlin.
Instead, you'll have to do this from the UI side.
Great news, https://jira.sonarsource.com/browse/SONARSLANG-373 is fixed in version 1.6 of Sonarslang. So an update to that version might improve the situation. I’ve not tested it yet, hence the cautious wording.

How to use Distributed Entry Iterator feature with RemoteCache on Infinispan +7.1 version?

I use keySet() api in production. But I know it's not recommended.
So I'd like to change it to new api over version 7.x
It's introduced on official blog.
http://blog.infinispan.org/2014/05/iterate-all-entries-in-cache.html
But I can't figure it out how to use it in Hotrod RemoteCache.
Anyone already tried successfully?
Thanks a lot.
This was answered at https://developer.jboss.org/message/920029?et=watches.email.thread#920029
Radim Vansa said:
Regrettably, this feature is not available yet over Hot Rod. Remote clients have certain lag after embedded-mode features. Map/Reduce and DistributedExecutors over HR are quite close on the roadmap, distributed entry retrievers should follow.
William Burns said:
I also wanted to make sure you are aware that the keySet method is fine to use in the API as outlined [1]. The Cache Javadoc has some more specifics [2]. Basically the methods you should never use are the toArray methods on the collections returned from keySet, entrySet or values. The other methods are done lazily. Note this means the collection isn't a copy like before as well.
Also to note if you do end up using any of the iterators from these bulk methods, you need to make sure to close them properly.
However as Radim pointed out Hot Rod does not have this support yet (embedded only), but should be coming to a new version soon.
[1] http://blog.infinispan.org/2014/11/why-doesnt-mapsize-return-size-of.html
[2] https://docs.jboss.org/infinispan/7.1/apidocs/org/infinispan/Cache.html#entrySet%28%29

How do I handle version with ModeShape JCR?

I have created a POC program to exercise the JCR version handling with ModeShape on both 4.0.0.Alph4 and 3.8.0.Final. The version number is increased from 1.0, 1.1, 1.2 1.3, 1.4, and etc. Then I restored the version 1.2 and made changes to it. But I noticed that the new version number is 1.3.0 now. Should the new version number be 1.2.0 (since it is based on the original 1.2) or am I missing something from the program? Thanks!
I would have expected 1.2.1, so it looks like it might be a bug. Please report the issue in the project's bug tracker. ModeShape is an open source project, we'll likely look at the issue much more quickly if you provide a simple test case.
But what we really love is a pull-request that adds to a test class one or more test methods that replicates the problem. We can get that pull-request, run the tests (which would fail), and then fix the problem. This really saves us a lot of time, and it us know that we're fixing the exact problem you see. And you'll know that the fix will be included in the next release.

ISessionFactoryKeyProvider missing from CommonServiceLocator when upgrading NHibernate from 2.1 to 3.0

I have a ASP.NET MVC application that uses Spring.NET 1.2 for dependecy injection and NHibernate 2.1 for ORM. It has been running on MVC 3, using S#arp Architecture in a slightly modified version which we have been compiling ourselves, something I am now striving to get rid of. (I.e. I am going to start using referenced SharpArch .dlls instead of pure source code.)
The initialization of Spring is done using tips taken from here, as well as using the SpringServiceLocatorAdapter found here. NH is initialized using SharpArch's NHibernateSession.Init, which is given our two assemblypaths. The mapping is done with HBM XML files.
The decision to move to NH 3 led to a serious case of DLL Hell, due to which I of course had to update FluentNH, NH Validator, SharpArch, Spring, and Castle Windsor binaries. To get things working a lot of manual labor was needed, changing references and doing minor code fixes. This was all expected.
Now I've got the software running well enough that Spring is initialized and the DI done correctly. But when a repository tries using it's Session object, I get the following error.
Error creating object with name '' :
no services of type
'SharpArch.NHibernate.ISessionFactoryKeyProvider'
defined
I've been trying to figure out the cause of this for the best part of a day now.
It seems to me like SpringServiceLocatorAdapter is obsolete, but I can find no information regarding that. Also, simply removing the use of it results in repositories' Sessions being null and thus NullReferenceExceptions. But as far as I know the problem could just as well be the way NH is initialized.
Hopefully someone can point me in the right direction. I'm having a hard time since I'm not the one who setup the system to begin with, and lists of breaking changes for the version upgrades are hard to find.
Thanks a lot! I will of course provide more information if needed.
You need to register an implmentation of ISessionFactoryKeyProvider with spring, the default implementation is DefaultSessionFactoryKeyProvider, in windsor, the statement would look like this:
container.Register(
Component.For(typeof(ISessionFactoryKeyProvider))
.ImplementedBy(typeof(DefaultSessionFactoryKeyProvider))
.Named("sessionFactoryKeyProvider"));