In this Eclipse RCP application I am making, when a new launch is made, it checks some details of the already running launches which are retrieved by DebugPlugin.getDefault().getLaunchManager().getLaunches().
If it has certain details of its configuration the same as any of the running launches, it should stop. Currently so far, so good.
The Issue
What happens when I edit a LaunchConfiguration while launches of its type are still ongoing? Will that change the attributes of all the running launches' launch configurations? (I am talking about what is retrieved by: ILaunch.getLaunchConfiguration() )
EDIT: More details: in this case it is a hardware connection, and the hardware can only receive one ongoing concurrent connection. If the launch configuration changes, and we check all of the running launches' configurations, we will be unable to check if we're launching for the same hardware twice
When I call ILaunch.getLaunchConfiguration().getAttribute(String,String) it retrieves the new value that has been changed DURING the launch.
So, yes, if an ILaunchConfiguration during an active ILaunch has some attributes changed, if there is no deep copy made in the ILaunch, the changes will reflect on the running ILaunch. Ugh.
Related
So we are doing distributed testing of our web-app using JMeter. For that you need to have the jmeter-server.bat file running in background as it acts as sort of a listener. The problem arises when one of the slave machine out of 4 restarts due to the load and the test is effectively stuck right there as the master machine expects some output from the 4th machine. Currently the automation is done via ansible-playbooks which are called in Jenkins. There are more or less 15 tests that are downstream to one another. So even if one test is stuck, the time is wasted until someone check on the machines.
Things I've tried so far:
I've tried using the Windows Task Scheduler and kept the jmeter-server.bat to run without any user loggin in, but it starts the bat file in background which in-turn spawns all the child processes in the background as well i.e. starts Selenium Chrome in headless mode.
I've tried adding the jmeter-server.bat in startup and configuring the system to AutoLogon without any password to trigger a session which will call the startup file. But unfortunately the idea was scrapped by IT for being insecure.
Tried using the ansible playbook by using the win_command but it again gets stuck as the batch file never returns anything.
Created a service as well for the bat file, but again the child processes started in background.
The problem arises when one of the slave machine out of 4 restarts due to the load
Instead of trying to work around the issue I would rather recommend finding the root cause and fixing it.
Make sure to follow JMeter Best Practices
Configure Java to take heap dump on failure
Inspect Windows PerfMon and operating system/application logs
Check presence of .hprof files in the "bin" folder of your JMeter installation and see what do they say
In general using Selenium for conducting the load is not recommended, I would rather suggest using JMeter's HTTP Request samplers for that, given you properly configure JMeter to behave like a real browser from the system under test perspective there won't be any difference whether the load comes from HTTP Request samplers or from the real browser.
The same states documentation on the WebDriver Sampler
Note: It is NOT the intention of this project to replace the HTTP Samplers included in JMeter. Rather it is meant to compliment them by measuring the end user load time.
I am deciding between using a login item and launch agent.
In this respect I have few questions:
Is it possible for a non root user to quit a login item helper if it is launched with service management framework using SMLoginItemSetEnabled? Will the helper app be reloaded by launchD if it is killed by user or in some cases OS?
Why does apple not recommend presenting a UI with an app that can be executed via a LaunchAgent? Is there a problem if we present a minimal UI?
A login item as a helper application requires the main application to call SMLoginItemSetEnabled. This implies that the main app must be called at least once to enable the login item. This differentiates it from a launch agent which can be loaded as soon as the plist is installed on the system. Can we execute the helper login item irrespective if the user has opened the main app or not?
Any help would be appreciable
LaunchAgents that are configured using SMJobBless are intended to be non-gui services. They run without UI in the background, and don't run as the logged in user.
If you want a gui, you're going to have to use SMLoginItemSetEnabled, or manually install a user LaunchAgent via a .plist with the "LimitLoadToSessionType" = "Aqua" property.
Helpers launched by SMLoginItemSetEnabled run as the current user, so they can be terminated by that user. The process will get relaunched if launchd detects that the agent went away because of a signal or due to an abnormal termination. If it terminates due to a clean termination it will not be restarted until the next login of the user (by clean termination we mean terminating with an exit code of 0, which will not happen if the program is killed e.g. via the activity monitor. If the helper has an option to quit, and that option causes it to exit with a 0 return code, then it will not be restarted, which would be considered good form by the application.
It's a stylistic thing - a user cannot disable the agent without interacting with the command line which would be considered poor standing. There is no issue displaying a UI from a LaunchAgent. As long as it's registered with the appropriate keys, it will be launched in the user's gui login context which means that it can be fully interactive. I have several applications which act like that - TunnelBlick, 1Password (this is via the LaunchAgent plist) and they only put up a menu bar item on startup.
If you're just shipping an application - e.g. via the app store, then there's no way to have anything automatically start without some interaction by the user - you have to launch the main app to get the helper to be enabled. The helper login item can be launched manually without ever launching the main application; but it won't have the 'launch at startup' magic enabled. If you can register a LaunchAgent plist, then you can get the launch at startup & starting it up immediately behaviour.
For uninstallation, however, LaunchAgents require the removal of the .plist, and interacting with launchd to disable it, items registered with the Service Mangement framework will naturally vanish once the app is dragged to the trash.
IMHO, (bit soapboxy, bit opinionated) If you're shipping a standard app with a helper, then rely on first launch before configuring such things as helper start on login; primarily because it keeps the user in control. Autoinstalling startup items is one of my pet peeves with windows applications (so many status bar items...).
The docs for SMLoginItemSetEnabled state the login item will be "kept running", which seems to indicate it will be relaunched if it is killed:
The Boolean enabled state of the helper application. This value is effective only for the currently logged in user. If true, the helper application will be started immediately (and upon subsequent logins) and kept running. If false, the helper application will no longer be kept running.
https://developer.apple.com/documentation/servicemanagement/1501557-smloginitemsetenabled
I've deployed an application inside a corporate network and I want the update process to require less attention from users, similar to how Google Chrome install updates - in the background. I don't need to give the user a choice to update.
I've used the System.Deployment library to detect when new ClickOnce updates are available and install them automatically. I'm wondering if its necessary to restart the app after the update is complete. Currently I invoke Application.Restart() at the end of my update script.
But what if (to make the update process more transparent for the user) I performed a 'silent' async update and then displayed an icon prompting the user to restart the app to apply the changes? Would this make the app unstable in any way?
Furthermore, if I ran my custom InstallUpdate() process on a timer, say every 30 minutes, would ClickOnce be stable to continue to update for every new version that was released even thought the user has not restarted (nb: I'm expecting the updates to only apply once the user restarts the app)?
I would think it depends on what your application does at startup, and what it's doing when the update is installed and the application is restarted, and what the update contains. You could try running it and then attaching a debugger to it and see what it's doing and what impact it has.
For example, our application loads a lot of information into memory when it starts up. If the update included a change to one of the data structures, and the app didn't reload the data for some reason, it would cause a problem.
After a few years of doing it like this, we have found that it is possible to silently install updates this way. However there are a few issues to be aware of:
If the thread terminates prematurely during the Update() (eg: the user exits out of the app while the updating is in progress), the install will become corrupt and the next time the user loads the app, the ClickOnce normal deployment will fire off and re-install the app.
The user's desktop icons always redraw (flicker) after an update is installed.
Calling ApplicationDeployment.CurrentDeployment.CheckForUpdate() more than 65536 times causes a System.NullReferenceException Source.
An alternative is not to actually check for an update, I have found that this locks one of my dlls and prevented a form from loading, so use with care:
If ApplicationDeployment.CurrentDeployment.Update Then ' update app
console.writeline("update installed")
' code to inform user update was sucessfull and they need to restart
End If
If your ClickOnce project is 32bit, and you run it on an x64 platform, any file associations your app has will break after performing a manual ClickOnce update. See this MS support case for more details.
My iOS application, among its features, download files from a specific server. This downloading occurs entirely in the background, while the user is working on the app. When a download is complete, the resource associated with the file appears on the app screen.
My users report some misbehavior about missing resources that I could not reproduce. Some side information leads me to suspect that the problem is caused by the download of the resource's file to be aborted mid-way. Then the app has a partially downloaded file that never gets completed.
To confirm the hypothesis, to make sure any fix works, and to test for such random network vanishing under my feet, I would like to simulate the loss of the network on my test environment: the test server is web sharing on my development Mac, the test device is the iOS simulator running on the same Mac.
Is there a more convenient way to do that, than manually turning web sharing off on a breakpoint?
Depending on how you're downloading your file, one possible option would be to set the callback delegate to null halfway through the download. It would still download the data, but your application would simply stop receiving callbacks. Although, I don't know if that's how the application would function if it truly dropped the connection.
Another option would be to temporarily point the download request at some random file on an external web server, then halfway though just disconnect your computer from the internet. I've done that to test network connectivity issues and it usually works. The interesting problem in your case is that you're downloading from your own computer, so disconnecting won't help. This would just be so you can determine the order of callbacks within the application when this happens, (does it make any callbacks at all? In what order?) so that you can simulate that behavior when actually pointed to your test server.
Combine both options together, I guess, to get the best solution.
I have couple of machines on which I wish to schedule exceutions. I need to access these machines remotely for exceution. Whenever I start exceution from these machines and minimize the session my script fails. So just curious to know whether QTP scripts can be executed while keeping sessions minimized. If yes what changes needs to be made in script. Thanks.
When you minimize this window, the operating system switches the remote session to a GUI-less mode and does not display windows and controls. As a result, the tests are unable to interact with the tested application’s GUI as the GUI doesn’t actually exist in this case.
You need to change Registry keys on your computer (that is, the computer from which you connect to a remote QTP workstation). Here is a step-by-step description:
Close Remote Desktop sessions opened on your computer.
Click Start and select Run. In the Run dialog box, type regedit and press Enter. Registry Editor starts
Locate any of the following Registry keys:
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\
(if you want to change the RDC settings for your user account)
-- or --
HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client\
(if you want to change the RDC settings for all accounts)
Create a new DWORD value in this key named RemoteDesktop_SuppressWhenMinimized. Specify 2 as the value data.
That’s all. Now minimizing the Remote Desktop Connection window on your computer will not affect the remote computer’s GUI and the GUI will still be available to your automated GUI tests.
This was taken from: http://blog.smartbear.com/post/10-10-11/testcomplete-tip-running-tests-in-minimized-remote-desktop-windows/
The problem you're facing is that if you minimize your display the remove machine knows that it doesn't have a display and ignores any questions about control locations and requests to move the mouse. In some cases QTP runs tests using device replay which means that the test will fail.
To work around this you need to have the remote machine think that it still has someone attached to it. One way is (obviously) to not minimize or close the remote desktop session. Another way is to use a remote access program that doesn't inform the remote machine when it's minimized a free example of such program is VNC, if I remember correctly you can even close the VNC session (not just minimize it) and the test will still run successfully.