I am having trouble with getting solr + jetty to work. I am following all
instructions to the letter from - http://wiki.apache.org/solr/SolrJetty. It works like a good. But when I restart jetty multiple times, after 3/4 such restarts it starts hanging. Admin pages just don't load and my app fails to acquire a connection with solr. I also created a work folder - /opt/solr/work. I am also setting tmpdir to a new path in /etc/default/jetty. I can confirm the tmpdir is set to the new path from admin dashboard, under args. So it's mostly not an issue with purging of tmp files by OS.
What might I be missing? Should I be rather looking at my code and see if I
am not committing correctly?
My configs - Solr 4.0.0 and jetty from example. Ubuntu 12.04 with Open JDK 7.
Edit:
I am running Jetty 8, bundled with Solr example on a Ubuntu 12.04 machine. When I use start.jar and server does not come up properly, while shutting down jetty throws ThreadPoolException - Failing to stop threads.
Here is a dump of stack trace:
2012-12-27 23:00:15.084:WARN:oejut.QueuedThreadPool:1 threads could not be stopped
2012-12-27 23:00:15.084:INFO:oejut.QueuedThreadPool:Couldn't stop Thread[qtp766488133-16,5,main]
2012-12-27 23:00:15.085:INFO:oejut.QueuedThreadPool: at sun.misc.Unsafe.park(Native Method)
2012-12-27 23:00:15.085:INFO:oejut.QueuedThreadPool: at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
2012-12-27 23:00:15.085:INFO:oejut.QueuedThreadPool: at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2081)
2012-12-27 23:00:15.085:INFO:oejut.QueuedThreadPool: at java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1425)
2012-12-27 23:00:15.086:INFO:oejut.QueuedThreadPool: at java.util.concurrent.Executors$DelegatedExecutorService.awaitTermination(Executors.java:636)
2012-12-27 23:00:15.086:INFO:oejut.QueuedThreadPool: at org.apache.solr.core.SolrCore.close(SolrCore.java:835)
2012-12-27 23:00:15.086:INFO:oejut.QueuedThreadPool: at org.apache.solr.handler.admin.CoreAdminHandler.getCoreStatus(CoreAdminHandler.java:865)
Since the Exception doesn't point out anything interesting, I would recommend that when it is hanging that you now take a thread dump of the whole server and analyze that for what is blocking correct startup. These can take a bit of trial and error to sort out what is what but should let you clue into what is holding things up. Note that the threads that start with qtp in the thread dump are rarely the issue, they are for processing requests so while there are likely a number of them there that is not an indication they are an issue. Common issues are things like database pooling that is 'await' on a pooled resource and things like that.
It seems the problem is with solrconfig.xml.
If I remove /browse request handler from solrconfig problem goes away. So not a solr or jetty issue, but most likely related to config of it.
Related
Following https://docs.hiro.so/smart-contracts/devnet I can't get the command clarinet integrate to work. I have installed Docker on my mac and am running version 0.28.0 of clarinet. Running command within 'my-react-app/clarinet' where all clarity related files live (contracts, settings, tests, and Clarinet.toml).
My guess is it could be an issue with Docker?
The issue was that I downloaded my Devnet.toml file from a repo that was configured incorrectly. The configuration I needed was:
[network]
name = "devnet"
I increased the CPU and Memory in Docker as well.
There is an issue when the command attempts to spin up the stacks explorer, but I was informed that there are several existing issues with the stacks explorer from clarinet integrate at the moment.
Depending on how the last devnet was terminated, you could have some containers running. This issue should be fixed in the next incoming release, meanwhile, you'd need to terminate this stale containers manually.
Apart from Ludo's suggestions, I'd also look into your Docker resources. The default CPU/memory allocation should allow you to get started with Clarinet, but just in case, you could alter it to see if that makes a difference. Here's my settings for your reference:
Alternatively, to tease things out, you could reuse one of the samples (eg: hirosystems/stacks-billboard) instead of running your project. See if the sample comes up as expected; if it does, there could be something missing in your project.
Camel sftp is unable to poll more than 2 levels deep when the java code runs on Linux, but it works fine on Windows.
For example, polling files from
sftp://user#domain:22/folder1/folder2?...
works on both Unix and Windows. But, when I use something like
sftp://user#domain:22/folder1/folder2/folder3?...,
the route is always started yet the route running on Unix doesn't get the files in folder 3.
Route: route22 started and consuming from:sftp://user#domain:22/folder1/folder2/folder3?...
The sftp is to the same Unix machine and the same paths are used.
I have tried with stepwise true and false, as well as with recursive.
Could anyone shed some light on this please?
The problem was caused by a quartz trigger (attached to the route) that became corrupted. That happend because of a camel bug that makes camel unable to reconcile triggers when running in cluster mode if they fail due to database reasons.
I recently came across a bug in Flink, reported (https://issues.apache.org/jira/browse/FLINK-8685) and found out that it has been reported and a pull request has been created (https://github.com/apache/flink/pull/5174).
Now I clone 1.5-SNAPSHOT, apply the patch and build Flink. Even though it builds (no matter patch is applied or not), when I run Flink (using start-cluster.sh), web dashboard doesn't work and command
tail log/flink-*-jobmanager-*.log returns "tail: cannot open 'log/flink-*-jobmanager-*.log' for reading: No such file or directory"
. I tested with a batch programs and surprisingly it returned results on terminal, but streaming programs and other things still don't work.
Any suggestions on this issue?
Thank you.
In case flink dashboard does not start change port in conf file and restart. Default port of flink could be occupied by other process in windows.
Also change log level for flink to debug.
I've setup an Ignite Server on a linux machine, that I'm configuring
and running over putty.
I wrote around 50.000 Key Value Pairs into the Heap.
But I´m not getting all the Data back?
Since I restarted the server, I'm getting this error:
bin/ignite.sh, WARN: Failed to resolve JMX host (JMX will be disabled): ignite-demo.novalocal
How can I resolve those problems?
You can set JMX_PORT=some port value in environment variables.
like,
JMX_PORT=8080
There are few solutions by gridgain experts like set IGNITE_JMX_PORT but it simply gives warning at start. See code in ignite.bat if you want to know more.
We just deployed selenium server 2.0b3 (upgraded from 1.0.3). It
looks like there are some fairly serious memory leaks - OutOfMemory
exception thrown during runs longer than 30 minutes long.
Is there any straight forward workaround for dealing with the memory leaks in the
2.0b3 selenium server?
I was hoping to get the 2.0b3 source, apply the assorted patches
submitted thus far and use this. However, when I pull this:
svn checkout http://selenium.googlecode.com/svn/tags/selenium-2.0-beta-3/
selenium-2.0-beta-3
and build with
./go clean release
The resulting binaries don't appear to have the
DefaultSelenium.class. Not sure what is going on here...
Alternately, I thought maybe we will just start working with the
latest release candidate. However, looks like the
DefaultSelenium.class is not here either.
Do I need to upgrade the client code to use WebDriver? I thought
things were suppose to be backwards compatible.
Suggestions?
for backwards compatibility you should use the WebdriverBackedSelenium like this:
FirefoxDriver driver = new FirefoxDriver(); //or any of the other drivertypes
Selenium selenium = new WebDriverBackedSelenium(driver, START_URL);
Specifically what kind of OutOfMemoryException is getting thrown? Heap? GC overhead limit? other?
I was getting "GC overhead limit exceeded" and sometimes also "out of heap space" as the message within the Exception (both 1.0.3 and 2.0.b3, using ruby selenium-client-1.2.18), and found your thread on the selenium-developers google group.[1] Have you followed along with the responses there?
Turning logging off for selenium-server (both -log AND -browserSideLog) stopped the OOMEs for me. I can wait till the next selenium-server release to get Kristian's patches.[2]
[1] http://groups.google.com/group/selenium-developers/browse_thread/thread/30d38475a16985a9/0db1af2456304f9f?hl=en&lnk=gst&q=outofmemory#0db1af2456304f9f
[2] http://code.google.com/p/selenium/source/detail?r=11872