March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-91) Unify mechanism selection and fix the tests

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-91?page=com.atlassian.jira.plugin.sys... ] David Lloyd commented on ELY-91: -------------------------------- I think AbstractSasl* all need a bit of a rewrite since they only handle a very small number of cases properly. It's been on my todo list for a long time but somehow I just never quite have gotten to it yet. > Unify mechanism selection and fix the tests > ------------------------------------------- > > Key: ELY-91 > URL: https://issues.jboss.org/browse/ELY-91 > Project: WildFly Elytron > Issue Type: Task > Reporter: Peter Skopek > Assignee: Peter Skopek > Fix For: 1.0.0.Beta1 > > > Unify mechanism selection and fix the tests -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-656) The blessed repo's should not accept a git force push

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-656?page=com.atlassian.jira.plugin... ] Geoffrey De Smet commented on DROOLS-656: ----------------------------------------- Brilliant :) Now we can sleep better at night :) > The blessed repo's should not accept a git force push > ----------------------------------------------------- > > Key: DROOLS-656 > URL: https://issues.jboss.org/browse/DROOLS-656 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > If someone ever git forces pushes to a blessed repo all hell will break loose. > We can prevent git forces pushes, as explained here: > http://stackoverflow.com/questions/1754491/is-there-a-way-to-configure-gi... > Force pushing on blessed repo's is very bad, but force pushing on forks is very common. > Requirements: > - Enable this on 1 new dummy blessed repository > - Prove you cannot force push to > - Prove you can fork it and force push to your fork. > - Delete the dummy blessed repository > - If that works well, enable it on the real blessed repositories -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/REMJMX-94?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on REMJMX-94: ---------------------------------------- Brad, WFCORE-553 sounds different from the description of this JIRA. The description describes what sounds like a classloader leak in the client. WFCORE-553 is a server side problem with inefficient cleanup of server thread pools, such that the number of file descriptors used by the server is excessive if the pace of opening and closing remoting management channels outpaces the gc. It's more a problem that a load test fixture like your reproducer for https://bugzilla.redhat.com/show_bug.cgi?id=1193926 would hit. > Memory leak in remoting-jmx > --------------------------- > > Key: REMJMX-94 > URL: https://issues.jboss.org/browse/REMJMX-94 > Project: Remoting JMX > Issue Type: Bug > Affects Versions: 1.1.3.Final > Reporter: Libor Zoubek > Assignee: Darran Lofthouse > Labels: memory_leak > > In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed. > I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps: > 1. start new thread > 2. assign URL classloader to this thread (point it to jboss-client.jar) > 3. connect & disconnect to jmx-remoting endpoint > In this test no classes don't get GCed which after serveral iterations ends up in OOM. > My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org... > I am not sure if memleak is in remoting-jmx or some other underlying stuff. > I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-583) Think about interactive slave domain controller registration.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-583: --------------------------------------- Summary: Think about interactive slave domain controller registration. Key: WFCORE-583 URL: https://issues.jboss.org/browse/WFCORE-583 Project: WildFly Core Issue Type: Feature Request Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse We can never eliminate pre-defined installations but we could potentially offer a capability to make it easier to register a slave with it's master and enable TLS with client-cert based authentication for the slave. As an example if you have a master running with TLS enabled and it's own CA certificate the following flow could be possible. - Start slave domain controller disconnected. - Start CLI and connect to slave using local auth. - Execute join-domain(hostname, port) At this point a message is displayed asking if the masters cert is trusted, an opportunity to check the fingerprints - if accepted the master's cert goes into the slave's trust store. Next we use a proxied authentication so the administrator sitting in front of slave can enter their credentials to authenticate against master. The slave process generates a public and private key and with interaction with the administrator a certificate signing request. The certificate signing request is passed to master over the previously established TLS connection, master signs it and passes it back to the slave. The slave populates it's local KeyStore with the two keys and the master signed certificate. Master may store something or it may rely on the fact it signed the cert and use CRLs instead. Slave can now disconnect, then reconnect using the key and trust stores populated in the above flow. Master will then verify it using whatever policy it is using, this could be trust all signed certs except the ones in the CRL or it could have also stored currently trusted certs. This may even be possible in a provisioned environment where the base config contains enough information to establish that first connection - in that case you may want to bundle master's cert to eliminate it's validation. Overall not planning this as a short term implementation but tracking here as the kind of advanced capability we could add with all of the building blocks from Elytron. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-164) A KeyStore wrapper to track if modifications are made.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-164: ------------------------------------ Summary: A KeyStore wrapper to track if modifications are made. Key: ELY-164 URL: https://issues.jboss.org/browse/ELY-164 Project: WildFly Elytron Issue Type: Feature Request Components: SSL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha1 Unlike the UnmodifiableKeyStore this time need to track if methods are called that succeed and make modifications. This will be used by the subsystem to provide an indication to the user that the in-memory instance may not be in sync with the persisted instance. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?

by Georgy Go (JIRA)

[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ] Georgy Go updated WFLY-4373: ---------------------------- Priority: Major (was: Blocker) > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: CLI, IO > Affects Versions: 8.2.0.Final > Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final > Reporter: Georgy Go > Assignee: Alexey Loubyansky > Labels: cli, dmr > > The following snippet of code to redeploy an application: > ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); > ModelNode operation = new ModelNode(); > operation.get("operation").set("redeploy"); > operation.get("address").add("deployment", "server.war"); > cl.execute(operation); > cl.close(); > - works fine, but .close() freezes forever. > This issue depends to not only redeploy, but also for any other operations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4373) WildFly CLI API ModelControllerClient memory leak?

by Georgy Go (JIRA)

[ https://issues.jboss.org/browse/WFLY-4373?page=com.atlassian.jira.plugin.... ] Georgy Go updated WFLY-4373: ---------------------------- Priority: Blocker (was: Major) > WildFly CLI API ModelControllerClient memory leak? > -------------------------------------------------- > > Key: WFLY-4373 > URL: https://issues.jboss.org/browse/WFLY-4373 > Project: WildFly > Issue Type: Bug > Components: CLI, IO > Affects Versions: 8.2.0.Final > Environment: Ubuntu 14.04 LTS, Java 1.8, xnio-api and xnio-nio are 3.3.0.Final > Reporter: Georgy Go > Assignee: Alexey Loubyansky > Priority: Blocker > Labels: cli, dmr > > The following snippet of code to redeploy an application: > ModelControllerClient cl = ModelControllerClient.Factory.create("localhost", 9999); > ModelNode operation = new ModelNode(); > operation.get("operation").set("redeploy"); > operation.get("address").add("deployment", "server.war"); > cl.execute(operation); > cl.close(); > - works fine, but .close() freezes forever. > This issue depends to not only redeploy, but also for any other operations. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-656) The blessed repo's should not accept a git force push

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-656?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer resolved DROOLS-656. ------------------------------------------- Resolution: Done > The blessed repo's should not accept a git force push > ----------------------------------------------------- > > Key: DROOLS-656 > URL: https://issues.jboss.org/browse/DROOLS-656 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > If someone ever git forces pushes to a blessed repo all hell will break loose. > We can prevent git forces pushes, as explained here: > http://stackoverflow.com/questions/1754491/is-there-a-way-to-configure-gi... > Force pushing on blessed repo's is very bad, but force pushing on forks is very common. > Requirements: > - Enable this on 1 new dummy blessed repository > - Prove you cannot force push to > - Prove you can fork it and force push to your fork. > - Delete the dummy blessed repository > - If that works well, enable it on the real blessed repositories -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-656) The blessed repo's should not accept a git force push

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-656?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer commented on DROOLS-656: ----------------------------------------------- yeah - i tried with a rep I will remove right now. I tried from two sides - local as mbiarnes and on the server as kiereleaseuser. kiereleaseuser modified some files and commited and pushed them. mbiarnes modified the same files and tried ti do a git push -f origin master and get: Counting objects: 17, done. Delta compression using up to 4 threads. Compressing objects: 100% (12/12), done. Writing objects: 100% (17/17), 5.12 KiB | 0 bytes/s, done. Total 17 (delta 1), reused 3 (delta 0) remote: error: GH003: Sorry, force-pushing to master is not allowed. To git@github.com:droolsjbpm/testRepo.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'git@github.com:droolsjbpm/testRepo.git' I will close this JIRA then > The blessed repo's should not accept a git force push > ----------------------------------------------------- > > Key: DROOLS-656 > URL: https://issues.jboss.org/browse/DROOLS-656 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > If someone ever git forces pushes to a blessed repo all hell will break loose. > We can prevent git forces pushes, as explained here: > http://stackoverflow.com/questions/1754491/is-there-a-way-to-configure-gi... > Force pushing on blessed repo's is very bad, but force pushing on forks is very common. > Requirements: > - Enable this on 1 new dummy blessed repository > - Prove you cannot force push to > - Prove you can fork it and force push to your fork. > - Delete the dummy blessed repository > - If that works well, enable it on the real blessed repositories -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-505) Fix double redeployment due to .failed file and a artifact with newer timestamp.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-505?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-505: ------------------------------------------------ Chao Wang <chaowan(a)redhat.com> changed the Status of [bug 1169239|https://bugzilla.redhat.com/show_bug.cgi?id=1169239] from NEW to POST > Fix double redeployment due to .failed file and a artifact with newer timestamp. > -------------------------------------------------------------------------------- > > Key: WFCORE-505 > URL: https://issues.jboss.org/browse/WFCORE-505 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha15 > Reporter: Chao Wang > Assignee: Chao Wang > Fix For: 1.0.0.Alpha16 > > > Issue found and described in https://bugzilla.redhat.com/show_bug.cgi?id=1169239 > steps to reproduce: > 1. deploy a "Test.war" > 2. Change something in "Test.war" to fail it. > 3. "Test.war.failed" file will be created. > 4. stop JBoss EAP. > 5. Revert the changes done in "Test.war" so that it will deploy successfully. > 6. Now there are two files ("Test.war.failed" and "Test.war", due to correction, Test.war must have a newer timestamp than Test.war.failed)in deployment directory. > 7. Restart JBoss EAP, it will fail with below Error : > The problem happens as a result of redundant redeployment in next reboot. During servert reboot, it will try to redeploy the application due to found .failed file, it also will try to redeploy same application because Test.war has a newer timestamp to see the problem. This will cause server startup failure as: > {noformat} > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 18) JBAS014613: Operation ("add") failed - address: ([("deployment" => "Test.war")]) - failure description: "JBAS014803: Duplicate resource [(\"deployment\" => \"Test.war\")] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2015