[JBoss JIRA] (JBIDE-16379) Using symbolic links in the workspace path causes an infinite loop for m2e builder
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16379?page=com.atlassian.jira.plugi... ]
Snjezana Peco commented on JBIDE-16379:
---------------------------------------
I have tested importing the wildfly distribution using Eclipse 4.4.1/JBT 4.2.0.CR1
Test case 1:
When excluding all the m2e/JBT Maven configurators, suspending all the WTP validators and disabling the "Auto Share EGit" projects (unchecking all the three checkboxes in Window>Preferences>Team>Git>Projects), importing the wildfly distribution takes 5-6 minutes. Since that operation creates and compiles 50+ Eclipse projects, I think, it can't be significantly improved.
Cleaning/rebuilding all the projects lasts about 3 minutes.
Test case 2:
When including the m2e/JBT maven configurators and the default WTP validators, disabling the "Auto Share EGit" projects, importing the wildfly distribution lasts less than 15 minutes.
Cleaning/rebuilding all the projects takes about 6-8 minutes.
Test case 3:
If all the validators and the m2e/JBT configurators are included and the "Auto Share EGit" projects enabled, importing the wildfly distribution takes less than 20 minutes.
EGit doesn't significantly affect cleaning/rebuilding projects.
In these cases, Eclipse requires less than 1GB Java heap space.
As I can see, there is noticeable improvements in Eclipse 4.4.1/JBT 4.2.0
I encounter issues in the test case 3 when there are more .git directories in the hierarchy and there is .git in a directory with a lot of entries. On Linux, such a situation can happen when using symbolic links.
If EGit finds the .git directory, it will scan the complete hierarchy which can slow down Eclipse/JBDS/JBT or even lock it.
In my opinion, we should advice users to disable the "Auto Share EGit" projects and maybe even, to disable this property in JBDS using plugin_customization.ini.
> Using symbolic links in the workspace path causes an infinite loop for m2e builder
> ----------------------------------------------------------------------------------
>
> Key: JBIDE-16379
> URL: https://issues.jboss.org/browse/JBIDE-16379
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: maven, upstream
> Affects Versions: 4.2.0.Alpha1
> Reporter: Snjezana Peco
> Assignee: Snjezana Peco
> Fix For: 4.3.x
>
>
> See JBIDE-16286
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (JBIDE-16379) Using symbolic links in the workspace path causes an infinite loop for m2e builder
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16379?page=com.atlassian.jira.plugi... ]
Snjezana Peco commented on JBIDE-16379:
---------------------------------------
I have tested importing the wildfly distribution using Eclipse 4.4.1/JBT 4.2.0.CR1
Test case 1:
When excluding all the m2e/JBT Maven configurators, suspending all the WTP validators and disabling the "Auto Share EGit" projects (unchecking all the three checkboxes in Window>Preferences>Team>Git>Projects), importing the wildfly distribution takes 5-6 minutes. Since that operation creates and compiles 50+ Eclipse projects, I think, it can't be significantly improved.
Cleaning/rebuilding all the projects lasts about 3 minutes.
Test case 2:
When including the m2e/JBT maven configurators and the default WTP validators, disabling the "Auto Share EGit" projects, importing the wildfly distribution lasts less than 15 minutes.
Cleaning/rebuilding all the projects takes about 6-8 minutes.
Test case 3:
If all the validators and the m2e/JBT configurators are included and the "Auto Share EGit" projects enabled, importing the wildfly distribution takes less than 20 minutes.
EGit doesn't significantly affect cleaning/rebuilding projects.
In these cases, Eclipse requires less than 1GB Java heap space.
As I can see, there is noticeable improvements in Eclipse 4.4.1/JBT 4.2.0
I encounter issues in the test case 3 when there are more .git directories in the hierarchy and there is .git in a directory with a lot of entries. On Linux, such a situation can happen when using symbolic links.
If EGit finds the .git directory, it will scan the complete hierarchy which can slow down Eclipse/JBDS/JBT or even lock it.
In my opinion, we should advice users to disable the "Auto Share EGit" projects and maybe even, to disable this property in JBDS using plugin_customization.ini.
> Using symbolic links in the workspace path causes an infinite loop for m2e builder
> ----------------------------------------------------------------------------------
>
> Key: JBIDE-16379
> URL: https://issues.jboss.org/browse/JBIDE-16379
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: maven, upstream
> Affects Versions: 4.2.0.Alpha1
> Reporter: Snjezana Peco
> Assignee: Snjezana Peco
> Fix For: 4.3.x
>
>
> See JBIDE-16286
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (JBIDE-16379) Using symbolic links in the workspace path causes an infinite loop for m2e builder
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16379?page=com.atlassian.jira.plugi... ]
Snjezana Peco updated JBIDE-16379:
----------------------------------
Comment: was deleted
(was: I have tested importing the wildfly distribution using Eclipse 4.4.1/JBT 4.2.0.CR1
Test case 1:
When excluding all the m2e/JBT Maven configurators, suspending all the WTP validators and disabling the "Auto Share EGit" projects (unchecking all the three checkboxes in Window>Preferences>Team>Git>Projects), importing the wildfly distribution takes 5-6 minutes. Since that operation creates and compiles 50+ Eclipse projects, I think, it can't be significantly improved.
Cleaning/rebuilding all the projects lasts about 3 minutes.
Test case 2:
When including the m2e/JBT maven configurators and the default WTP validators, disabling the "Auto Share EGit" projects, importing the wildfly distribution lasts less than 15 minutes.
Cleaning/rebuilding all the projects takes about 6-8 minutes.
Test case 3:
If all the validators and the m2e/JBT configurators are included and the "Auto Share EGit" projects enabled, importing the wildfly distribution takes less than 20 minutes.
EGit doesn't significantly affect cleaning/rebuilding projects.
In these cases, Eclipse requires less than 1GB Java heap space.
As I can see, there is noticeable improvements in Eclipse 4.4.1/JBT 4.2.0
I encounter issues in the test case 3 when there are more .git directories in the hierarchy and there is .git in a directory with a lot of entries. On Linux, such a situation can happen when using symbolic links.
If EGit finds the .git directory, it will scan the complete hierarchy which can slow down Eclipse/JBDS/JBT or even lock it.
In my opinion, we should advice users to disable the "Auto Share EGit" projects and maybe even, to disable this property in JBDS using plugin_customization.ini.)
> Using symbolic links in the workspace path causes an infinite loop for m2e builder
> ----------------------------------------------------------------------------------
>
> Key: JBIDE-16379
> URL: https://issues.jboss.org/browse/JBIDE-16379
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: maven, upstream
> Affects Versions: 4.2.0.Alpha1
> Reporter: Snjezana Peco
> Assignee: Snjezana Peco
> Fix For: 4.3.x
>
>
> See JBIDE-16286
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (JBDS-3152) Cheatsheet crashes silently when they need to open files
by Sande Gilda (JIRA)
[ https://issues.jboss.org/browse/JBDS-3152?page=com.atlassian.jira.plugin.... ]
Sande Gilda commented on JBDS-3152:
-----------------------------------
I installed jboss-devstudio-8.0.0.CR1-v20140915-0805-B246-installer-standalone.jar, started JDBS in a new workspace, and the cheatsheet does not open when I import kitchensink or helloworld (https://github.com/jboss-developer/jboss-eap-quickstarts). I'm using Fedora 20 and jdk1.7.0_51.
> Cheatsheet crashes silently when they need to open files
> --------------------------------------------------------
>
> Key: JBDS-3152
> URL: https://issues.jboss.org/browse/JBDS-3152
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: central
> Environment: JBDS 8.0.0.CR1b, OSX 10.9.4
> Reporter: Fred Bricon
> Assignee: Snjezana Peco
> Priority: Blocker
> Fix For: 8.0.0.CR2
>
>
> After creating a AngularJS Forge project, the cheatsheet opens, then, after clicking a couple times on the continue buttons, persistence.xml opens but the cheatsheet closes silently. The log shows :
> {quote}
> org.eclipse.swt.SWTException: Widget is disposed
> at org.eclipse.swt.SWT.error(SWT.java:4441)
> at org.eclipse.swt.SWT.error(SWT.java:4356)
> at org.eclipse.swt.SWT.error(SWT.java:4327)
> at org.eclipse.swt.widgets.Widget.error(Widget.java:783)
> at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:573)
> at org.eclipse.swt.widgets.Control.setCursor(Control.java:3659)
> at org.eclipse.ui.internal.cheatsheets.views.CheatSheetViewer.runSubItemPerformExecutable(CheatSheetViewer.java:1096)
> at org.eclipse.ui.internal.cheatsheets.views.CoreItem$4.linkActivated(CoreItem.java:198)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink.handleActivate(AbstractHyperlink.java:233)
> at org.eclipse.ui.forms.widgets.ImageHyperlink.handleActivate(ImageHyperlink.java:199)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink.handleMouseUp(AbstractHyperlink.java:327)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink.access$2(AbstractHyperlink.java:311)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink$4.handleEvent(AbstractHyperlink.java:125)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4188)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1467)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1490)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1475)
> at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1279)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4031)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3658)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:236)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> {quote}
> It used to work at some point, last week.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (JBIDE-18526) CordovaSim: Debugger doesn't work properly with the last JDK 8u20
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18526?page=com.atlassian.jira.plugi... ]
Ilya Buziuk updated JBIDE-18526:
--------------------------------
Labels: upstream (was: )
> CordovaSim: Debugger doesn't work properly with the last JDK 8u20
> -----------------------------------------------------------------
>
> Key: JBIDE-18526
> URL: https://issues.jboss.org/browse/JBIDE-18526
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: browsersim
> Affects Versions: 4.2.0.CR2
> Environment: Not reproducible with Oracle JDK 7u67
> Affects Oracle JDK 8u20 and above (Not reproducible with JDK 8u5 and 8u11)
> Reporter: Ilya Buziuk
> Assignee: Ilya Buziuk
> Priority: Critical
> Labels: upstream
> Fix For: 4.2.0.Final
>
> Attachments: debugger error.png
>
>
> CordovaSim freezes with the following stack trace:
> {code}
> java.lang.IllegalStateException: Nested event loops are allowed only while handling system events
> at com.sun.javafx.tk.quantum.QuantumToolkit.enterNestedEventLoop(QuantumToolkit.java:506)
> at com.sun.javafx.webkit.EventLoopImpl.cycle(EventLoopImpl.java:59)
> at com.sun.webkit.EventLoop.fwkCycle(EventLoop.java:45)
> at com.sun.webkit.Timer.twkFireTimerEvent(Native Method)
> at com.sun.webkit.Timer.fireTimerEvent(Timer.java:83)
> at com.sun.webkit.Timer.notifyTick(Timer.java:64)
> at javafx.scene.web.WebEngine$PulseTimer.lambda$static$44(WebEngine.java:1167)
> at javafx.scene.web.WebEngine$PulseTimer$$Lambda$67/10449826.pulse(Unknown Source)
> at com.sun.javafx.tk.Toolkit.lambda$runPulse$28(Toolkit.java:314)
> at com.sun.javafx.tk.Toolkit$$Lambda$134/26908315.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:313)
> at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:340)
> at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:451)
> at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:431)
> at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$363(QuantumToolkit.java:298)
> at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$40/33541029.run(Unknown Source)
> at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
> at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2549)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3759)
> at org.jboss.tools.vpe.cordovasim.CordovaSimRunner.startCordovaSim(CordovaSimRunner.java:114)
> at org.jboss.tools.vpe.cordovasim.CordovaSimRunner.main(CordovaSimRunner.java:91)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (JBIDE-18455) UI freeze when using server view on remote servers
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18455?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-18455:
---------------------------------------
I wanted to verify this, but the truth is I cannot replicate the original problem with CR1 now. I suspect I might have better luck if trying on a slow network. So I will try tomorrow connecting from home.
> UI freeze when using server view on remote servers
> --------------------------------------------------
>
> Key: JBIDE-18455
> URL: https://issues.jboss.org/browse/JBIDE-18455
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Reporter: Max Rydahl Andersen
> Assignee: Rob Stryker
> Priority: Critical
> Fix For: 4.2.0.CR2
>
>
> create a remote server
> start it
> now when trying to use the server view with this server things freezes for several seconds.
> stacktrace shows it is blocking the main thread.
> full jstacktrace here: https://gist.github.com/maxandersen/51575583ba5877eb48ec
> important part here:
> {code}
> "main" prio=5 tid=0x0000000102870000 nid=0x513 in Object.wait() [0x00007fff5fbf9000]
> java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000007f492b908> (a java.lang.Object)
> at org.xnio.AbstractIoFuture.await(AbstractIoFuture.java:101)
> - locked <0x00000007f492b908> (a java.lang.Object)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:101)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> - locked <0x00000007f492a9a0> (a org.jboss.as.protocol.ProtocolConnectionManager)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:176)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:144)
> - locked <0x00000007f491a368> (a org.jboss.as.controller.client.impl.RemotingModelControllerClient)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:115)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:98)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.ide.eclipse.as.internal.management.as71.AS71Manager.execute(AS71Manager.java:325)
> at org.jboss.ide.eclipse.as.internal.management.as71.AS71Manager.getServerState(AS71Manager.java:266)
> at org.jboss.ide.eclipse.as.internal.management.as71.JBoss71ManagerService.getServerState(JBoss71ManagerService.java:142)
> at org.jboss.ide.eclipse.as.management.core.JBoss7ManagerServiceProxy.getServerState(JBoss7ManagerServiceProxy.java:71)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.ManagementPublishController.isRunning(ManagementPublishController.java:112)
> at org.jboss.tools.as.core.server.controllable.subsystems.internal.ManagementPublishController.canPublish(ManagementPublishController.java:124)
> at org.jboss.ide.eclipse.as.wtp.core.server.behavior.ControllableServerBehavior.canPublish(ControllableServerBehavior.java:297)
> at org.eclipse.wst.server.core.internal.Server.canPublish(Server.java:1215)
> at org.eclipse.wst.server.ui.internal.view.servers.PublishAction.accept(PublishAction.java:40)
> at org.eclipse.wst.server.ui.internal.view.servers.AbstractServerAction.selectionChanged(AbstractServerAction.java:85)
> at org.eclipse.ui.actions.SelectionProviderAction.selectionChanged(SelectionProviderAction.java:144)
> at org.eclipse.jface.viewers.Viewer$2.run(Viewer.java:163)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (JBIDE-18454) Cant connect to OpenShift running on RHEL 6.6 (javax.net.ssl.SSLException: Could not generate DH keypair)
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18454?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-18454:
---------------------------------------------
Just recording the combos that fail without this property set:
{code}
Verified tests:
(+ means works, - means fails)
OSX
====
+ oracle jdk 1.7.0_45 (max, yosemite)
+ oracle jdk 1.8.0_20 (max, yosemite)
Linux
====
- openjdk 1.7.65 (mlabuda, FC19)
+ openjdk 1.8.20 (mlabuda, FC19)
+openjdk 1.8_11 (adietish, FC20)
-openjdk 1.8_11 (adietish, FC20) - had both success/failing, no joke
- oracle jdk 1.7_65 (adietish, FC20)
+ oracle jdk 1.8_20 (adietish, FC20)
- oracle jdk 1.6_45 (adietish, FC20)
Windows
=======
+oracle jdk 1.7.X (mlabuda, win7)
+ oracle jdk 1.8.05 (mlabuda, win7)
{code}
> Cant connect to OpenShift running on RHEL 6.6 (javax.net.ssl.SSLException: Could not generate DH keypair)
> ---------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-18454
> URL: https://issues.jboss.org/browse/JBIDE-18454
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.2.0.CR1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Priority: Blocker
> Fix For: 4.2.0.CR2
>
> Attachments: ssl-error-on-connect.png
>
>
> In https://bugzilla.redhat.com/show_bug.cgi?id=1145848 openshift-java-client cant connect to OpenShift running on RHEL 6.6 when using jdks (openjdk and sun) < 1.8 on linux. We have to verify that this affects the Eclipse based tooling (that's also using openshift-java-client)
> {code}
> java.io.IOException: com.openshift.client.OpenShiftEndpointException: Could not request https://broker.ose21z-auto.com.cn/broker/rest/api: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
> at hudson.plugins.openshift.OpenShiftCloud.getOpenShiftConnection(OpenShiftCloud.java:186)
> at hudson.plugins.openshift.OpenShiftCloud.getSlaves(OpenShiftCloud.java:877)
> at hudson.plugins.openshift.OpenShiftCloud.provisionSlave(OpenShiftCloud.java:451)
> at hudson.plugins.openshift.OpenShiftCloud.provision(OpenShiftCloud.java:413)
> at hudson.slaves.NodeProvisioner.update(NodeProvisioner.java:281)
> at hudson.slaves.NodeProvisioner.access$000(NodeProvisioner.java:51)
> at hudson.slaves.NodeProvisioner$NodeProvisionerInvoker.doRun(NodeProvisioner.java:368)
> at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:54)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: com.openshift.client.OpenShiftEndpointException: Could not request https://broker.ose21z-auto.com.cn/broker/rest/api: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months