During debugging an Application ,
Assume taht a line of execution is taking a lot of time , how can we know that Eclipse still in the process of Debugging ??
For example assume that the method client.submitOrder() shown below is taking 5 mins to get executed ??
Is there any Indication shown anywhere that eclipse is still running that method ??
public void test()
{
try
{
ServiceResponse response = client.submitOrder(request);
System.out.println("Doen")
}
catch(Exception e)
{
e.printStackTrace();
}
}
Assuming that you have started the application in Debug mode and if you are in the Debug View, the thread executing the method shows that the method it is in Stepping state.
I don't have a screenshot for this at the moment, but will try to upload one soon.
Related
I have an issue with JBoss EAP 7.1.0 GA. On one server (my DEV) this works like a charm while on the other (TEST environment) the Callable executed using executor.submit() does not seem to be started (I do not see that "This is call" message in log), but no exception or any other clue is given.
The question is - where should I look like / how should I debug this issue?
The calling code:
#Resource(name = "DefaultManagedExecutorService")
ManagedExecutorService executor;
try {
DownloadPlayers dp = new DownloadPlayers();
Future<Queue<PlayerForDownload>> f = executor.submit(dp);
Queue<PlayerForDownload> q = f.get();
L.info(q.size());
} catch (Exception e) {
L.error("EXCEPTION" + e.getMessage());
}
The class it calls:
public class DownloadPlayers implements Callable<Queue<PlayerForDownload>> {
// the constructor gets called, I'm sure as it writes to log
// the call is as simple as this
#Override
public Queue<PlayerForDownload> call() {
L.info("This is call()");
try {
return this.getPlayersForDownload();
} catch (WorkerException e) {
L.error(e);
return null;
}
}
}
As stated above, the code itself seems to be OK as it works in one server but does not work on the other. Both are
7.1.0GA standalone.
Any advice how to debug the ManagedExecutorService?
Thanks.
In this particular case the problem was that on the TEST environment it was only allowed to run two threads which we already running (by some completely different part of application I didn't realize). So the problem is solved now by setting the "Core threads" parameter in ManagerExecutorService to higher value, the tasks are running.
However the tricky part was that there was no obvious visible difference between the JBoss servers (I compared the standalone.xml configs...) just because the ManagerExecutorService in JBoss has some default (blank) values that actually depend on the system config (v-CPU cores in my case). So despite the config being the same, the "Core threads" seem to default to 2 on TEST and some higher (unknown to me) value on my DEV.
So never depend on default settings in ManagerExecutorService if comparing two environments.
I have also rewritten the logic, instead of using blocking Future.get() or checking for Future.isDone() in a loop a do Future.get() with timeout and in the exception handler I decide whether to keep waiting or fail.
I am exploring the usage of SWTWorkbenchBot to use in my automation of an eclipse-based project. However, something seems weird when trying to get the "Console" view.
SWTWorkbenchBot workbenchBot = new SWTWorkbenchBot();
String consoleTitle = "Console";
try {
workbenchBot.viewByTitle(consoleTitle).show();
System.out.println("Got the Console view");
} catch (Exception e) {
for (SWTBotView view : workbenchBot.views()) {
System.out.println(view.getTitle() + "\t" + v.getTitle().equals(consoleTitle));
}
}
From the above code, I assume one of the following 2 cases holds:
Either the code will exit with "Got the Console view" message printed
Or the message "Got the Console view" message NOT printed because the "Console" view was not found and an exception of type WidgetNotFoundException is thrown and the code inside the catch will be executed. The output should NOT contain the title "Console" or at least, next to all view titles, false should be printed.
Surprisingly, this is not happening. The message "Got the Console view" is NOT printed, yet if you look at the list of the view, you see that there exists a line Console true which means that the SWTWorkbenchBot could not get the console view using the method .viewByTitle() but he knows that exists by checking the .views() content.
The above code works fine for any view except for the Console view. Am I doing something wrong here? Thanks in advance.
If I look into my running Eclipse the View is called "Console (General)". You really should not rely on any names if you have the possibility to reference the view with an Id, check if the follwing snippet will work
workbenchBot.viewById("org.eclipse.ui.console.ConsoleView").show();
Just a sidenote: You should make ui Test code a bit more robust, UI tests tend to fail caused by timings, ui-states, overlapping windows, so fail early with a clear statement why the test failed.
[...]
SWTBotView view = workbenchBot.viewByTitle(consoleTitle);
assertNotNull("Console was not found", view);
try {
view.show()
} catch (Exception e) {
fail("Error occured while opening console")
}
[...]
new SWTWorkbenchBot().viewByPartName("Console").show();
should do the job.
What you see in the UI is the value returned by org.eclipse.ui.IWorkbenchPartReference.getPartName() but not the value returned by org.eclipse.ui.IWorkbenchPartReference.getTitle().
I'm running a simple Parse FindAsync method as show below (on Unity3d):
Task queryTask = query.FindAsync();
Debug.Log("Start");
Thread.Sleep(5000);
Debug.Log("Middle");
while (!queryTask.IsCompleted) {
Debug.Log("Waiting");
Thread.Sleep(1);
}
Debug.Log("Finished");
I'm running this method on a separate thread and I put a load circle on UI. My load freezes (+- 1 second) somewhere in the middle of the Thread.sleep method. It's look like when findAsync finishes the process it freezes the UI until it complete their job. Is there anything I could do?
Ps: This works perfectly on editor, the problem is on Android devices.
Ps2: I'm running parse 1.4.1
Ps3: I already tried the continueWith method, but the same problem happens.
IEnumerator RunSomeLongLastingTask () {
Task queryTask = query.FindAsync();
Debug.Log("Start");
//Thread.Sleep(5000); //Replace with below call
yield WaitForSeconds(5); //Try this
Debug.Log("Middle");
while (!queryTask.IsCompleted) {
Debug.Log("Waiting");
//Thread.Sleep(1);
yield WaitForSeconds(0.001f);
}
Debug.Log("Finished");
}
To call this function, use:
StartCoroutine(RunSomeLongLastingTask());
Making the thread sleep might not be a good idea, mainly because the number of threads available is different on each device.
Unity as a built-in scheduler that uses coroutines, so it is better to use it.
IEnumerator RunSomeLongLastingTask()
{
Task queryTask = query.FindAsync();
while (!queryTask.IsCompleted)
{
Debug.Log("Waiting"); // consider removing this log because it also impact performance
yield return null; // wait until next frame
}
}
Now, one possible issue is if your task take too much CPU, then the UI will still not be responsive. If possible, try to give a lower priority to this task.
i have a long-running non-UI Job with a number of sub-tasks. each sub-task updates caption for the Job's progress entry in the Progress View via IProgressMonitor.subTask(some-caption). the Job goes through three sub-tasks before it contributes to the UI in its fourth sub-task (via Display.syncExec() of course) by creating a new IEditorPart instance. the problem is that those initial three sub-tasks are never reflected in the Job's progress entry in the Progress View. in fact, the Job progress entry never actually appears in the Progress View until fourth sub-task. this, of course, creates a problem for a user who is left to wonder if anything is even happening. my guess is that once the Job starts, the vm thread "broker" (sorry, not well versed in this matter) never gets a chance to switch from a non-UI Job thread to the UI thread until the former actually makes a call to the latter via Display.syncExec(). my only solution at this point is to put Job thread to sleep for about half a second right after each sub-task kicks in, thereby allowing UI thread to take over long enough to update Progress View. and while this has worked most of the time, i still get instances here and there where the Porgress View still remains empty until fourth sub-task, leading me to believe that my solution is not of a robust kind. hence, i am looking for a robust one. thank you for your time!
EDIT: example code
Job job = new Job("multipleTasks") {
public IStatus run(IProgressMonitor monitor) {
monitor.beginTask("multiple tasks", IProgressMonitor.UNKNOWN);
monitor.subTask("task1");
monitor.worked(1);
try { Thread.sleep(1000); } catch (Exception e) { }
monitor.subTask("task2");
monitor.worked(1);
try { Thread.sleep(1000); } catch (Exception e) { }
monitor.subTask("task3");
monitor.worked(1);
try { Thread.sleep(1000); } catch (Exception e) { }
monitor.done();
return Status.OK_STATUS;
}
};
job.schedule();
I am invoking a compiler command but the compiler messages are not getting displayed in the Eclipse Console View consistently.
I have my launch() method implemented the same way as first code block of
this question; I have the command-line string setup which I use to call DebugPlugin.exec() method. However, unlike the the author of the question above, my output Eclipse console is very inconsistent. T
There is no activity in the console when I invoke the command and the console continues to display the "No console to display at this time." But after invoking the command numerous time and activating different consoles from the drop-down menu, the console occasionally does become active and message is displayed.
I am confused with how the eclipse is behaving and not sure how to resolve this issue. Any comment and/or recommendation would be appreciated.
Thanks!!
--
EDIT
To add some more info, running the external process using External Tools works fine. I add the compiler process c:\path\myprocess.exe in Locations field and the file to compile in the Arguments field within the External Tools Configuration window. When I run it, all the output is displayed fine. It just won't display when I run it programmatically through LaunchConfigurationDelegate class.
Maybe try bringing the console to front programmatically see if it helps:
* Bring the console to front.
*/
public static void showConsole() {
Display.getDefault().asyncExec(new Runnable() {
#Override
public void run() {
IWorkbenchWindow window = CUIPlugin.getActiveWorkbenchWindow();
if (window != null) {
IWorkbenchPage page = window.getActivePage();
if (page != null) {
IViewPart consoleView =
page.findView(IConsoleConstants.ID_CONSOLE_VIEW);
if (consoleView == null) {
IWorkbenchPart activePart = page.getActivePart();
try {
consoleView =
page.showView(IConsoleConstants.ID_CONSOLE_VIEW);
} catch (PartInitException pie) {
CUIPlugin.log(pie);
}
// restore focus stolen by the creation of the
// console
page.activate(activePart);
} else {
boolean bringToTop = true;
if (bringToTop) {
page.bringToTop(consoleView);
}
}
}
}
}
});
}
Finally got it to work. The main change I've made is having my MyLaunchConfigurationDelegate extend LaunchConfigurationDelegate instead of just implementing ILaunchConfigurationDelegate. When observed through the debugger, the launch() method went through similar code path as external process that was launched via External Tools when MyLaunchConfigurationDelegate extended LaunchConfigurationDelegate.
I guess it was lack of information on my part but I wasn't sure which part of the code was more important to share.
Another piece of code that was removed was:
IProcess dbgProcess = DebugPlugin.newProcess(launch, compilerProcess, "XVR Compiler", processAttributes);
...
launch.removeProcess(dbgProcess);
I've added it while attempting different approach in debugging this issue and it actually caused more issues by removing the debugProcess before it has chance to display output to the console.