I am getting following error when running R through renjin , can someone help me
I am using following packages
library(dplyr)
library(downloader)
when I run through R studio it works fine but not through renjin. I can put more details about version I am using
INFO: Using "C:\Users\ukhan\AppData\Local\Temp\vfs_cache" as temporary files store.
Exception in thread "main" org.renjin.eval.EvalException: Could not resolve native method 'dplyr_combine_vars' in package 'dplyr'
at org.renjin.primitives.Native.findMethodByName(Native.java:574)
at org.renjin.primitives.Native.findMethod(Native.java:547)
at org.renjin.primitives.Native.redotCall(Native.java:363)
at org.renjin.primitives.R$primitive$$Call.apply(R$primitive$$Call.java:62)
at org.renjin.eval.Context.evaluateCall(Context.java:407)
at org.renjin.eval.Context.evaluate(Context.java:282)
at org.renjin.eval.Context.evaluate(Context.java:264)
at org.renjin.primitives.special.BeginFunction.apply(BeginFunction.java:38)
at org.renjin.eval.Context.evaluateCall(Context.java:407)
at org.renjin.eval.Context.evaluate(Context.java:282)
at org.renjin.eval.Context.evaluate(Context.java:264)
at org.renjin.eval.Context.evaluate(Context.java:198)
at org.renjin.sexp.Closure.doApply(Closure.java:98)
at org.renjin.eval.ClosureDispatcher.apply(ClosureDispatcher.java:80)
at org.renjin.eval.ClosureDispatcher.applyClosure(ClosureDispatcher.java:51)
at org.renjin.sexp.Closure.apply(Closure.java:83)
at org.renjin.eval.Context.evaluateCall(Context.java:407)
at org.renjin.eval.Context.evaluate(Context.java:282)
at org.renjin.eval.Context.evaluate(Context.java:264)
at org.renjin.primitives.special.AssignLeftFunction.assignLeft(AssignLeftFunction.java:57)
at org.renjin.primitives.special.AssignLeftFunction.apply(AssignLeftFunction.java:41)
at org.renjin.eval.Context.evaluateCall(Context.java:407)
at org.renjin.eval.Context.evaluate(Context.java:282)
at org.renjin.eval.Context.evaluate(Context.java:264)
at org.renjin.primitives.special.BeginFunction.apply(BeginFunction.java:38)
at org.renjin.eval.Context.evaluateCall(Context.java:407)
at org.renjin.eval.Context.evaluate(Context.java:282)
at org.renjin.eval.Context.evaluate(Context.java:264)
at org.renjin.eval.Context.evaluate(Context.java:198)
at org.renjin.sexp.Closure.doApply(Closure.java:98)
at org.renjin.eval.ClosureDispatcher.apply(ClosureDispatcher.java:80)
at
As your code has not been submitted I am writing based on 2 assumptions : 1) you are using Maven as your dependency management tool and 2) you have only included Renjin as a project dependency
In this case I would guess your POM file is missing the lines in the link below : http://packages.renjin.org/package/org.renjin.cran/dplyr/0.7.4
If, however, the dependency is already set I assume the error above happens because the Renjin implementation of this package (as explained in the link above) is still not fully functional. From what I've seen most of the packages that are highly dependent on C/C++ code take more time to be fully functional than pure R packages - one example is the Forecast package that has taken about 2 years to be somewhat usable.
Related
I am currently using Blazemeter to run load (performance) tests for a Java application, but I am getting this error. When I run it locally on my machine, this error does not occur.
Under 'scenario definition' my test starts off with a standard jmeter thread group. I did a bit of searching and realised that com.blazemeter.jmeter.threads.DynamicThread comes from the CustomThreadGroups plugin, so I have also uploaded the appropriate jar file plugin jmeter-plugins-casutg-2.9.jar file.
Screenshot of scenario definition
Screenshot of error
Would just like to check if there is some other jar file that I need to upload to solve this error, or if there is another method to solve this issue? Thank you.
Normally you should raise this form of questions to BlazeMeter Support as they should have better understanding of their infrastructure.
With regards to your question itself, most probably you're suffering from a form of a Jar Hell as:
BlazeMeter uses Taurus under the hood for kicking off JMeter tests which automatically downloads JMeter Plugins so it might be the case your plugins versions clash with the plugins at their end
You need to remove one of joda-time libraries as you cannot tell for sure which one will be loaded into classpath and in case of API inconsistency you can get unpredictable errors.
Am trying to excute the R code for Recommendation system on movie data set
when am running library(proxy) am getting error as there is no package called proxy
Am finding same error even after installing the package install.packages("proxy")
I got struck not going further.
My goal is to run a load test using 4 Azure servers as load generators and 1 Azure server to initiate the test and gather results. I had the distributed test running and I was getting good data. But today when I remote start the test 3 of the 4 load generators fail with all the http transactions erroring. The failed transactions log the following error:
Non HTTP response message: java.lang.ClassNotFoundException: org.apache.commons.logging.impl.Log4jFactory (Caused by java.lang.ClassNotFoundException: org.apache.commons.logging.impl.Log4jFactory)
I confirmed the presence of commons-logging-1.2.jar in the jmeter\lib folder on each machine.
To try to narrow down the issue I set up one Azure server to both initiate the load and run JMeter-server but this fails too. However, if I start the test from the JMeter UI on that same server the test runs OK. I think this rules out a problem in the script or a problem with the Azure machines talking to each other.
I also simplified my test plan down to where it only runs one simple http transaction and this still fails.
I've gone through all the basics: reinstalled jmeter, updated java to the latest version (1.8.0_111), updated the JAVA_HOME environment variable and backed out the most recent Microsoft Security update on the server. Any advice on how to pick this problem apart would be greatly appreciated.
I'm using JMeter 3.0r1743807 and Java 1.8
The Azure servers are running Windows Server 2008 R2
I did get a resolution to this problem. It turned out to be a conflict between some extraneous code in a jar file and a component of JMeter. It was “spooky” because something influenced the load order of referenced jar files and JMeter components.
I had included a jar file in my JMeter script using the “Add directory or jar to classpath” function in the Test Plan. This jar file has a piece of code I needed for my test along with many other components and one of those components, probably a similar logging function, conflicted with a logging function in JMeter. The problem was spooky; the test ran fine for months but started failing at the maximally inconvenient time. The problem was revealed by creating a very simple JMeter test that would load and run just fine. If I opened the simple test in JMeter then, without closing JMeter, opened my problem test, my problem test would not fail. If I reversed the order, opening the problem test followed by the simple test then the simple test would fail too. Given that the problem followed the order in which things loaded I started looking at the jar files and found my suspect.
When I built the script I left the jar file alone thinking that the functions I need might have dependencies to other pieces within the jar. Now that things are broken I need to find out if that is true and happily it is not. So, to fix the problem I changed the extension on my jar file to zip then edited it in 7-zip. I removed all the code except what I needed. I kept all the folders in the path to my needed code, I did this for two reasons; I did not have to update my code that called the functions and when I tried changing the path the functions did not work.
Next I changed the extension on the file back to jar and changed the reference in JMeter’s “Add directory or jar to classpath” function to point to the revised jar. I haven’t seen the failure since.
Many thanks to the folks who looked at this. I hope the resolution will help someone out.
Has anyone ever used Solrnet inside CLR Stored Procedures? I would really appreciate pointers to some good tutorials.
One problem I'm facing is that I can't find a way to include the SolrNet library as a reference to the VS (2008) Database (SQL Server) Project.
Update:
So it seems that when you have an SQL Server Project, and you want to add a reference to a library, it has to first exist in SQL Server itself, which makes sense. This is done by creating an assembly in SQL Server from the DLL itself with the following SQL:
CREATE ASSEMBLY SolrNet FROM 'C:\CLR_SP\SolrNet.dll'
WITH PERMISSION_SET = UNSAFE
(Note that UNSAFE might have some repercussions on the security of the database however it is ok for me for now)
However the SolrNet.dll requires other library dependencies such as Castle.Windsor.dll (which in itself requires System.Core.dll) and Ninject.dll. I found the required version of Castle.Windsor.dll (which is 2.5.1.0) and also System.Core.Dll (which was in the .Net folder of Windows), however I cannot find the required version of Ninject.dll (which should be 2.1.0.76). I have attempted to create assembly version 2.2 but, as expected, it did not do the job.
I searched for it on different repositories but could not find it. Does anyone know where I could find this version of DLL?
Update 2:
So after lots of searching over the net, I still didn't manage to find Ninject.dll v2.1.0.76. My next attempt was to use the next version of SolrNet (which is v0.4.0.2002). This version required Ninject.dll v2.2 which I had already found. So my current status is registering all other libraries in SQL Server which are dependencies of SolrNet.dll. I will leave this open to document my process just in case there will be someone having the same problem.
Update 3:
I have managed to register all required libraries (some of which I got from SolrNet source on GitHub). So now, SolrNet is registered as an assembly in SQL Server, and therefore I can reference it from the .NET SQL Server Project (for creating the CLR Stored Procedure). So I have written a very simple CLR SP which connects to SOLR and retrieves a piece of data. Code below:
[Microsoft.SqlServer.Server.SqlProcedure]
public static void PrintToday()
{
SqlPipe p;
p = SqlContext.Pipe;
p.Send("Helloooo");
// Open Solr instance
SolrNet.Startup.Init<ActiveProduct>("http://192.168.2.190:8983/solr");
// Get instance of ActiveProduct
ISolrOperations<ActiveProduct> operations = ActiveProduct.GetActiveProductSolrOperations();
// Prepare QueryOptions. This will be passed as a parameter into the query() method.
SolrNet.Commands.Parameters.QueryOptions qo = new QueryOptions();
qo.Start = 0;
qo.Rows = 20;
// Query Solr
SolrQueryResults<ActiveProduct> results = operations.Query(new SolrQueryByField("SearchDescription", "pants"), qo);
// Read results
String s = "Docs found: " + results.NumFound;
p.Send(s);
}
My next problem is that when I deploy and run the CLR SP, an error is popping stating that Solr is already registered in container. The exact output that I see in SQL Server Management Studio is the following:
Helloooo
Msg 6522, Level 16, State 1, Procedure PrintToday, Line 0
A .NET Framework error occurred during execution of user defined routine or aggregate 'PrintToday':
System.ApplicationException: Key 'SolrNet.Impl.SolrConnection.CLRStoredProcedures2.ActiveProduct.SolrNet.Impl.SolrConnection' already registered in container
System.ApplicationException:
at SolrNet.Utils.Container.Register(String key, Type serviceType, Converter`2 factory)
at SolrNet.Utils.Container.Register[T](String key, Converter`2 factory)
at SolrNet.Startup.Init[T](ISolrConnection connection)
at SolrNet.Startup.Init[T](String serverURL)
at StoredProcedures.PrintToday()
PrintToday is the name of the CLR StoredProcedure
CLRStoredProcedures2 is the name of the .NET SQL Server project and default namespace in VS 2008
ActiveProduct is the name of the document in Solr, and the cs class with Solr annotations
As can be seen from the output, the first Pipe.send("Hellooo") is doing its job therefore the SP works fine until there.
When I searched for the above error, I found out that it will show when one tries to register Solr instance twice in the same application. Now I don't see where I am registering the instance twice. Am I missing something here?
Note that the above cs function worked fine when executed in a cs console application developed on my machine. Another detail which might be important is that the SOLR Server is being hosted on my machine which is on the same network of my SQL Server 2005.
Update 4:
For starters, the error I mentioned above (in update 3) does not fire when the SP is executed the 1st time just after deployment (let's assume that the 1st time works for now since I have another error which I'm currently working on fixing), the error fires when the SP is executed again afterwards. So it seems that whatever SolrNet.Startup.Init<ActiveProduct>("http://192.168.2.190:8983/solr"); is doing (creating some sort of session that has to do with a container I think) when called from the SP it is not releasing the "session" therefore the 2nd time (and each time afterwards) the SP is executed, the error is fired. Is there a way to sort of stop the session or releasing from the container. What I can do as a workaround is to try - catch the SolrNet.Startup.Init part, however this is not clean.
Thanks.
I'll try to summarize the steps / requirements with explanations whenever possible:
For some reason SQL Server seems to trigger the "hidden" dependencies of the merged SolrNet. Usually you can just use the merged SolrNet (which includes all integration modules) and if you ignore the integration classes the dependencies won't trigger. But in this case the unmerged SolrNet is necessary.
SolrNet does HTTP requests to the Solr server, so the DLL must be registered with UNSAFE permissions in SQL-CLR.
SolrNet Initialization (Startup.Init) must happen only once per application, but you don't have a 'root' context in SQL-CLR to place this initialization. A workaround is to use a singleton or a Lazy type. SQL-CLR doesn't run .NET 4 yet, but you can backport the Lazy type or use FSharp.Core.dll's implementation (I blogged about this some time ago)
I am in a situation where my Felix OSGi container will not start properly after deploying groovy via:
obr:deploy "Groovy Scripting Languge"#1.7.3
Managed to deploy & got Groovy stuff running, until I did a restart on my OSGi container...then most of the bundles will not start. FWIW, I am pretty sure Groovy is not the cause even though there's a typo in its bundle name. :-)
After some troubleshooting, turning on Felix's wire logging (thank god!), i noticed this (among all the other failed bundles, similar cause):
2011-04-03 16:26:43,108 DEBUG [FelixStartLevel] felix.wire - Candidate permutation failed due to a conflict between imports; will try another if possible. (org.apache.felix.framework.resolver.ResolveException: Unable to resolve module org.apache.felix.http.bundle [36.0] because it is exposed to package 'org.osgi.framework' from org.apache.felix.framework [0] and com.springsource.org.aspectj.tools [47.0] via two dependency chains.
Chain 1:
org.apache.felix.http.bundle [36.0]
import: (&(package=org.osgi.framework)(version>=1.3.0))
|
export: package=org.osgi.framework
org.apache.felix.framework [0]
Chain 2:
org.apache.felix.http.bundle [36.0]
import: (&(package=org.osgi.service.log)(version>=1.3.0))
|
export: package=org.osgi.service.log; uses:=org.osgi.framework
osgi.cmpn [15.0]
import: (&(package=org.osgi.framework)(version>=1.5.0)(!(version>=2.0.0)))
|
export: package=org.osgi.framework
com.springsource.org.aspectj.tools [47.0])
Seems like both o.a.felix.framework and c.s.o.aspectj.tools are exporting o.osgi.framework.
I am able to get things running again by removing bundle id 47 (c.s.o.aspectj.tools), but yet to check if there's other implications. Feels wrong because I removed c.s.o.aspectj.tools but it was indicated as required (or optional) for Groovy by the OBR repository. In fact, it was installed via the obr:deploy command for Groovy.
Feels like c.s.o.aspectj.tools should not be exporting o.osgi.framework, but that's just a guess as i do not use aspectj tools stuff.
Question: What is the proper way to resolve such issues without resorting to educated guesses?
You are right, c.s.o.aspectj.tools should not be export org.osgi.framework, but apparently it does. To be precise, I checked version 1.6.8, and that has the following export statement:
org.osgi.framework;version="1.6.8.RELEASE"
Furthermore, it does not import org.osgi.framework. This is plain wrong, and I'd say it's worth a bugreport with the Spring team; if you export, you should usually import, and I can't think of a valid reason to tag osg.osgi.framework with a different version than it actually has.
How can you get around this for now? The problem with the two resolution chains can be resolved by wiring both http and cmpn to the same framework package; perhaps even a simple osgi:refresh in the shell could help you, since the declared version (1.6.8.RELEASE) is within the import ranges of both http and cmpn, by accident.
If you don't really need the aspectj stuff, I would leave it out.