I am using JMeter 3.1.
While I am trying to run the script & click on run button on GUI mode. Script doesn't start/executed immediatly. It took 1 or 2 mins to start executing the script.
Please let me know if anyone faced such Issue earlier & how can I Overcome from this issue.
Related
I recently installed Pycharm on a fresh PC. Unfortunately something seems to be off with the installation. When I try to enter the debug console this isn't loading. E.g. for a very simple test case
def test_stable():
1 == 1
2 == 2 # breakpoint in this line
when I add a breakpoint in the last line, it is stopping the execution correctly, but I can't enter the console (i.e. the little wheels keep spinning):
What is wrong with my installation here? Is this a known issue?
Edit:
When clicking the "Show Python Prompt" button a console opens, but the console is not working, there is no output from it:
As I said above I believe this is connected to the strange behavior in the Debug Console tab.
Edit 2:
As recommended by #bad_coder I changed the test to
class Test:
def test_trivial(self):
test = 5
assert 1 == 1 # breakpoint on this line
I still can't use the debug console. I also just started up my old system and can now confirm that there when clicking on console I am directly getting to the console and not the situation of my first image (with the animated spinning wheels).
The button you're looking for is the Python-with-a-prompt button, which switches between the console and test progress.
If someone stumbles across the same issue, I believe the problem here was basically just that the Pycharm version was rather old. After downloading the current version everything works fine.
while working on application, code execution caught in infinite loop like-
console.log('print');
and now it is running and running.
To close Chrome I tried everything which I can but no result.
finally I restart my machine to solve it, that took several minutes
The same (infinite looping) happen again and again, I looked for that like -
http://ubuntuhandbook.org/index.php/2013/07/use-ctrl-alt-del-task-manager-ubuntu/
Advanced Scheduled Process/Task Manager - Linux
Killing a process in linux
finally I got solution, wanted to share with all to save the time-
Here is the solution-
1. Machine info-
Ubuntu 16.04 LTS.
Press windows Butoon-
type 'System Monitor', which will display one menu, click on that-
We will see list of all running process as-
At bottom, we have button as 'end process', click on that which will show one popUp as-
click Ok and that task enjoy!!!
Hope will work for you too!!
I have a test-script written in UFT. How can I let this test run in ALM every morning at the same time. Like every morning at 10 AM automated?
In ALM go to the Test Lab section in the Execution Flow tab, then right click a specific test and select Test Run Schedule.
Select the Time Dependency tab and fill it out.
Current Problem
I'm running automated selenium scripts every night. I just noticed that Firefox 38 is crashing and nothing is being listed in the firefox logs.
Clicking "Restart" firefox means that the tests run fine.
Is there anyway to debug and find what is going on with firefox crashing?
Firefox error report: https://crash-stats.mozilla.com/report/index/fdba810a-1980-45ea-b64b-0e8c62150604
Current Solution
Since "Restart Firefox" is already selected, using xdotool this button is clicked by sending the enter key. (note: set appropriate display, export DISPLAY=:1). I am executing a bash script from cron that contains the following section of code:
export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64
export PATH=$PATH:/usr/lib/jvm/java-7-openjdk-amd64/bin
export DISPLAY=":99"
java -jar /home/m/selenium-server-standalone-2.45.0.jar -htmlSuite "*firefox" "http://www.google.com" "selenium/2_Suite.html" "test_results/2_results.htm" &
sleep 5
xdotool key KP_Enter
wait
Update
Except for simulating the enter key to restart firefox and run the tests, I'v disabled all future updates on my headless automated testing VM using https://support.mozilla.org/en-US/questions/1003777 .
Selenium works on FireFox version 33.0 or below. Do not update your fire fox, selenium will not work on Firefox 36.0.
I had this issue with the .NET bindings. I never solved it, but I have a workaround.
I found that the issue didn't occur when instantiating the Selenium Firefox driver from an existing profile, so my workaround was to create a blank profile, launch Selenium's Firefox driver using a temporary copy of that profile; then at the conclusion of the test, delete the temporary copy.
In this way, you're still using a reasonably-fresh profile, and importantly the same profile, for every test.
The Selenium documentation has instructions on launching the Firefox driver with an existing profile.
I have an Applescript that runs fine on my Macbook Retina but fails on a Mac Mini.
Both are running MacOS 10.9.2.
After peeling the onion a bit I'm able to reproduce the problem with a one-line Applescript:
tell application "MidiPipe" to activate
On the Mini that throws the error:
An error of type -10810 has occurred.
On the Macbook the MidiPipe application opens.
MidiPipe works normally on the Mini when started from the Finder or from Launchpad.
Google provides no insight into this error.
Well, I found this: http://www.thexlab.com/faqs/error-10810.html and this: http://osxdaily.com/2010/02/09/mac-error-10810/ and this: http://forums.adobe.com/thread/1389805 . At least one of these suggests a RAM problem.
But just to make sure you've tried every weird variation, have you tried the following:
1) using a full path:
tell application "Full:Path:To:MidiPipe.app" --(probably "YourHDName:Applications:MidiPipe.app"?
2) using an actual tell block:
tell application "MidiPipe"--or full path
activate
end tell
3) using the Finder:
tell application "Finder" to open "Full:Path:To:MidiPipe.app"
4) using shell:
do shell script "open /Applications/MidiPipe.app"
?
After looking at the links in CRGreen's answer, it looks like this is likely being caused by the process table being full on the mini. This, in turn, prevents any new applications from opening. According to The X Lab:
Error -10810 is a Launch Services result code indicating an unknown error. One cause of this error is that the Mac® OS X process table is full. When the process table is full, new (not currently running) applications cannot be opened until another running application ends. Programming errors in third-party applications can fill-up the process table, leading to the -10810 error when opening an application.
I would start by restarting the mini to see if that clears the process table, allowing you to to start MidiPipe.
If that doesn't work, you should look at your Activity Monitor to see if there is a specific program filling up your process table.
Could be nothing more than another mysterious grieving crap from Apple.
Today I have faced this myself, first time after using four different Mac Minis as build servers for Continuous Integration of Mobile apps for about two years or so.
My Jenkins runs the osascript from the bash script to build the app.
A few days ago the office experienced the power outage and all Macs went down. After powering them back on I have got this error at osascript execution on one of my Macs.
I have tried just to re-build - with the same result.
First thing I stumbled upon was https://jacobsalmela.com/2014/08/04/infamous-execution-error-error-type-10810-occurred-10810/ , but none of them applied to me.
Then I googled more general 10810 issue occurrences and went through couple of questions here on SO.
Still no luck.
Next I reached to the server via SSH using PuTTY and tried telling Terminal to do the very basic script like
osascript -e 'tell application "Terminal"
activate
tell window 1
do script "counter=0; while true; do if [ \"$counter\" -gt \"10\" ]; then
break; else counter=$((counter + 1)); sleep 1; fi; done; exit;"
end tell
end tell'
This worked fine.
Then I tried to run the whole bash script that Jenkins used to execute. Everything went just perfect and the app was uploaded to HockeyApp as the result.
I came with the thought that the issue is that Jenkins runs it remotely on that Mac and finally I have tried just to re-build again and it magically worked fine this time.
No idea what it was, but since then I have performed three or more builds already and all of them were successful.
Note I haven't changed anything, and my script:
1) never used a full path;
2) always used an actual tell block;
3,4) nothing like that from the accepted answer was ever used.
So... Go away mysterious grieving crap! Go away! :)