[JBoss JIRA] (WFCORE-5004) TlsTestCase#testReloadTrustManager fails on IBM Java 8
by Sonia Zaldana (Jira)
[ https://issues.redhat.com/browse/WFCORE-5004?page=com.atlassian.jira.plug... ]
Sonia Zaldana updated WFCORE-5004:
----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/4236
> TlsTestCase#testReloadTrustManager fails on IBM Java 8
> ------------------------------------------------------
>
> Key: WFCORE-5004
> URL: https://issues.redhat.com/browse/WFCORE-5004
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 13.0.0.Beta1
> Reporter: Ondrej Kotek
> Assignee: Sonia Zaldana
> Priority: Major
>
> TlsTestCase#testReloadTrustManager fails on IBM Java 8 at [TlsTestCase.java#L439|https://github.com/wildfly/wildfly-core/blob/master...] reporting the same DN. When I try to compare using canonical names, there is a difference. Using RFC1779 or RFC2253 names is ok.
> {noformat}
> Assert.assertEquals(originalFoundDN.getIssuerX500Principal().getName(X500Principal.CANONICAL), ISSUER_DN.getName(X500Principal.CANONICAL));
> [ERROR] TlsTestCase.testReloadTrustManager:439 expected:<....2.840.113549.1.9.1=[#1613656c7974726f6e4077696c64666c792e6f7267],c=uk,st=elytron,cn=...> but was:<....2.840.113549.1.9.1=[elytron@wildfly.org],c=uk,st=elytron,cn=...>
> {noformat}
> Is it just a test issue, or can there be an impact on functionality? In case it's just a test issue, can we assert equality of names? I.e.
> {noformat}
> Assert.assertEquals(originalFoundDN.getIssuerX500Principal().getName(), ISSUER_DN.getName());
> {noformat}
> The same for [TlsTestCase.java#L465|https://github.com/wildfly/wildfly-core/blob/master...] then.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (SWSQE-1185) OC API - workload_list - apply Job/Pod filters
by Hayk Hovsepyan (Jira)
[ https://issues.redhat.com/browse/SWSQE-1185?page=com.atlassian.jira.plugi... ]
Hayk Hovsepyan updated SWSQE-1185:
----------------------------------
Description:
openshift_api.workload_list
# TODO apply Job filters
# TODO apply Pod filters
Activate in workload lists test:
# TODO when workloads are filtered put == here
was:
openshift_api.workload_list
# TODO apply Job filters
# TODO apply Pod filters
> OC API - workload_list - apply Job/Pod filters
> ----------------------------------------------
>
> Key: SWSQE-1185
> URL: https://issues.redhat.com/browse/SWSQE-1185
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Hayk Hovsepyan
> Priority: Major
> Labels: automation
>
> openshift_api.workload_list
> # TODO apply Job filters
> # TODO apply Pod filters
>
> Activate in workload lists test:
> # TODO when workloads are filtered put == here
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5437) Unable to deploy project to kie server
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5437?page=com.atlassian.jira.plug... ]
Yeser Amer commented on DROOLS-5437:
------------------------------------
Hi [~adupliak], I tried to reproduce it and I have the same behavior reported by [~jomarko].
I think this is not related to Test Scenario, so I strongly recommend to re-address it or to require support by Appformer team.
> Unable to deploy project to kie server
> --------------------------------------
>
> Key: DROOLS-5437
> URL: https://issues.redhat.com/browse/DROOLS-5437
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.39.0.Final
> Reporter: Anna Dupliak
> Assignee: Yeser Amer
> Priority: Blocker
> Labels: drools-tools
> Attachments: Screenshot from 2020-06-17 07-29-32.png, c.d is undefined 2.scesim, c.d is undefined.scesim, error.log, image-2020-06-16-21-39-06-147.png, undefinedType.webm
>
>
> Cannot deploy any project to kie-server
> Kie server fails deploying project with message [^c.d is undefined.scesim] [^c.d is undefined 2.scesim]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5437) Unable to deploy project to kie server
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5437?page=com.atlassian.jira.plug... ]
Yeser Amer updated DROOLS-5437:
-------------------------------
Component/s: (was: Scenario Simulation and Testing)
> Unable to deploy project to kie server
> --------------------------------------
>
> Key: DROOLS-5437
> URL: https://issues.redhat.com/browse/DROOLS-5437
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.39.0.Final
> Reporter: Anna Dupliak
> Assignee: Yeser Amer
> Priority: Blocker
> Labels: drools-tools
> Attachments: Screenshot from 2020-06-17 07-29-32.png, c.d is undefined 2.scesim, c.d is undefined.scesim, error.log, image-2020-06-16-21-39-06-147.png, undefinedType.webm
>
>
> Cannot deploy any project to kie-server
> Kie server fails deploying project with message [^c.d is undefined.scesim] [^c.d is undefined 2.scesim]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JGRP-2396) increasing networkdata, cpu and heap
by Rob van der Boom (Jira)
[ https://issues.redhat.com/browse/JGRP-2396?page=com.atlassian.jira.plugin... ]
Rob van der Boom commented on JGRP-2396:
----------------------------------------
So glad to see that keycloak 10 (or wildfly 19...) solved this issue !!!
!Schermafbeelding 2020-06-17 om 13.53.23.png!
> increasing networkdata, cpu and heap
> ------------------------------------
>
> Key: JGRP-2396
> URL: https://issues.redhat.com/browse/JGRP-2396
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.19
> Reporter: Rob van der Boom
> Assignee: Bela Ban
> Priority: Major
> Attachments: Schermafbeelding 2019-11-08 om 15.43.04.png, Schermafbeelding 2019-11-08 om 15.44.52.png, Schermafbeelding 2019-11-08 om 16.00.48.png, jstack-production-pod0.dump, standalone-ha.xml
>
>
> hey,
> we have an keycloak (sso) setup, version 7.0.1 running in kubernetes - aws.
> Its build on wildfly 17, infinispan 9.4 and jgroups 4.0.19.
> We have 3 pods running in standalone-ha with cache setup on distribution (all 3 nodes - so equivalent to replication)
> ISSUE:
> We see a slowly growing of networkstatistics, heap and cpu, while the number of sessions in keycloak (cached) remain almost stable.
> The cpu growth is caused by the TQbundler process, which explaines the networkdata growth. It looks like this is causing also a memory leakage..
> every 5 days we have to restart the pods and then every resets to a very low level including the heap. this while all sessions are still valid and cached.
> The only issue i could find maybe related to this is:
> https://issues.jboss.org/browse/JGRP-2382?jql=project%20%3D%20JGRP%20AND%...
> Could this be the same issue and does it also cause increasing network and cpu (since that is why we have to restart, the heap has much space left !).
> And if so how does this issue continue since for us its a major issue.
> We als had this issue already in keycloak 5 (wildfly 15), thats why we upgraded to the latest available version.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month