[JBoss JIRA] (JBIDE-21836) Preferences: openshift 3 oc location resets to a different/old value on restart
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21836?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-21836:
-----------------------------------
Priority: Critical (was: Blocker)
> Preferences: openshift 3 oc location resets to a different/old value on restart
> -------------------------------------------------------------------------------
>
> Key: JBIDE-21836
> URL: https://issues.jboss.org/browse/JBIDE-21836
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Reporter: Max Rydahl Andersen
> Assignee: Rob Stryker
> Priority: Critical
> Labels: oc_binary, openshift_v3, preferences
> Fix For: 4.4.0.Alpha1
>
>
> on start of eclipse new workspace the value is for reason unknown to me set to:
> {code}
> /Users/max/Downloads/openshift-origin-v1.0.3-1695461-darwin-amd64/oc
> {code}
> which does exist, but is old version and publish fails.
> Then I set it to
> {code}
> /usr/local/bin/oc
> {code}
> now publish works.
> Restart eclipse - old value returns and publish starts failing again.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-22005) Unexpected EOF in pod log
by Jeff Cantrill (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22005?page=com.atlassian.jira.plugi... ]
Jeff Cantrill commented on JBIDE-22005:
---------------------------------------
[~mlabuda] do you actually have a stack trace from eclipse identifying where this 'out of memory' occurred. We are using a bufferedinputstream which allows tweaking the buffer size. [~fbricon] Any thoughts on what the buffer should be on the inputstream? MessageConsole doesnt seem to have any features where you can set a buffer.
> Unexpected EOF in pod log
> -------------------------
>
> Key: JBIDE-22005
> URL: https://issues.jboss.org/browse/JBIDE-22005
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Assignee: Jeff Cantrill
> Priority: Critical
> Labels: openshift_v3
>
> I had an eap application running on OpenShift. I was watching pod log of the application (stdout from EAP server). Unfortunately in some point console was not enough for displaying pod log and it stopped streaming pod log.
> Last lines from console (output of application pod log)
> {code}
> ...
> [0m[33m09:27:29,845 WARN [org.jgroups.protocols.openshift.KUBE_PING] (Timer-4,shared=tcp) Problem getting Pod json from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1, headers={Authorization=#MASKED:885#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.openshift.ping.common.stream.InsecureStreamProvider@4fb96d85] for cluster [hornetq-channel], namespace [serveradaptertrests], labels [application=eap-app]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/namespaces/serveradaptertrests/pods?labelSe...
> error: unexpected EOF
> {code}
> I also checked pod log via Web UI, whether there is something wrong on OpenShift side, but it is tooling related - memory/space for pod log output in console is limited and it went "out of memory". Pod log in Web UI was streaming all the time. This block user from checking pod log once it reach a specific length.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBIDE-21857) Hot class reload doesn't work on OpenShift
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21857?page=com.atlassian.jira.plugi... ]
Alexey Kazakov updated JBIDE-21857:
-----------------------------------
Fix Version/s: 4.4.0.Alpha1
(was: 4.3.1.CR1)
> Hot class reload doesn't work on OpenShift
> ------------------------------------------
>
> Key: JBIDE-21857
> URL: https://issues.jboss.org/browse/JBIDE-21857
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta2
> Reporter: Fred Bricon
> Assignee: Max Rydahl Andersen
> Priority: Blocker
> Fix For: 4.4.0.Alpha1
>
> Attachments: HCRFailure.zip
>
>
> When enabling debug mode on an EAP server deployed on OpenShift, locally changing a class file will :
> - work sometimes when only the content of the method changed, but could fail in some other occasions with the Debugger saying the JDK is out of sync
> - will always fail if a method signature changed, the debugger saying JDK is out of sync
> Restarting the deployed module (with the .dodeploy flag) doesn't fixes the issue (as opposed to the same tweak ahen running on a local EAP server)
> This may be caused by running OpenJDK? Does it support the same level of debugging as Oracle JDK?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBDS-3739) Docker connection does not work after cdk restart
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-3739?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov updated JBDS-3739:
---------------------------------
Project: Developer Studio (JBoss Developer Studio) (was: Tools (JBoss Tools))
Key: JBDS-3739 (was: JBIDE-21947)
Workflow: CDW v1 (was: GIT Pull Request workflow )
Docs QE Status: NEW
Component/s: cdk
installer
upstream
(was: upstream)
(was: cdk)
Affects Version/s: 9.1.0.CR1
(was: 4.3.1.CR1)
Fix Version/s: 9.1.0.GA
(was: 4.3.1.CR1)
> Docker connection does not work after cdk restart
> -------------------------------------------------
>
> Key: JBDS-3739
> URL: https://issues.jboss.org/browse/JBDS-3739
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: cdk, installer, upstream
> Affects Versions: 9.1.0.CR1
> Reporter: Martin Malina
> Assignee: Hardy Ferentschik
> Labels: havoc
> Fix For: 9.1.0.GA
>
>
> When you set up cdk and start it for the first time, docker connection is properly set up and functioning. But when you restart cdk in the servers view, docker connection will no longer work.
> This is caused by a bug in vagrant-service-manager 0.0.4:
> https://github.com/projectatomic/vagrant-service-manager/issues/80
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months