April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-1099) Automate labels https://github.com/kiali/kiali-ui/pull/1686

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1099?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1099: ---------------------------------- Sprint: Kiali Sprint #38 > Automate labels https://github.com/kiali/kiali-ui/pull/1686 > ----------------------------------------------------------- > > Key: SWSQE-1099 > URL: https://issues.redhat.com/browse/SWSQE-1099 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2403) Dump information in panic scenarios

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2403?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2403: --------------------------- Description: When there is a panic situation (e.g. thread pool exhausted), dump information (e.g. including a thread dump) to a file at FATAL level. The question is *when* do we do this? If the pool fluctuates between almost-full and full, we can't obviously take a thread dump every time! was: When there is a panic situation (e.g. thread pool exhausted), dump information (e.g. including a thread dump) to a file at FATAL level. > Dump information in panic scenarios > ----------------------------------- > > Key: JGRP-2403 > URL: https://issues.redhat.com/browse/JGRP-2403 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.2, 5.0.0.Alpha4 > > > When there is a panic situation (e.g. thread pool exhausted), dump information (e.g. including a thread dump) to a file at FATAL level. > The question is *when* do we do this? If the pool fluctuates between almost-full and full, we can't obviously take a thread dump every time! -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5220) Make @watch annotation to also work with oopath

by Mario Fusco (Jira)

Mario Fusco created DROOLS-5220: ----------------------------------- Summary: Make @watch annotation to also work with oopath Key: DROOLS-5220 URL: https://issues.redhat.com/browse/DROOLS-5220 Project: Drools Issue Type: Bug Reporter: Mario Fusco Assignee: Mario Fusco Property reactivity is currently working on oopath as demostrated by this test case: {code} @Test public void testPropertyReactivityWithOOPath() { String str = "import " + Person.class.getCanonicalName() + ";" + "import " + AdultUnit.class.getCanonicalName() + "\n" + "rule Adult @Unit( AdultUnit.class ) when\n" + " $p : /persons[name == \"Mario\"]\n" + "then\n" + " modify($p) { setAge($p.getAge()+1) };\n" + "end\n"; KieContainer kieContainer = getKieContainer( null, str ); RuleUnitExecutor executor = RuleUnitExecutor.newRuleUnitExecutor( kieContainer ); Person mario = new Person( "Mario", 45 ); Person sofia = new Person( "Sofia", 8 ); DataSource<Person> persons = DataSource.create( mario, sofia ); AdultUnit unit = new AdultUnit(persons); assertEquals(1, executor.run( unit ) ); assertEquals(46, mario.getAge() ); } {code} Conversely what it is not working (it doesn't compile at all) is the use of the @watch annotation like in {code} @Test public void testPropertyReactivityWithOOPathAndWatch() { String str = "import " + Person.class.getCanonicalName() + ";" + "import " + AdultUnit.class.getCanonicalName() + "\n" + "rule Adult @Unit( AdultUnit.class ) when\n" + " $p : /persons[$age : age, name == \"Mario\"] @watch( !age )\n" + "then\n" + " modify($p) { setAge($age+1) };\n" + "end\n"; KieContainer kieContainer = getKieContainer( null, str ); RuleUnitExecutor executor = RuleUnitExecutor.newRuleUnitExecutor( kieContainer ); Person mario = new Person( "Mario", 45 ); Person sofia = new Person( "Sofia", 8 ); DataSource<Person> persons = DataSource.create( mario, sofia ); AdultUnit unit = new AdultUnit(persons); assertEquals(1, executor.run( unit ) ); assertEquals(46, mario.getAge() ); } {code} Of course this can work only on a one-level oopath. It has to be decided what to do (trigger a compile time error?) when trying to use that annotation on a oopath made of 2 or more chunks. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1111) UI job - Swagger Version Always 'master'

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1111?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1111. ---------------------------------- Resolution: Done Swagger.json is taken based on KIALI_REVISION_OR_BRANCH Main pipelines are setting it according to CORE_BRANCH parameter so it will not work for PR pipelines, but it's possible to run tests manually and set KIALI_REVISION_OR_BRANCH for given commit in the PR. > UI job - Swagger Version Always 'master' > ---------------------------------------- > > Key: SWSQE-1111 > URL: https://issues.redhat.com/browse/SWSQE-1111 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > UI tests are not getting correct swagger version - https://gitlab.cee.redhat.com/istio/kiali-qe/kiali-qe-jenkins-dsl/blob/ma... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1110) E2E job - Swagger Version Always 'master'

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1110?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1110. ---------------------------------- Resolution: Done Swagger.json is taken based on KIALI_REVISION_SHA1 Main pipeline are setting it according to CORE_BRANCH parameter so it will not work for PR pipelines, but it's possible to run tests manually and set KIALI_REVISION_SHA1 for given commit in the PR. > E2E job - Swagger Version Always 'master' > ----------------------------------------- > > Key: SWSQE-1110 > URL: https://issues.redhat.com/browse/SWSQE-1110 > Project: Kiali QE > Issue Type: Bug > Reporter: Matthew Mahoney > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > Issue is that the swagger json is always 'master'. > prepare-e2e-tests-env.sh needs to set the swagger file version/path appropriately based on KIALI_REVISION_SHA1 > https://github.com/kiali/kiali/blob/master/tests/e2e/config/env.yaml#L10 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1107) Update prepare-e2e-tests-env.sh and prepare-ui-tests-env.sh to be less verbose

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1107?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1107. ---------------------------------- Resolution: Done > Update prepare-e2e-tests-env.sh and prepare-ui-tests-env.sh to be less verbose > ------------------------------------------------------------------------------ > > Key: SWSQE-1107 > URL: https://issues.redhat.com/browse/SWSQE-1107 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Minor > Labels: infrastructure > > It produces very long output containing lot of: > Cloning into '/home/jenkins/agent/workspace/run-kiali-e2e-tests/kiali'... > Checking out files: 42% (3633/8645) > Checking out files: 43% (3718/8645) > Checking out files: 44% (3804/8645) > Checking out files: 45% (3891/8645) > Checking out files: 46% (3977/8645) > Checking out files: 47% (4064/8645) > Checking out files: 48% (4150/8645) > From https://github.com/kiali/kiali > * [new ref] refs/pull/1/head -> origin/pr/1/head > * [new ref] refs/pull/1/merge -> origin/pr/1/merge > * [new ref] refs/pull/10/head -> origin/pr/10/head > * [new ref] refs/pull/10/merge -> origin/pr/10/merge > * [new ref] refs/pull/100/head -> origin/pr/100/head > * [new ref] refs/pull/1000/head -> origin/pr/1000/head > * [new ref] refs/pull/1001/head -> origin/pr/1001/head > * [new ref] refs/pull/1002/head -> origin/pr/1002/head > * [new ref] refs/pull/1003/head -> origin/pr/1003/head > * [new ref] refs/pull/1004/head -> origin/pr/1004/head > * [new ref] refs/pull/1005/head -> origin/pr/1005/head > * [new ref] refs/pull/1009/head -> origin/pr/1009/head > * [new ref] refs/pull/101/head -> origin/pr/101/head > * [new ref] refs/pull/1010/head -> origin/pr/1010/head > * [new ref] refs/pull/1011/head -> origin/pr/1011/head > * [new ref] refs/pull/1012/head -> origin/pr/1012/head > * [new ref] refs/pull/1013/head -> origin/pr/1013/head > * [new ref] refs/pull/1014/head -> origin/pr/1014/head > * [new ref] refs/pull/1015/head -> origin/pr/1015/head > * [new ref] refs/pull/1016/head -> origin/pr/1016/head -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4041) ManagementRealm does now show plain-text attribute in default read-resource output

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFCORE-4041?page=com.atlassian.jira.plug... ] Jean Francois Denise commented on WFCORE-4041: ---------------------------------------------- [~michpetrov], yes that is a bug, the plain-text attribute is not handled, could you log a CLI JIRA. Thank-you. > ManagementRealm does now show plain-text attribute in default read-resource output > ---------------------------------------------------------------------------------- > > Key: WFCORE-4041 > URL: https://issues.redhat.com/browse/WFCORE-4041 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Justin Cook > Assignee: Michal Petrov > Priority: Major > > Currently running /subsystem=elytron/properties-realm=ManagementRealm:read-resource() results in the output: > {code} > { > "outcome" => "success", > "result" => { > "groups-attribute" => "groups", > "groups-properties" => { > "path" => "mgmt-groups.properties", > "relative-to" => "jboss.server.config.dir" > }, > "users-properties" => { > "path" => "mgmt-users.properties", > "relative-to" => "jboss.server.config.dir", > "digest-realm-name" => "ManagementRealm" > } > } > } > {code} > which is missing the plain-text attribute -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2463) TransferQueueBundler: Message to stopped node blocks the bundler thread

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2463?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2463. ---------------------------- Resolution: Done I'm closing this issue. Once JGRP-2108 is implemented, this problem should go away. Feel free to re-open if something else is causing this. > TransferQueueBundler: Message to stopped node blocks the bundler thread > ----------------------------------------------------------------------- > > Key: JGRP-2463 > URL: https://issues.redhat.com/browse/JGRP-2463 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.2.1 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.2, 5.0.0.Alpha4 > > > {{TransferQueueBundler}} sends all the messages from a single thread. When one of the {{TP.doSend()}} calls blocks, the bundler thread no longer makes any progress, and it doesn't send messages to any destination, even if {{TP.doSend()}} is only slow for one particular destination. > One example is when sending a message to a stopped node, e.g. the coordinator sending a {{LEAVE_RSP}} after the leaver has already stopped. The bundler thread calls {{TP.doSend()}}, the connection no longer exists, so it ends up calling {{BaseServer.createConnection()}}. If the stopped node's machine is no longer up or it is configured to drop messages to closed ports, the connection open blocks the bundler thread for {{TCP.sock_conn_timeout}}(default: 2s). > {{UNICAST3}} also retransmits the highest sent message every {{UNICAST3.xmit_interval}} (default: 500ms), for {{UNICAST3.max_retransmit_time}}(default: 1 min), so the bundler thread will block more than once for the same message. > I assume the bundler thread will also block if the transport is {{TCP}}, one of the destinations is overloaded, and the TCP connection's send buffer is full. Normally applications try to spread the workload evenly among members, but e.g. with RELAY2 not all the members will be site masters. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4041) ManagementRealm does now show plain-text attribute in default read-resource output

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-4041?page=com.atlassian.jira.plug... ] Darran Lofthouse commented on WFCORE-4041: ------------------------------------------ That last point does sound like something to review, however we may want and commands we offer to discourage the use of plain text. > ManagementRealm does now show plain-text attribute in default read-resource output > ---------------------------------------------------------------------------------- > > Key: WFCORE-4041 > URL: https://issues.redhat.com/browse/WFCORE-4041 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Justin Cook > Assignee: Michal Petrov > Priority: Major > > Currently running /subsystem=elytron/properties-realm=ManagementRealm:read-resource() results in the output: > {code} > { > "outcome" => "success", > "result" => { > "groups-attribute" => "groups", > "groups-properties" => { > "path" => "mgmt-groups.properties", > "relative-to" => "jboss.server.config.dir" > }, > "users-properties" => { > "path" => "mgmt-users.properties", > "relative-to" => "jboss.server.config.dir", > "digest-realm-name" => "ManagementRealm" > } > } > } > {code} > which is missing the plain-text attribute -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2402) SOS report

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2402?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2402. ---------------------------- Resolution: Done > SOS report > ---------- > > Key: JGRP-2402 > URL: https://issues.redhat.com/browse/JGRP-2402 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.2, 5.0.0.Alpha4 > > > Add the ability to dump the most important attributes to a file / log (configurable), e.g.: > * Max threads > * Number of rejected messages > * Size of retransmission tables (NAKACK2, UNICAST3) > This should be done periodically (e.g. every 15 minutes). This log should be enabled by default, e.g. in Infinispan. > These files can then be sent to support via an SOS report. > This can be used to diagnose issues by telling the customer to invoke this command and attach the resulting file to a ticket. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2020