[JBoss JIRA] (JBIDE-26802) Warn users of the server adapter if "show method result" pref is enabled
by André Dietisheim (Jira)
André Dietisheim created JBIDE-26802:
----------------------------------------
Summary: Warn users of the server adapter if "show method result" pref is enabled
Key: JBIDE-26802
URL: https://issues.jboss.org/browse/JBIDE-26802
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: openshift
Affects Versions: 4.13.0.AM1
Reporter: André Dietisheim
Attachments: show-method-result-after-step-operation.png
In JBIDE-26794 it turned out that when the preference value "show method result" is turned on, stepping over code that runs in OpenShift is slow to the point of being unusable.
The cause for this - the pref value mentioned above - is completely non-obvious. We thus should warn users and allow them to disable it if the detect it.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
5 years, 3 months
[JBoss JIRA] (JBIDE-26802) Warn users of the server adapter if "show method result" pref is enabled
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26802?page=com.atlassian.jira.plugi... ]
André Dietisheim updated JBIDE-26802:
-------------------------------------
Attachment: show-method-result-after-step-operation.png
> Warn users of the server adapter if "show method result" pref is enabled
> ------------------------------------------------------------------------
>
> Key: JBIDE-26802
> URL: https://issues.jboss.org/browse/JBIDE-26802
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.13.0.AM1
> Reporter: André Dietisheim
> Priority: Major
> Attachments: show-method-result-after-step-operation.png
>
>
> In JBIDE-26794 it turned out that when the preference value "show method result" is turned on, stepping over code that runs in OpenShift is slow to the point of being unusable.
> The cause for this - the pref value mentioned above - is completely non-obvious. We thus should warn users and allow them to disable it if the detect it.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
5 years, 3 months
[JBoss JIRA] (JBIDE-26794) OpenShift: Remote debugging is very slow
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26794?page=com.atlassian.jira.plugi... ]
André Dietisheim updated JBIDE-26794:
-------------------------------------
Sprint: devex #171 Aug 2019
> OpenShift: Remote debugging is very slow
> ----------------------------------------
>
> Key: JBIDE-26794
> URL: https://issues.jboss.org/browse/JBIDE-26794
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.11.0.Final
> Environment: Version: 12.11.0.GA
> Build id: GA-v20190329-0120-B4247
> Build date: 20190329-0120
> RHPDS
> Reporter: Josef Kopriva
> Assignee: André Dietisheim
> Priority: Major
> Labels: debugging
> Fix For: 4.13.0.AM1
>
> Attachments: disable-show-method-result.png
>
>
> From Email on devtools-team from [~jgammonred612]:
> {code:java}
> Hi Folks:
> Using this version of Code Ready Studio
> Version: 12.11.0.GA
> Build id: GA-v20190329-0120-B4247
> Build date: 20190329-0120
> I recently ran an Openshift Starter Workshop lab and witnessed a clear
> issue with Code Ready Studio and INtelliJ
> Workshop Starter Lab
> (http://starter-guides-labs.b9ad.pro-us-east-1.openshiftapps.com/workshop/...)
> Lab 19 has a remote debugging setup. The remote debugger in Code Ready
> connected very very slowly and would not step over or step out making
> using it as a debugger virtually impossible.
> One of the lab participants had IntelliJ and it connected immediately
> and worked just fine.
> Clearly, something is broken in CRS. Maybe someone would want to test
> this out and fix?
> You can find this lab on RHPDS.
> Just FYI to the PM's.
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
5 years, 3 months
[JBoss JIRA] (JBDS-4735) Central projects Wizard sometimes fails to open
by Jeff MAURY (Jira)
[ https://issues.jboss.org/browse/JBDS-4735?page=com.atlassian.jira.plugin.... ]
Jeff MAURY updated JBDS-4735:
-----------------------------
Sprint: devex #159 December 2018, devex #161 January 2019, devex #162 February 2019, devex #163 March 2019, devex #164 April 2019, devex #165 April 2019, devex #166 May 2019, devex #167 June 2019, devex #168 June 2019, devex #169 July 2019, devex #170 Aug 2019, devex #171 Aug 2019 (was: devex #159 December 2018, devex #161 January 2019, devex #162 February 2019, devex #163 March 2019, devex #164 April 2019, devex #165 April 2019, devex #166 May 2019, devex #167 June 2019, devex #168 June 2019, devex #169 July 2019, devex #170 Aug 2019)
> Central projects Wizard sometimes fails to open
> -----------------------------------------------
>
> Key: JBDS-4735
> URL: https://issues.jboss.org/browse/JBDS-4735
> Project: Red Hat CodeReady Studio (devstudio)
> Issue Type: Bug
> Components: central
> Affects Versions: 12.9.0.GA
> Environment: manually Fedora 28, automation
> Reporter: Vojtech Prusa
> Assignee: Jeff MAURY
> Priority: Major
> Fix For: 12.13.0.AM1
>
> Attachments: central.tar.gz, image-2018-10-17-09-24-31-555.png, screenshot-1.png
>
>
> There is "openInIDE" used in 3 places in "main.min.js" in central source code*. When the central reloads and works normally, "openInIDE" is a function (probably defined in Java code or somewhere out of the "main.min.js" file) with following implementation:
> function openInIDE() {
> var result = callJava(1, '9aee3b4a3f3b40ed26f47d66375b25e3', Array.prototype.slice.call(arguments));
> if (typeof result == 'string' && result.indexOf('org.eclipse.swt.browser.error') == 0) {
> var error = new Error(result.substring(29));
> throw error;
> }
> return result;
> }
> After the issue appears, "typedef openInIDE" is undefined, which causes probably the issues.
> *Additional information to the 3 places, where "openInIDE" appears - it appears in 2 functions:
> - registerButtonClicks() - here is the "openInIDE" needed for loading and displaying the central correctly
> - delegateToIDE(a, b) - here is the "openInIDE" needed for opening the wizard to the quickstart
> OLDER DESCRIPTION (does not describes the issue enough, but I decided to keep it for more details about the issue):
> ----------------------------------------------------------------------------------------------------------------------
> Sometimes central examples wizards fail to load and modal dialog is shown instead (screen attached).
> Nothing in Error log view.
> Restarting devstudio solves the issue.
> Adding screen and central tar of:
> devstudio-12.9.0.GA-v20180928-1629-B3448/workspaces/workspace/.metadata/.plugins/org.jboss.tools.central/central
> Addition info:
> Considering that central itests fails for this sometimes fresh installation without restart may cause this. Although it happen again after running devstudio for some time and restarting Central view.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
5 years, 3 months
[JBoss JIRA] (ERT-748) [GTK3] Shell dispose slowdown [EBZ#549644]
by Jeff MAURY (Jira)
[ https://issues.jboss.org/browse/ERT-748?page=com.atlassian.jira.plugin.sy... ]
Jeff MAURY updated ERT-748:
---------------------------
Sprint: devex #170 Aug 2019, devex #171 Aug 2019 (was: devex #170 Aug 2019)
> [GTK3] Shell dispose slowdown [EBZ#549644]
> ------------------------------------------
>
> Key: ERT-748
> URL: https://issues.jboss.org/browse/ERT-748
> Project: Eclipse Release Train
> Issue Type: Task
> Components: Platform
> Reporter: Friendly Jira Robot
> Assignee: Eric Williams
> Priority: Major
> Labels: 4.13_M3, SWT, bzira
>
> Created attachment 279428
> Snippet
> GTK version: 3.22.30
> SWT version: 4928
> With the fix from Bug 547227, SWTBot unit tests are sometimes able to complete on GTK3 successfully. However sometimes the build still fails with Tycho return code 137.
> Running a loop to continuously create and dispose a ControlExample in a Shell shows that the dispose gets progressively slower.
> Doing this with the SWTBot ControlExample (a modified copy) crashes the build after less than 700 iterations, with the dispose time starting around 300 ms and ending around 2,300 ms:
> https://ci.eclipse.org/swtbot/job/swtbot-gerrit/1071/console
> By comparison, the same code with GTK2 on 2018-09 target platform crashes after more than 13,000 iterations, but the dispose time is stable around 50 ms throughout:
> https://ci.eclipse.org/swtbot/job/swtbot-gerrit/1070/console
> The slowdown problem can be reproduced locally using the original ControlExample from SWT. See the included snippet.
> Profiling this snippet shows that the majority of the time is spent in GTK._gtk_widget_destroy[native] for the Shell itself.
> main 100,341 ms (100%) 100,341 ms (100%)
> +SnippetControlExampleDispose.main () 100,341 ms (100%) 100,341 ms (100%)
> +org.eclipse.swt.widgets.Shell.dispose () 64,397 ms (64.2%) 64,397 ms (64.2%)
> +org.eclipse.swt.widgets.Widget.dispose () 64,397 ms (64.2%) 64,397 ms (64.2%)
> +org.eclipse.swt.widgets.Control.release () 64,397 ms (64.2%) 64,397 ms (64.2%)
> +org.eclipse.swt.widgets.Widget.release () 64,397 ms (64.2%) 64,397 ms (64.2%)
> +org.eclipse.swt.widgets.Widget.destroyWidget () 61,443 ms (61.2%) 61,443 ms (61.2%)
> +org.eclipse.swt.internal.gtk.GTK.gtk_widget_destroy () 61,443 ms (61.2%) 61,443 ms (61.2%)
> +org.eclipse.swt.internal.gtk.GTK._gtk_widget_destroy[native] () 61,443 ms (61.2%) 61,443 ms (61.2%)
> +org.eclipse.swt.widgets.Shell.releaseChildren () 2,954 ms (2.9%) 2,954 ms (2.9%)
> +org.eclipse.swt.examples.controlexample.ControlExample.<init> () 35,103 ms (35%) 35,103 ms (35%)
> +org.eclipse.swt.widgets.Shell.<init> () 840 ms (0.8%) 840 ms (0.8%)
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
5 years, 3 months