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.
Related
I have a storage cluster that has been churning along for a few years. It's based around a pretty stock Centos 7.6 setup, using beegfs.
In an effort to increase throughput I've decided to do a test-upgrade of the network, from 10gig to 40gig. However, it would appear that the necessary drivers for this 40gig card conflicts with beegfs in terms of kernel modules. Now that I have the 40gig network running successfully, beegfs-client fails to start:
modprobe: ERROR: could not insert 'beegfs': Unknown symbol in module, or unknown parameter (see dmesg)
How do I make these two get along?
The cards I've installed are all ConnectX-3 FDR Infiniband (both ports configured to Ethernet, though). The driver I installed is MLNX_OFED_LINUX-5.0-2.1.8.0-rhel7.6-x86_64. Uninstalling the driver did not resolve the issue, but the 40gig network is still working. It was only needed for recorfiguring the ports to Ethernet instead of Infiniband.
Update: From the looks of it, I will need to add infiniband support to the beegfs-client-autobuild.conf. Not entirely sure where to find the source that I need to reference.
Turns out the answer was simpler than anticipated: upgrade to the newest version of beegfs-client. The newer version includes infiniband compatibility by default. No rebuild needed.
After an upgrade and a reboot, the cluster behaved as intended again, with the Mellanox 40Gb/s cards operating.
Facing error 1067 for when trying to deliver into integration stream.
On investigation, it was found that albd service isn't coming up.
Have checked out the doc regarding this error code on IBM, none of the resolutions have helped.
What could be the possible cause?
Errors faced :
cleartool: Error: Unable to contact albd_server on host 'hostname'
albd_contact call failed: RPC: Unable to receive; errno = [WINSOCK]
Connection reset by peer
I have seen this when the ClearCase license server itself was down.
But if this is not the case here, check the Windows Event viewer for more clues on that particular instance, for example right after attempting to start the albd service.
I don't know if that is the local host or a remote one. If the local host, this technote may help: https://www.ibm.com/support/pages/troubleshooting-albd-startup-failures-microsoft-windows
If a remote host, that technote may still apply, but you may also be dealing with a network issue. Some questions may help clarify the issue in that case:
Does the issue impact multiple clients?
When did this start?
Are there any functions that work from this host? ("Cleartool quit" command, cleartool lsvob, etc.)
We've just updated Nagios from 3.5.x to the current version (4.0.7) and subsequently added a new host for monitoring.
The new host shows as 'Down' in Nagios, and this seems to be related to the fact that pnp4nagios is not logging performance data (the individual checks for users, http etc are all find).
Initially there was an error that the directory
/usr/local/pnp4nagios/var/perfdata/newhost.com
that contains the xml setup and rrd files for the new host was missing), so I manually created this directory, but now it complains that the files are missing.
Does anyone know the appropriate steps to overcome this issue?
Thanks,
Toby
PS I'd tag this 'pnp4nagios', but that tag doesn't exist and I can't create them
UPDATE
It's possible that pnp4nagios is a red herring/symptom. Looking more closely I realise that Nagios actually believes the host is down, even though all services are up. The host status information is '(Host check timed out after 30.01 seconds)'...does this make any more sense?
It's indeed very unlikely that pnp4nagios has something to do with your host being down. pnp actually exports output and performance data to feed the rrd database and xml files (via npcd module or evenhandler command).
The fact that nagios reports the host check timed out after 30 sec means that :
- you have a problem with your host check command, please double-check the syntax
- this check command times out after a certain timelapse (most likely defined in nagios.conf) because the plugin was still running.
I'd recommend running this command from the server's prompt. You want to do something like :
/path/to/libexec/check_command -H ipaddress -args
For example:
/usr/local/libexec/nagios/check_ping -H 192.168.1.1 -w 200,40% -c 500,80% -timeout 120
See if something might be hanging. Having the output would be helpful.
Once your host check returns correct output and performance data to nagios, pnp will hopefuly do the rest.
In the unlikely event it helps anyone, pnp4nagios was indeed a red herring. The problem was that ping wasn't enabled for the host being checked, and this is the test for whether a host is up or not. Hence this was failing, despite other services being reported as working.
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.
I've got the following settings in my postgres conf:
log_destination = 'stderr'
redirect_stderr = on
log_directory = '/tmp/psqlog'
log_statement = 'all'
And yet no logs are logged. What am I missing here? There is reference on the internet to a variable called "logging_collector", but when I try and set that, postgres dies on startup with a FATAL: unknown variable.
This is on MacOS 10.4.
Ta.
I believe that you need to change log_destination to "syslog" or a specific directory. Output that goes to stderr will just get tossed out. Here's the link to the doc page, but I'll see if I can find an example postgresql.conf somewhere http://www.postgresql.org/docs/8.2/static/runtime-config-logging.html
This mailing list entry provides some info on setting up logging with syslog http://archives.postgresql.org/pgsql-admin/2004-03/msg00381.php
Also, if you're building postgres from source, you might have better luck using a os x package from Fink or MacPorts. Doing all of the configuration yourself can be tricky for beginners, but the packages normally give you a good base to work from.