I know the current development is in Pyro5 but I am using another package (Pyomo) that is still dependent on Pyro 4. For some reason I am not being able to terminate the name server while submitting a slurm request. I have a nameserver as one process, dispatch server as another process, and there are a few more processes for solver server. I can get the result and everything is working fine for me. However, it is annoying that all of the solver servers and dispatch server gets terminated at the end but nameserver does not. This is okay if I run it via terminal where I can force the nameserver shutdown using Ctrl + C but how to enforce this when submitting a job request via slurm?
Dispatch server can be terminated using: proxy.shutdown() where proxy = Pyro.proxy("uri of dispatch server") followed by proxy._pyroRelease(). However, the same process does not work for nameserver and the job halts at that point until I cancel the job using scancel. This is hindering me from submitted multiple job arrays as the nameserver is not terminated without manual interruption.
Is there a way to handle this?
I tried the following:
ns = Pyro.locateNS()
uri = ns.lookup("Pyro.NameServer")
proxy = Pyro.Proxy(uri)
proxy.shutdown() # also tried proxy._shutdown() and proxy._pyroshutdown()
proxy._pyroRelease()
But the error pops up as I figured out proxy does not have any of those methods to shutdown a server.
Related
I need to perform a load test against a pgbouncer. All the clients perform an SSH Tunnel before enstablishing a database connection to the database (through the pgbouncer). It's something like this:
sshpass -p 'MY_PSW' ssh -o StrictHostKeyChecking=no -N -L LOCAL_PORT:127.0.0.1:63666 PGBOUNCER_USER#PGBOUNCER_ADDRESS -p PORT >/dev/null 2>&1 &
My Jmeter project has three thread Groups at the moment:
SetUp Thread Group: In which I make a connection to a different database to select a random username and schema
Query Thread Group: In which I perform the JDBC connection using the previous user (which became a property using props.put("schema", vars.get("schema_1")); into the BeanShell Assertion) and the queries
TearDown Thread Group: In which I close the ssh Tunnel.
Now every first time I run the test from the GUI, the data select (JDBC request) into the Query Thread Group gives me an error:
Cannot create PoolableConnectionFactory (FATAL: "trust" authentication failed)
After that, if I run the test again, everything works. I checked the content of the variables and properties with a Debug sampler and everything is correct.
The main problem starts when I run the test without the GUI. It always fails because of that error.
I actually don't like the fact that I have to enstablish the SSH tunnel running the command with an OS Process Sampler, but I can't find any better solution. The SSH tunnel is a part of the test, I don't need that for the master/slave configuration of JMeter.
I would appreciate a lot for a solution or a suggestion to make this work. Thanks.
If you're using the command in the OS Process Sampler it's being run in the background therefore my expectation is that the OS Process Sampler returns the SampleResult immediately and the tunnel is not up yet.
Then when the "Query Thread Group" starts as per JMeter Test Elements execution order JDBC Connection Configuration tries to establish the connection using local port which is not fully established. The fact that the issue is reproducible in non-GUI mode might be the confirmation for my guess as JMeter works much faster in non-GUI as it doesn't need to waste time and resources for GUI refreshing and propagating sample results to listeners.
My expectation is that if you add i.e. Flow Control Action sampler to the setUp Thread Group and configure it to "sleep" for a couple of seconds it should resolve your issue. If it doesn't - try increasing JMeter logging verbosity for the JDBC Test Elements by adding the next line to log4j2.xml file
<Logger name="org.apache.jmeter.protocol.jdbc" level="debug" />
and compare the entries for "successful" and "failed" executions in the jmeter.log file.
Ok, I managed to find the solution. Thank to Dmitri T Answer, I could track the problem, which was about the property not being properly set.
I was using the BeanShell Assertion to set the property after the result of the JDBC request in the setUp Thread Group. Apparently, the BeanShell Assertion is executed at the end of the entire run, so the property where being set at the end. During the first execution, the property is empty.
I used the Beanshell Sampler instead and now it works.
I've been using Mongo for a while now, and I never had any kind of errors. But today, I tried running the mongo command in my terminal and I got the following error:
Error connecting to 127.0.0.1:27017 :: caused by :: No connection could be made because the target machine actively refused it. :
I have my PATH variable for Mongo properly configured in my environment variables as follows:
C:\Program Files\MongoDB\Server\4.4\bin
so I doubt that is the issue. I remember going through my task manager yesterday and I accidentally terminated a program running in the background related to Mongo, but I can't seem to remember exactly what it was called, and I really think that that's the root of my problem, because before having terminated that Mongo program in my task manager I had never ran across this connection problem before.
By terminating a program in the background, I'm going to assume you didn't just end process, otherwise a simple computer restart would fix your issue. And in some cases, that same program would've relaunched when you launched MongoDB. But if you disabled a service and need to find which service needs to be running to be able to connect to your MongDB then I would suggest going through your Windows Services list and seeing which ones you disabled and looking one relating to TCP or SNMP.
This is because MongoDB Wire Protocol is a simple socket-based, request-response style protocol. You communicate with the database server through a regular TCP/IP socket and since you can't remember which one you "terminated" and any number of services related to networking can cause a dependency to be absent, I can't be more specific in helping you determine which one you need to turn back on and you'll have to do it through trial and error but I can at least offer you some guidance, hopefully.
Specifically you can either
Run system configuration using
msconfig
In a run box, navigating to the Services tab, order the list by Date Disabled to find the service that was disabled which correlates with when you when snooping through task manager, or
Run Task manager and navigate to the Services Tab, then Open Services, and order them by Status or by Name, and look for any service that includes TCP/IP, COM+, Port direction, etc. to see which one is disabled and change the configuration from anything but Disabled and then stat it manually and run MongDB again.
It's about as specific as I can get without knowing anything more than you terminated some program running in the background but I hope it helps.
The background process (daemon) for MongoDB is called 'mongod'. It's an executable in your bin directory inside your mongodb installation. You can just execute it in the terminal.
Run:
C:\Program Files\MongoDB\Server\4.4\bin\mongod.exe
When halting service in Process Admin console - using Halt service button - I get following message after a while:
Halting of the Service timed out. Most probably, the Process Server failed to halt the Service within short time period.
From what I can see, it happens only when said service has few (say in tenths)steps, when it has more (hundreds) steps, it works well.
Can somebody see cause of this and tell me what to do? Thanks.
If we fail to halt a hung or long running (infinite loop) service within a short duration, process admin console does not allow to halt it.
This is the default behavior of how halt will work. Only way to restart the server to reinstate the BPM env.
I have a machine setup to run automated tests. I have some software, including Fiddler running as scheduled tasks on start up without user required to log in.
But tests fail, since traffic is not going through Fiddler. When I log in to that machine, I can see in Task Manager Fiddler running as background process.
I've tried starting the task as my user and as System.
Trying to figure out how to have traffic go through that fiddler instance. Thank you!
4/27 Update
So it had to do with the user that scheduled task was set to run from. After playing with it, I figured my user was set incorrectly. Now it looks like traffic goes through Fiddler, as tests are passing. But nowhere I can see the traffic. Fiddler is running as background process and I can't find the folder where it stores temp files. I have also tried setting autosave to a file every 5 minutes. And while it works when I run fiddler in UI, no sessions are saved when it runs as background process.
I've got this project running under mod_perl shows some information on a host. On this page is a text box with a dropdown that allows users to ping/nslookup/traceroute the host. The output is shown in the text box like a tail -f.
It works great under CGI. When the user requests a ping it would make an AJAX call to the server, where it essentially starts the ping with the output going to a temp file. Then subsequent ajax calls would 'tail' the file so that the output was updated until the ping finished. Once the job finished, the temp file would be removed.
However, under mod_perl no matter what I do I can's stop it from creating zombie processes. I've tried everything, double forking, using IPC::Run etc. In the end, system calls are not encouraged under mod_perl.
So my question is, maybe there's a better way to do this? Is there a CPAN module available for creating command line jobs and tailing output that will work under mod_perl? I'm just looking for some suggestions.
I know I could probably create some sort of 'job' daemon that I signal with details and get updates from. It would run the commands and keep track of their status etc. But is there a simpler way?
Thanks in advance.
I had a short timeframe on this one and had no luck with CPAN, so I'll provide my solution here (I probably re-invented the wheel). I had to get something done right away.
I'll use ping in this example.
When ping is requested by the user, the AJAX script creates a record in a database with the details of the ping (host, interval, count etc.). The record has an auto-incrementing ID field. It then sends a SIGHUP to to a job daemon, which is just a daemonised perl script.
This job daemon receives the SIGHUP, looks for new jobs in the database and processes each one. When it gets a new job, it forks, writes the PID and 'running' status to the DB record, opens up stdout/stderr files based on the unique job ID and uses IPC::Run to direct STDOUT/STDERR to these files.
The job daemon keeps track of the forked jobs, killing them if they run too long etc.
To tail the output, the AJAX script send back the job ID to the browser. Then on a Javascript timer, the AJAX script is called which basically checks the status of the job via the database record and tails the files.
When the ping finishes, the job daemon sets the record status to 'done'. The AJAX script checks for this on it's regular status checks.
One of the reasons I did it this way is that the AJAX script and the job daemon talk through and authenticated means (the DB).