From karthika.sathish at siemens.com Mon Apr 4 08:37:23 2016 From: karthika.sathish at siemens.com (karthika.sathish at siemens.com) Date: Mon, 4 Apr 2016 18:07:23 +0530 Subject: [wildfly-dev] Dependencies found in binaries of component JBoss AS - 7.2.0 Message-ID: <213407F210556E42A72638E06EDC4CFA09969D8D15@INBLRK77M2MSX.in002.siemens.net> Hi guys, I just went through the binaries of JBoss AS-7.20 and found around 320+ jar files (dependencies) in the binaries. It is mentioned in the website that the dependencies are licensed under LGPL V2.1 license or a compatible license. Can you please provide me with the license conditions (other than LGPL V2. 1 license, maybe permissive ones if any) and copyrights for these jar files if possible so that evaluation of the component could be done? I have attach the list of jar files found in binaries along with this mail. With best regards, Karthika Sathish CT DD DS AA TEC CON-PR email id:karthika.sathish at siemens.com www.siemens.co.in/STS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160404/686f3e7f/attachment.html From dandread at redhat.com Mon Apr 4 14:13:32 2016 From: dandread at redhat.com (Dimitris Andreadis) Date: Mon, 4 Apr 2016 20:13:32 +0200 Subject: [wildfly-dev] Dependencies found in binaries of component JBoss AS - 7.2.0 In-Reply-To: <213407F210556E42A72638E06EDC4CFA09969D8D15@INBLRK77M2MSX.in002.siemens.net> References: <213407F210556E42A72638E06EDC4CFA09969D8D15@INBLRK77M2MSX.in002.siemens.net> Message-ID: <5702AECC.6060504@redhat.com> In the distribution there should be a docs/licenses/licenses.xml file that pretty much contains all the info you need. Cheers -- Dimitris Andreadis Senior Engineering Manager Red Hat JBoss EAP/WildFly On 04/04/2016 14:37, karthika.sathish at siemens.com wrote: > Hi guys, > I just went through the binaries of JBoss AS-7.20 and found around 320+ jar files > (dependencies) in the binaries. It is mentioned in the website that the dependencies are > licensed under LGPL V2.1 license or a compatible license. Can you please provide me with the > license conditions (other than LGPL V2. 1 license, maybe permissive ones if any) and > copyrights for these jar files if possible so that evaluation of the component could be > done? I have attach the list of jar files found in binaries along with this mail. > With best regards, > Karthika Sathish > CT DD DS AA TEC CON-PR > email id:karthika.sathish at siemens.com > _www.siemens.co.in/STS_ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From karthika.sathish at siemens.com Tue Apr 5 04:13:17 2016 From: karthika.sathish at siemens.com (karthika.sathish at siemens.com) Date: Tue, 5 Apr 2016 13:43:17 +0530 Subject: [wildfly-dev] Dependencies found in binaries of component JBoss AS - 7.2.0 In-Reply-To: <5702AECC.6060504@redhat.com> References: <213407F210556E42A72638E06EDC4CFA09969D8D15@INBLRK77M2MSX.in002.siemens.net> <5702AECC.6060504@redhat.com> Message-ID: <213407F210556E42A72638E06EDC4CFA09970440A0@INBLRK77M2MSX.in002.siemens.net> Hello Guys, The problem is that the license.xml provided in the sources do not have license conditions covered for all jar files found in the binaries. There are around 358 jar files given in the binaries. Could you send me a file (if any) containing the license conditions for all jar files found in the binaries. With best regards, Karthika Sathish CT DD DS AA TEC CON-PR email id:karthika.sathish at siemens.com www.siemens.co.in/STS -----Original Message----- From: wildfly-dev-bounces at lists.jboss.org [mailto:wildfly-dev-bounces at lists.jboss.org] On Behalf Of Dimitris Andreadis Sent: Monday, April 04, 2016 11:44 PM To: wildfly-dev at lists.jboss.org Subject: Re: [wildfly-dev] Dependencies found in binaries of component JBoss AS - 7.2.0 In the distribution there should be a docs/licenses/licenses.xml file that pretty much contains all the info you need. Cheers -- Dimitris Andreadis Senior Engineering Manager Red Hat JBoss EAP/WildFly On 04/04/2016 14:37, karthika.sathish at siemens.com wrote: > Hi guys, > I just went through the binaries of JBoss AS-7.20 and found around > 320+ jar files > (dependencies) in the binaries. It is mentioned in the website that > the dependencies are licensed under LGPL V2.1 license or a compatible > license. Can you please provide me with the license conditions (other > than LGPL V2. 1 license, maybe permissive ones if any) and copyrights > for these jar files if possible so that evaluation of the component could be done? I have attach the list of jar files found in binaries along with this mail. > With best regards, > Karthika Sathish > CT DD DS AA TEC CON-PR > email id:karthika.sathish at siemens.com > _www.siemens.co.in/STS_ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: JAR_FILES_JBOSS_BINARIES.txt Url: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160405/bfe7872f/attachment-0001.txt From dandread at redhat.com Tue Apr 5 17:45:54 2016 From: dandread at redhat.com (Dimitris Andreadis) Date: Tue, 5 Apr 2016 23:45:54 +0200 Subject: [wildfly-dev] Dependencies found in binaries of component JBoss AS - 7.2.0 In-Reply-To: <213407F210556E42A72638E06EDC4CFA09970440A0@INBLRK77M2MSX.in002.siemens.net> References: <213407F210556E42A72638E06EDC4CFA09969D8D15@INBLRK77M2MSX.in002.siemens.net> <5702AECC.6060504@redhat.com> <213407F210556E42A72638E06EDC4CFA09970440A0@INBLRK77M2MSX.in002.siemens.net> Message-ID: <57043212.6020005@redhat.com> AFAIK, licenses.xml and the content of the licenses dir is produced at build time from maven license information as the union set of all licenses of all jars included in the build. So all the different licenses for those 358 jars are there. On 05/04/2016 10:13, karthika.sathish at siemens.com wrote: > Hello Guys, > > The problem is that the license.xml provided in the sources do not have license conditions covered for all jar files found in the binaries. There are around 358 jar files given in the binaries. Could you send me a file (if any) containing the license conditions for all jar files found in the binaries. > > With best regards, > Karthika Sathish > CT DD DS AA TEC CON-PR > email id:karthika.sathish at siemens.com > www.siemens.co.in/STS > > > -----Original Message----- > From: wildfly-dev-bounces at lists.jboss.org [mailto:wildfly-dev-bounces at lists.jboss.org] On Behalf Of Dimitris Andreadis > Sent: Monday, April 04, 2016 11:44 PM > To: wildfly-dev at lists.jboss.org > Subject: Re: [wildfly-dev] Dependencies found in binaries of component JBoss AS - 7.2.0 > > In the distribution there should be a docs/licenses/licenses.xml file that pretty much contains all the info you need. > > Cheers > > -- > Dimitris Andreadis > Senior Engineering Manager > Red Hat JBoss EAP/WildFly > > On 04/04/2016 14:37, karthika.sathish at siemens.com wrote: >> Hi guys, >> I just went through the binaries of JBoss AS-7.20 and found around >> 320+ jar files >> (dependencies) in the binaries. It is mentioned in the website that >> the dependencies are licensed under LGPL V2.1 license or a compatible >> license. Can you please provide me with the license conditions (other >> than LGPL V2. 1 license, maybe permissive ones if any) and copyrights >> for these jar files if possible so that evaluation of the component could be done? I have attach the list of jar files found in binaries along with this mail. >> With best regards, >> Karthika Sathish >> CT DD DS AA TEC CON-PR >> email id:karthika.sathish at siemens.com >> _www.siemens.co.in/STS_ >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From mwessend at redhat.com Wed Apr 6 03:43:22 2016 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 6 Apr 2016 09:43:22 +0200 Subject: [wildfly-dev] Fork-Join Pool on WildFly ? Message-ID: Hi, w/ Java8 and the Stream API, there is parallelStream(), which is based on the Fork-Join Pool. With JavaEE there a concurrency util, for managed threads and executors. However, fork-join is imcompatible with those managed threads, therefore I think (I hope I am not wrong here) it is NOT recommended to use parallel streams in JavaEE. Now, that WildFly-10 is Java8 and later I am wondering if there are plans to support that; e.g. with a non-standard feature/flag which could enable it, if desired. Sure that would cause issues regarding portablility, but still :-) Just wondering if there are any thoughts around this, for WildFly 10 or 11 Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160406/b7e73c9b/attachment.html From slaskawi at redhat.com Wed Apr 6 09:25:26 2016 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Wed, 6 Apr 2016 15:25:26 +0200 Subject: [wildfly-dev] SNI Support for WF Message-ID: Hey! I'm working on implementing SNI support for Infinispan [1] and I noticed that there are some plans to to implement it in WF11 as well [2][3]. Could you please tell me if there is any design for this? I'm especially interested in XML configuration bits. I think it would be beneficial if ISPN and WF configuration was similar (of course to some extend). Thanks Sebastian [1] https://issues.jboss.org/browse/ISPN-5721 [2] https://lists.jboss.org/pipermail/wildfly-dev/2015-February/003604.html [3] https://issues.jboss.org/browse/XNIO-227?focusedCommentId=13103329 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160406/99dcf0a2/attachment.html From david.lloyd at redhat.com Wed Apr 6 09:39:42 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 6 Apr 2016 08:39:42 -0500 Subject: [wildfly-dev] SNI Support for WF In-Reply-To: References: Message-ID: <5705119E.4010905@redhat.com> On 04/06/2016 08:25 AM, Sebastian Laskawiec wrote: > Hey! > > I'm working on implementing SNI support for Infinispan [1] and I noticed > that there are some plans to to implement it in WF11 as well [2][3]. > > Could you please tell me if there is any design for this? I'm especially > interested in XML configuration bits. I think it would be beneficial if > ISPN and WF configuration was similar (of course to some extend). This is related to unified SSL configuration (in the Elytron subsystem), which should premiere in WildFly 11. But I think there are still some design points to discuss here, which will probably happen mostly in the Elytron design chat room [1]. I expect a summary will make its way to this list once we have arrived at a final design. [1] https://www.hipchat.com/gKoTFkUyg -- - DML From claudio at claudius.com.br Wed Apr 6 18:59:05 2016 From: claudio at claudius.com.br (Claudio Miranda) Date: Wed, 6 Apr 2016 19:59:05 -0300 Subject: [wildfly-dev] undertow filters Message-ID: Hi, working with wildfly 10.1 SNAPSHOT, with latest update as of Mar/23 The issue is, add an error-page filter, named error3, remove it, add with the same name, it throws an exception of duplicated name, see below. The remove operation, requires a reload, but does it should prevent the adding of a item with the same name ? I thought the reload operation is necessary only to apply the settings at boot time. [standalone at localhost:9990 /] /subsystem=undertow/configuration=filter/error-page=error3:add(code=402,path="caminho2.html") {"outcome" => "success"} [standalone at localhost:9990 /] /subsystem=undertow/configuration=filter/error-page=error3:remove { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } [standalone at localhost:9990 /] /subsystem=undertow/configuration=filter/error-page=error3:add(code=402,path="caminho2.html") { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service jboss.undertow.filter.error3 is already registered", "rolled-back" => true, "response-headers" => {"process-state" => "reload-required"} } -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From slaskawi at redhat.com Thu Apr 7 01:27:12 2016 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Thu, 7 Apr 2016 07:27:12 +0200 Subject: [wildfly-dev] SNI Support for WF In-Reply-To: <5705119E.4010905@redhat.com> References: <5705119E.4010905@redhat.com> Message-ID: Thanks David! On Wed, Apr 6, 2016 at 3:39 PM, David M. Lloyd wrote: > On 04/06/2016 08:25 AM, Sebastian Laskawiec wrote: > > Hey! > > > > I'm working on implementing SNI support for Infinispan [1] and I noticed > > that there are some plans to to implement it in WF11 as well [2][3]. > > > > Could you please tell me if there is any design for this? I'm especially > > interested in XML configuration bits. I think it would be beneficial if > > ISPN and WF configuration was similar (of course to some extend). > > This is related to unified SSL configuration (in the Elytron subsystem), > which should premiere in WildFly 11. But I think there are still some > design points to discuss here, which will probably happen mostly in the > Elytron design chat room [1]. I expect a summary will make its way to > this list once we have arrived at a final design. > > [1] https://www.hipchat.com/gKoTFkUyg > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160407/d5356fba/attachment.html From brian.stansberry at redhat.com Thu Apr 7 10:20:35 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 7 Apr 2016 09:20:35 -0500 Subject: [wildfly-dev] undertow filters In-Reply-To: References: Message-ID: <57066CB3.9030803@redhat.com> This is what WFCORE-1106 is all about. The first remove removes the item from the configuration model, but doesn't remove the MSC service. The MSC service is only removed when you stop or reload the server. If you try and add the same resource back without doing the reload, the "add" op tries to install a new service and that conflicts with the one that is already there. On 4/6/16 5:59 PM, Claudio Miranda wrote: > Hi, working with wildfly 10.1 SNAPSHOT, with latest update as of Mar/23 > > The issue is, add an error-page filter, named error3, remove it, add > with the same name, it throws an exception of duplicated name, see > below. > > The remove operation, requires a reload, but does it should prevent > the adding of a item with the same name ? I thought the reload > operation is necessary only to apply the settings at boot time. > > > [standalone at localhost:9990 /] > /subsystem=undertow/configuration=filter/error-page=error3:add(code=402,path="caminho2.html") > {"outcome" => "success"} > [standalone at localhost:9990 /] > /subsystem=undertow/configuration=filter/error-page=error3:remove > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone at localhost:9990 /] > /subsystem=undertow/configuration=filter/error-page=error3:add(code=402,path="caminho2.html") > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: > org.jboss.msc.service.DuplicateServiceException: Service > jboss.undertow.filter.error3 is already registered", > "rolled-back" => true, > "response-headers" => {"process-state" => "reload-required"} > } > > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From claudio at claudius.com.br Thu Apr 7 11:13:56 2016 From: claudio at claudius.com.br (Claudio Miranda) Date: Thu, 7 Apr 2016 12:13:56 -0300 Subject: [wildfly-dev] undertow filters In-Reply-To: <57066CB3.9030803@redhat.com> References: <57066CB3.9030803@redhat.com> Message-ID: On Thu, Apr 7, 2016 at 11:20 AM, Brian Stansberry wrote: > This is what WFCORE-1106 is all about. Thank you Brian -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From luis.m.costa at gmail.com Thu Apr 7 17:03:48 2016 From: luis.m.costa at gmail.com (=?UTF-8?B?THXDrXMgTS4gQ29zdGE=?=) Date: Thu, 7 Apr 2016 22:03:48 +0100 Subject: [wildfly-dev] Intra-process connections to ephemeral ports Message-ID: I've be doing some tests with WF 10. I've noticed that are some connections being established intra-process to and from ephemeral ports. This is without having any application deployed. C:\>netstat -nao | findstr 28692 TCP 127.0.0.1:8280 0.0.0.0:0 LISTENING 28692 TCP 127.0.0.1:10190 0.0.0.0:0 LISTENING 28692 TCP 127.0.0.1:64778 127.0.0.1:64779 ESTABLISHED 28692 TCP 127.0.0.1:64779 127.0.0.1:64778 ESTABLISHED 28692 TCP 127.0.0.1:64780 127.0.0.1:64781 ESTABLISHED 28692 TCP 127.0.0.1:64781 127.0.0.1:64780 ESTABLISHED 28692 TCP 127.0.0.1:64782 127.0.0.1:64783 ESTABLISHED 28692 TCP 127.0.0.1:64783 127.0.0.1:64782 ESTABLISHED 28692 TCP 127.0.0.1:64784 127.0.0.1:64785 ESTABLISHED 28692 TCP 127.0.0.1:64785 127.0.0.1:64784 ESTABLISHED 28692 TCP 127.0.0.1:64786 127.0.0.1:64787 ESTABLISHED 28692 TCP 127.0.0.1:64787 127.0.0.1:64786 ESTABLISHED 28692 TCP 127.0.0.1:64788 127.0.0.1:64789 ESTABLISHED 28692 TCP 127.0.0.1:64789 127.0.0.1:64788 ESTABLISHED 28692 TCP 127.0.0.1:64790 127.0.0.1:64791 ESTABLISHED 28692 TCP 127.0.0.1:64791 127.0.0.1:64790 ESTABLISHED 28692 TCP 127.0.0.1:64792 127.0.0.1:64793 ESTABLISHED 28692 TCP 127.0.0.1:64793 127.0.0.1:64792 ESTABLISHED 28692 *Setup* Wildfly 10 final (just downloaded / no applications deployed / port offset:150) Windows 7 64bits Java 8u20 Can someone clarify why is this happening? Or provide some troubleshooting tips? *Connection pattern* Using WinCap I was able to identify the communication pattern: Client Connects [SYN] Server Ack [SYN, ACK] Client Ack [ACK] Client Push [PSH] - It pushes 8 bytes (e.g., in hex, e6202552f2b95f6f) Optionally the server pushes some data periodically (always the same) Server Push [PSH] - It pushes 1 bytes (in hex, 1) I've reported a problem related with this in the user's forum, but I still don't have a answer. Link: https://developer.jboss.org/message/953900 Thanks, Lu?s M. Costa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160407/450a9891/attachment.html From rstryker at redhat.com Fri Apr 8 09:35:16 2016 From: rstryker at redhat.com (Rob Stryker) Date: Fri, 8 Apr 2016 09:35:16 -0400 Subject: [wildfly-dev] Question on jboss-app_7_0.xsd and why it inherits from application_6.xsd Message-ID: <5707B394.2070906@redhat.com> While investigating a jira (https://issues.jboss.org/browse/JBIDE-22141) I tried to make a minimalist jboss-application xml, and it had a really strange validation error: cvc-complex-type.3.1: Value '7.0' of attribute 'version' of element 'jboss-app' is not valid with respect to the corresponding attribute use. Attribute 'version' has a fixed value of '6'. When I dug into the current jboss-app_7_0.xsd to see what was going on (https://github.com/jboss/metadata/blob/master/ear/src/main/resources/schema/jboss-app_7_0.xsd) I saw the following: Shouldn't this be pulling from application_7.xsd at least? Also we don't seem to have a jboss-common_7_0.xsd. So these version inconsistancies are really angering the eclipse validator. Is there anything that can be done here at all? It really seems our schema have this recurring problem of not validating in eclipse, and often times it seems the problems lead back to our very own schema as the cause. It ends up causing errors in eclipse and our users get very confused why all our example projects or snippets of xml on redhat access often fail to validate. - Rob Stryker From ken at zaptillion.net Fri Apr 8 17:49:04 2016 From: ken at zaptillion.net (Ken Wills) Date: Fri, 8 Apr 2016 16:49:04 -0500 Subject: [wildfly-dev] Intra-process connections to ephemeral ports In-Reply-To: References: Message-ID: On Thu, Apr 7, 2016 at 4:03 PM, Lu?s M. Costa wrote: > > *Setup* > Wildfly 10 final (just downloaded / no applications deployed / port > offset:150) > Windows 7 64bits > Java 8u20 > > Can someone clarify why is this happening? Or provide some troubleshooting > tips? > > Are you starting a domain, or standalone? > I've reported a problem related with this in the user's forum, but I still > don't have a answer. > Link: https://developer.jboss.org/message/953900 > > The forum post says you were using WF8.2.1-Final, is this happening with both 10 and 8? The first thing I'd try is make sure you're running the process as administrator and see if the same thing occurs, perhaps it's a permissions issue. Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160408/e88d39b7/attachment.html From luis.m.costa at gmail.com Sun Apr 10 13:50:35 2016 From: luis.m.costa at gmail.com (=?UTF-8?B?THXDrXMgTS4gQ29zdGE=?=) Date: Sun, 10 Apr 2016 18:50:35 +0100 Subject: [wildfly-dev] Intra-process connections to ephemeral ports In-Reply-To: References: Message-ID: Hi Ken, I'm using standalone. I've observed the problem both in WF 8.2.1.Final and WF 10.0.0.Final. The type of connection, and communication pattern, is the same. This is observable in Windows (I haven't tried any linux flavor) running as Administrator or Windows Service. I've been using JDK 8u20, but it is also observable with the latest JDK release. I find this connections very intriguing, and I'm hopping to understand what sub-system may be responsible, in order to deal with the problem I described in the forum. Thanks, Lu?s M. Costa On Fri, Apr 8, 2016 at 10:49 PM, Ken Wills wrote: > On Thu, Apr 7, 2016 at 4:03 PM, Lu?s M. Costa > wrote: > >> >> *Setup* >> Wildfly 10 final (just downloaded / no applications deployed / port >> offset:150) >> Windows 7 64bits >> Java 8u20 >> >> Can someone clarify why is this happening? Or provide some >> troubleshooting tips? >> >> > Are you starting a domain, or standalone? > > >> I've reported a problem related with this in the user's forum, but I >> still don't have a answer. >> Link: https://developer.jboss.org/message/953900 >> >> > The forum post says you were using WF8.2.1-Final, is this happening with > both 10 and 8? > > The first thing I'd try is make sure you're running the process as > administrator and see if the same thing occurs, perhaps it's a permissions > issue. > > Ken > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160410/d1a5973b/attachment.html From ken at zaptillion.net Sun Apr 10 16:11:06 2016 From: ken at zaptillion.net (Ken Wills) Date: Sun, 10 Apr 2016 15:11:06 -0500 Subject: [wildfly-dev] Intra-process connections to ephemeral ports In-Reply-To: References: Message-ID: Hi Lu?s, On Sun, Apr 10, 2016 at 12:50 PM, Lu?s M. Costa wrote: > > I'm using standalone. > > Quick note, when I looked at the forum on Friday, it wasn't showing me any responses to your original post, so sorry for the duplicate questions. I see that there are a few responses prior. What configuration are you using? standalone.xml? I've had a quick look on linux and I don't see the same behavior, but perhaps I'm not using the same config. > I've observed the problem both in WF 8.2.1.Final and WF 10.0.0.Final. The > type of connection, and communication pattern, is the same. This is > observable in Windows (I haven't tried any linux flavor) running as > Administrator or Windows Service. I've been using JDK 8u20, but it is also > observable with the latest JDK release. > > I find this connections very intriguing, and I'm hopping to understand > what sub-system may be responsible, in order to deal with the problem I > described in the forum. > > On Fri, Apr 8, 2016 at 10:49 PM, Ken Wills wrote: > >> On Thu, Apr 7, 2016 at 4:03 PM, Lu?s M. Costa >> wrote: >> >>> >>> *Setup* >>> Wildfly 10 final (just downloaded / no applications deployed / port >>> offset:150) >>> Windows 7 64bits >>> Java 8u20 >>> >>> Can someone clarify why is this happening? Or provide some >>> troubleshooting tips? >>> >>> >> Are you starting a domain, or standalone? >> >> >>> I've reported a problem related with this in the user's forum, but I >>> still don't have a answer. >>> Link: https://developer.jboss.org/message/953900 >>> >>> >> The forum post says you were using WF8.2.1-Final, is this happening with >> both 10 and 8? >> >> The first thing I'd try is make sure you're running the process as >> administrator and see if the same thing occurs, perhaps it's a permissions >> issue. >> >> Ken >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160410/851b6b1d/attachment-0001.html From luis.m.costa at gmail.com Sun Apr 10 18:48:07 2016 From: luis.m.costa at gmail.com (=?UTF-8?B?THXDrXMgTS4gQ29zdGE=?=) Date: Sun, 10 Apr 2016 23:48:07 +0100 Subject: [wildfly-dev] Intra-process connections to ephemeral ports In-Reply-To: References: Message-ID: Yes, I'm using standalone.xml. To reproduce the odd behaviour, it's very simple (in windows, at least): - Download WF 10.0.0.Final - Execute "stanalone.bat" Use netstat, and filter for PID, to see the unexpected connections. If you dig further, like I did, and enable TRACE for XNIO, nothing related with these connections shows up. Capturing the traffic (I use WinCap for localhost captures in windows), you'll see the the pattern I referred earlier. On Sun, Apr 10, 2016 at 9:11 PM, Ken Wills wrote: > Hi Lu?s, > > On Sun, Apr 10, 2016 at 12:50 PM, Lu?s M. Costa > wrote: >> >> I'm using standalone. >> >> > Quick note, when I looked at the forum on Friday, it wasn't showing me any > responses to your original post, so sorry for the duplicate questions. I > see that there are a few responses prior. > > What configuration are you using? standalone.xml? I've had a quick look on > linux and I don't see the same behavior, but perhaps I'm not using the same > config. > > >> I've observed the problem both in WF 8.2.1.Final and WF 10.0.0.Final. The >> type of connection, and communication pattern, is the same. This is >> observable in Windows (I haven't tried any linux flavor) running as >> Administrator or Windows Service. I've been using JDK 8u20, but it is also >> observable with the latest JDK release. >> >> I find this connections very intriguing, and I'm hopping to understand >> what sub-system may be responsible, in order to deal with the problem I >> described in the forum. >> > >> On Fri, Apr 8, 2016 at 10:49 PM, Ken Wills wrote: >> >>> On Thu, Apr 7, 2016 at 4:03 PM, Lu?s M. Costa >>> wrote: >>> >>>> >>>> *Setup* >>>> Wildfly 10 final (just downloaded / no applications deployed / port >>>> offset:150) >>>> Windows 7 64bits >>>> Java 8u20 >>>> >>>> Can someone clarify why is this happening? Or provide some >>>> troubleshooting tips? >>>> >>>> >>> Are you starting a domain, or standalone? >>> >>> >>>> I've reported a problem related with this in the user's forum, but I >>>> still don't have a answer. >>>> Link: https://developer.jboss.org/message/953900 >>>> >>>> >>> The forum post says you were using WF8.2.1-Final, is this happening with >>> both 10 and 8? >>> >>> The first thing I'd try is make sure you're running the process as >>> administrator and see if the same thing occurs, perhaps it's a permissions >>> issue. >>> >>> Ken >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160410/2f470ddd/attachment.html From mnovotny at redhat.com Mon Apr 11 03:15:39 2016 From: mnovotny at redhat.com (Marek Novotny) Date: Mon, 11 Apr 2016 09:15:39 +0200 Subject: [wildfly-dev] Question on jboss-app_7_0.xsd and why it inherits from application_6.xsd In-Reply-To: <5707B394.2070906@redhat.com> References: <5707B394.2070906@redhat.com> Message-ID: <570B4F1B.5070605@redhat.com> Isn't JBoss AS 7.x compliant to Java EE 6 specs which is the XSD schema there referenced/imported from Sun? I guess you mixed Java EE 6 with JBoss AS 7 versions here. On 8.4.2016 15:35, Rob Stryker wrote: > While investigating a jira (https://issues.jboss.org/browse/JBIDE-22141) > I tried to make a minimalist jboss-application xml, and it had a really > strange validation error: > > cvc-complex-type.3.1: Value '7.0' of attribute 'version' of element > 'jboss-app' is not valid with respect to the corresponding attribute > use. Attribute 'version' has a fixed value of '6'. > > When I dug into the current jboss-app_7_0.xsd to see what was going on > (https://github.com/jboss/metadata/blob/master/ear/src/main/resources/schema/jboss-app_7_0.xsd) > I saw the following: > > > > > schemaLocation="application_6.xsd"/> > > > > > > > Shouldn't this be pulling from application_7.xsd at least? Also we > don't seem to have a jboss-common_7_0.xsd. So these version > inconsistancies are really angering the eclipse validator. > > Is there anything that can be done here at all? It really seems our > schema have this recurring problem of not validating in eclipse, and > often times it seems the problems lead back to our very own schema as > the cause. It ends up causing errors in eclipse and our users get very > confused why all our example projects or snippets of xml on redhat > access often fail to validate. > > - Rob Stryker > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Marek Novotny -- Windup team member and Seam Project Lead Red Hat Czech s.r.o. Purkynova 99 612 45 Brno From mmucha at redhat.com Mon Apr 11 04:08:12 2016 From: mmucha at redhat.com (Martin Mucha) Date: Mon, 11 Apr 2016 04:08:12 -0400 (EDT) Subject: [wildfly-dev] about using wildfly-maven-plugin with port-offset In-Reply-To: <1791080670.36053449.1460361712892.JavaMail.zimbra@redhat.com> Message-ID: <1326259939.36055211.1460362092929.JavaMail.zimbra@redhat.com> Hi, I'm having problems when using wildfly-maven-plugin with port-offset. If I specify pom.xml like below, server does start up, but shutsdown after a minute, because it was allegedly not started up (which is not true). When server-args are omitted, everything works. If it's like below, everything works as well, but only for a minute. Can you advice how correct port-offset usage looks like? Thanks. M. ??? org.wildfly.plugins wildfly-maven-plugin ${version.wildfly.maven.plugin} ${jbossHome} standalone.xml -Djboss.socket.binding.port-offset=200 ${project.build.finalName}.war From lthon at redhat.com Mon Apr 11 04:15:05 2016 From: lthon at redhat.com (Ladislav Thon) Date: Mon, 11 Apr 2016 10:15:05 +0200 Subject: [wildfly-dev] about using wildfly-maven-plugin with port-offset In-Reply-To: <1326259939.36055211.1460362092929.JavaMail.zimbra@redhat.com> References: <1326259939.36055211.1460362092929.JavaMail.zimbra@redhat.com> Message-ID: <570B5D09.2030305@redhat.com> Hi, I'd assume that the plugin tries to connect to the server on the management port to figure out if the server really started. But if you set a port offset via a system property, the plugin has no chance of figuring out that the default port is now wrong (short of parsing the string...). There seems to be a configuration option for specifying the port manually: https://docs.jboss.org/wildfly/plugins/maven/latest/start-mojo.html#port I'd start there. LT P.S.: I'm not sure if this is the correct list for this type of questions. On 11.4.2016 10:08, Martin Mucha wrote: > > Hi, > > I'm having problems when using wildfly-maven-plugin with port-offset. If I specify pom.xml like below, server does start up, but shutsdown after a minute, because it was allegedly not started up (which is not true). When server-args are omitted, everything works. If it's like below, everything works as well, but only for a minute. Can you advice how correct port-offset usage looks like? Thanks. > > M. > ??? > > > > > org.wildfly.plugins > wildfly-maven-plugin > ${version.wildfly.maven.plugin} > > ${jbossHome} > standalone.xml > > -Djboss.socket.binding.port-offset=200 > > ${project.build.finalName}.war > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From mmucha at redhat.com Mon Apr 11 04:39:34 2016 From: mmucha at redhat.com (Martin Mucha) Date: Mon, 11 Apr 2016 04:39:34 -0400 (EDT) Subject: [wildfly-dev] about using wildfly-maven-plugin with port-offset In-Reply-To: <570B5D09.2030305@redhat.com> References: <1326259939.36055211.1460362092929.JavaMail.zimbra@redhat.com> <570B5D09.2030305@redhat.com> Message-ID: <1509887615.36062142.1460363974108.JavaMail.zimbra@redhat.com> Thanks for response, that settled it. Default port number did not seemed (to beginner-ish me) as it's designed to be used with port offsets, so I did not try that. But providing port number fixed it. Thanks, M. ----- Original Message ----- > Hi, > > I'd assume that the plugin tries to connect to the server on the > management port to figure out if the server really started. But if you > set a port offset via a system property, the plugin has no chance of > figuring out that the default port is now wrong (short of parsing the > string...). > > There seems to be a configuration option for specifying the port manually: > > https://docs.jboss.org/wildfly/plugins/maven/latest/start-mojo.html#port > > I'd start there. > > LT > > P.S.: I'm not sure if this is the correct list for this type of questions. > > On 11.4.2016 10:08, Martin Mucha wrote: > > > > Hi, > > > > I'm having problems when using wildfly-maven-plugin with port-offset. If I > > specify pom.xml like below, server does start up, but shutsdown after a > > minute, because it was allegedly not started up (which is not true). When > > server-args are omitted, everything works. If it's like below, everything > > works as well, but only for a minute. Can you advice how correct > > port-offset usage looks like? Thanks. > > > > M. > > ??? > > > > > > > > > > org.wildfly.plugins > > wildfly-maven-plugin > > ${version.wildfly.maven.plugin} > > > > ${jbossHome} > > standalone.xml > > > > -Djboss.socket.binding.port-offset=200 > > > > ${project.build.finalName}.war > > > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Mon Apr 11 12:57:59 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 11 Apr 2016 11:57:59 -0500 Subject: [wildfly-dev] Inter Host Controller group communication mesh Message-ID: <570BD797.9010706@redhat.com> Just an FYI: I spent a couple days and worked up a POC[1] of creating a JGroups-based reliable group communication mesh over the sockets our Host Controllers use for intra-domain management communications. Currently those sockets are used to form a tree of connections; master HC to slave HCs and then HCs to their servers. Slave HCs don't talk to each other. That kind of topology works fine for our current use cases, but not for other use cases, where a full communication mesh is more appropriate. 2 use cases led me to explore this: 1) A longstanding request to have automatic failover of the master HC to a backup. There are different ways to do this, but group communication based leader election is a possible solution. My preference, really. 2) https://issues.jboss.org/browse/WFLY-1066, which has led to various design alternatives, one of which is a distributed cache of topology information, available via each HC. See [2] for some of that discussion. I don't know if this kind of communication is a good idea, or if it's the right solution to either of these use cases. Lots of things need careful thought!! But I figured it was worth some time to experiment. And it worked in at least a basic POC way, hence this FYI. If you're interested in details, here are some Q&A: Q: Why JGroups? A: Because 1) I know it well 2) I trust it and 3) it's already used for this kind of group communications in full WildFly. Q: Why the management sockets? Why not other sockets? A: Slave HCs already need configuration for how to discover the master. Using the same sockets lets us reuse that discovery configuration for the JGroups communications as well. If we're going to use this kind of communication in an serious way, the configuration needs to be as easy as possible. Q: How does it work? A: JGroups is based on a stack of "protocols" each of which handles one aspect of reliable group communications. The POC creates and uses a standard protocol stack, except it replaces two standard protocols with custom ones: a) JGroups has various "Discovery" protocols which are used to find possible peers. I implemented one that integrates with the HC's domain controller discovery logic. It's basically a copy of the oft used TCPPING protocol with about 10-15 lines of code changed. b) JGroups has various "Transport" protocols which are responsible for actually sending/receiving over the network. I created a new one of those that knows how to use the WF management comms stuff built on JBoss Remoting. JGroups provides a number of base classes to use in this transport area, so I was able to rely on a lot of existing functionality and could just focus on the details specific to this case. Q: What have you done using the POC? A: I created a master HC and a slave on my laptop and saw them form a cluster and exchange messages. Typical stuff like starting and stopping the HCs worked. I see no reason why having multiple slaves wouldn't have worked too; I just didn't do it. Q: What's next? A: Nothing really. We have a couple concrete use cases we're looking to solve. We need to figure out the best solution for those use cases. If this kind of thing is useful in that, great. If not, it was a fun POC. [1] https://github.com/wildfly/wildfly-core/compare/master...bstansberry:jgroups-dc . See the commit message on the single commit to learn a bit more. [2] https://developer.jboss.org/wiki/ADomainManagedServiceRegistry -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From ken at zaptillion.net Mon Apr 11 16:43:27 2016 From: ken at zaptillion.net (Ken Wills) Date: Mon, 11 Apr 2016 15:43:27 -0500 Subject: [wildfly-dev] Inter Host Controller group communication mesh In-Reply-To: <570BD797.9010706@redhat.com> References: <570BD797.9010706@redhat.com> Message-ID: On Mon, Apr 11, 2016 at 11:57 AM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > Just an FYI: I spent a couple days and worked up a POC[1] of creating a > JGroups-based reliable group communication mesh over the sockets our > Host Controllers use for intra-domain management communications. > > Nice! I've been thinking about the mechanics of this a bit recently, but I hadn't gotten to any sort of transport details, this looks interesting. > Currently those sockets are used to form a tree of connections; master > HC to slave HCs and then HCs to their servers. Slave HCs don't talk to > each other. That kind of topology works fine for our current use cases, > but not for other use cases, where a full communication mesh is more > appropriate. > > 2 use cases led me to explore this: > > 1) A longstanding request to have automatic failover of the master HC to > a backup. There are different ways to do this, but group communication > based leader election is a possible solution. My preference, really. > I'd come to the same conclusion of it being an election. A deterministic election algorithm, perhaps allowing the configuration to supply some sort of weighted value to influence the election on each node, perhaps analogous to how the master browser smb election works (version + weight + etc). > > 2) https://issues.jboss.org/browse/WFLY-1066, which has led to various > design alternatives, one of which is a distributed cache of topology > information, available via each HC. See [2] for some of that discussion. > > I don't know if this kind of communication is a good idea, or if it's > the right solution to either of these use cases. Lots of things need > careful thought!! But I figured it was worth some time to experiment. > And it worked in at least a basic POC way, hence this FYI. > Not knowing a lot about jgroups .. for very large domains is the mesh NxN in size? For thousands of nodes would this become a problem, or would a mechanism to segment into local groups perhaps, with only certain nodes participating in the mesh and being eligible for election? Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160411/bd8a53b4/attachment.html From brian.stansberry at redhat.com Mon Apr 11 17:20:02 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 11 Apr 2016 16:20:02 -0500 Subject: [wildfly-dev] Inter Host Controller group communication mesh In-Reply-To: References: <570BD797.9010706@redhat.com> Message-ID: <570C1502.4000808@redhat.com> On 4/11/16 3:43 PM, Ken Wills wrote: > > > On Mon, Apr 11, 2016 at 11:57 AM, Brian Stansberry > > wrote: > > Just an FYI: I spent a couple days and worked up a POC[1] of creating a > JGroups-based reliable group communication mesh over the sockets our > Host Controllers use for intra-domain management communications. > > > Nice! I've been thinking about the mechanics of this a bit recently, but > I hadn't gotten to any sort of transport details, this looks interesting. > > Currently those sockets are used to form a tree of connections; master > HC to slave HCs and then HCs to their servers. Slave HCs don't talk to > each other. That kind of topology works fine for our current use cases, > but not for other use cases, where a full communication mesh is more > appropriate. > > 2 use cases led me to explore this: > > 1) A longstanding request to have automatic failover of the master HC to > a backup. There are different ways to do this, but group communication > based leader election is a possible solution. My preference, really. > > > I'd come to the same conclusion of it being an election. A deterministic > election algorithm, perhaps allowing the configuration to supply some > sort of weighted value to influence the election on each node, perhaps > analogous to how the master browser smb election works (version + weight > + etc). Yep. For sure the master must be running the latest version. > > > 2) https://issues.jboss.org/browse/WFLY-1066, which has led to various > design alternatives, one of which is a distributed cache of topology > information, available via each HC. See [2] for some of that discussion. > > I don't know if this kind of communication is a good idea, or if it's > the right solution to either of these use cases. Lots of things need > careful thought!! But I figured it was worth some time to experiment. > And it worked in at least a basic POC way, hence this FYI. > > > Not knowing a lot about jgroups .. for very large domains is the mesh > NxN in size? Yes. For thousands of nodes would this become a problem, It's one concern I have, yes. There are large JGroups clusters, but they may be based on the UDP multicast transport JGroups offers. > or would > a mechanism to segment into local groups perhaps, with only certain > nodes participating in the mesh and being eligible for election? For sure we'd have something in the host.xml that controls whether a particular HC joins the group. I don't think this is a big problem for the DC election use case, as you don't need a large number of HCs in the group. You'd have a few "potential" DCs that could join the group, and the remaining slaves don't need to. For use cases where you want slave HCs to be in the cluster though, it's a concern. The distributed topology cache thing may or may not need that. It needs a few HCs to provide HA, but those could be the same ones that are "potential" HCs. But if only a few are in the group, the servers need to be told how to reach those HCs. Chicken and egg, as the point of the topology cache is to provide that kind of data to servers! If a server's own HC is required to be a part of the group though, that helps cut through the chicken/egg problem. > Ken > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From hbraun at redhat.com Tue Apr 12 02:57:24 2016 From: hbraun at redhat.com (Heiko Braun) Date: Tue, 12 Apr 2016 08:57:24 +0200 Subject: [wildfly-dev] Inter Host Controller group communication mesh In-Reply-To: <570BD797.9010706@redhat.com> References: <570BD797.9010706@redhat.com> Message-ID: <1EFCC9CF-4D53-4D45-ACA7-743F867694EE@redhat.com> Have you seen the RAFT implementation in jgroups [1]? It maybe helpful to implement the leader election. [1] http://belaban.github.io/jgroups-raft/manual/index.html > On 11 Apr 2016, at 18:57, Brian Stansberry wrote: > > 1) A longstanding request to have automatic failover of the master HC to > a backup. There are different ways to do this, but group communication > based leader election is a possible solution. My preference, really. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160412/33b5cda2/attachment.html From slaskawi at redhat.com Tue Apr 12 05:29:54 2016 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Tue, 12 Apr 2016 11:29:54 +0200 Subject: [wildfly-dev] Inter Host Controller group communication mesh In-Reply-To: <570BD797.9010706@redhat.com> References: <570BD797.9010706@redhat.com> Message-ID: Adding Bela to the thread... The POC looks really nice to me. I could try take it from herre and finish WFLY-1066 implementation to see how everything works together. The only thing that comes into my mind is whether we should (or or not) add capability and server group information to it? I think most of the subsystems would be interested in that. On Mon, Apr 11, 2016 at 6:57 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > Just an FYI: I spent a couple days and worked up a POC[1] of creating a > JGroups-based reliable group communication mesh over the sockets our > Host Controllers use for intra-domain management communications. > > Currently those sockets are used to form a tree of connections; master > HC to slave HCs and then HCs to their servers. Slave HCs don't talk to > each other. That kind of topology works fine for our current use cases, > but not for other use cases, where a full communication mesh is more > appropriate. > > 2 use cases led me to explore this: > > 1) A longstanding request to have automatic failover of the master HC to > a backup. There are different ways to do this, but group communication > based leader election is a possible solution. My preference, really. > > 2) https://issues.jboss.org/browse/WFLY-1066, which has led to various > design alternatives, one of which is a distributed cache of topology > information, available via each HC. See [2] for some of that discussion. > > I don't know if this kind of communication is a good idea, or if it's > the right solution to either of these use cases. Lots of things need > careful thought!! But I figured it was worth some time to experiment. > And it worked in at least a basic POC way, hence this FYI. > > If you're interested in details, here are some Q&A: > > Q: Why JGroups? > > A: Because 1) I know it well 2) I trust it and 3) it's already used for > this kind of group communications in full WildFly. > > Q: Why the management sockets? Why not other sockets? > > A: Slave HCs already need configuration for how to discover the master. > Using the same sockets lets us reuse that discovery configuration for > the JGroups communications as well. If we're going to use this kind of > communication in an serious way, the configuration needs to be as easy > as possible. > > Q: How does it work? > > A: JGroups is based on a stack of "protocols" each of which handles one > aspect of reliable group communications. The POC creates and uses a > standard protocol stack, except it replaces two standard protocols with > custom ones: > > a) JGroups has various "Discovery" protocols which are used to find > possible peers. I implemented one that integrates with the HC's domain > controller discovery logic. It's basically a copy of the oft used > TCPPING protocol with about 10-15 lines of code changed. > > b) JGroups has various "Transport" protocols which are responsible for > actually sending/receiving over the network. I created a new one of > those that knows how to use the WF management comms stuff built on JBoss > Remoting. JGroups provides a number of base classes to use in this > transport area, so I was able to rely on a lot of existing functionality > and could just focus on the details specific to this case. > > Q: What have you done using the POC? > > A: I created a master HC and a slave on my laptop and saw them form a > cluster and exchange messages. Typical stuff like starting and stopping > the HCs worked. I see no reason why having multiple slaves wouldn't have > worked too; I just didn't do it. > > Q: What's next? > > A: Nothing really. We have a couple concrete use cases we're looking to > solve. We need to figure out the best solution for those use cases. If > this kind of thing is useful in that, great. If not, it was a fun POC. > > [1] > > https://github.com/wildfly/wildfly-core/compare/master...bstansberry:jgroups-dc > . See the commit message on the single commit to learn a bit more. > > [2] https://developer.jboss.org/wiki/ADomainManagedServiceRegistry > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160412/e7e99005/attachment-0001.html From remerson at redhat.com Tue Apr 12 05:43:21 2016 From: remerson at redhat.com (Ryan Emerson) Date: Tue, 12 Apr 2016 05:43:21 -0400 (EDT) Subject: [wildfly-dev] Inter Host Controller group communication mesh In-Reply-To: <570BD797.9010706@redhat.com> References: <570BD797.9010706@redhat.com> Message-ID: <963282740.8779544.1460454201156.JavaMail.zimbra@redhat.com> Overall looks good to me, however I have a question about the automatic failover use case, how do you intend to handle split brain scenarios? Example scenarios: You have a network of {Master HC, Slave1, Slave2, Slave3, Slave4, Slave5} and the network splits into two partitions of {Master HC, Slave1, Slave2} and {Slave3, Slave4, Slave5}. Or even three distinct partitions consisting of #2 nodes. If no additional provisions were added, how detrimental would it be if two Master HCs were elected in distinct partitions and the network partitions became one again (resulting in two Master HCs)? ----- Original Message ----- From: "Brian Stansberry" To: wildfly-dev at lists.jboss.org Sent: Monday, 11 April, 2016 5:57:59 PM Subject: [wildfly-dev] Inter Host Controller group communication mesh Just an FYI: I spent a couple days and worked up a POC[1] of creating a JGroups-based reliable group communication mesh over the sockets our Host Controllers use for intra-domain management communications. Currently those sockets are used to form a tree of connections; master HC to slave HCs and then HCs to their servers. Slave HCs don't talk to each other. That kind of topology works fine for our current use cases, but not for other use cases, where a full communication mesh is more appropriate. 2 use cases led me to explore this: 1) A longstanding request to have automatic failover of the master HC to a backup. There are different ways to do this, but group communication based leader election is a possible solution. My preference, really. 2) https://issues.jboss.org/browse/WFLY-1066, which has led to various design alternatives, one of which is a distributed cache of topology information, available via each HC. See [2] for some of that discussion. I don't know if this kind of communication is a good idea, or if it's the right solution to either of these use cases. Lots of things need careful thought!! But I figured it was worth some time to experiment. And it worked in at least a basic POC way, hence this FYI. If you're interested in details, here are some Q&A: Q: Why JGroups? A: Because 1) I know it well 2) I trust it and 3) it's already used for this kind of group communications in full WildFly. Q: Why the management sockets? Why not other sockets? A: Slave HCs already need configuration for how to discover the master. Using the same sockets lets us reuse that discovery configuration for the JGroups communications as well. If we're going to use this kind of communication in an serious way, the configuration needs to be as easy as possible. Q: How does it work? A: JGroups is based on a stack of "protocols" each of which handles one aspect of reliable group communications. The POC creates and uses a standard protocol stack, except it replaces two standard protocols with custom ones: a) JGroups has various "Discovery" protocols which are used to find possible peers. I implemented one that integrates with the HC's domain controller discovery logic. It's basically a copy of the oft used TCPPING protocol with about 10-15 lines of code changed. b) JGroups has various "Transport" protocols which are responsible for actually sending/receiving over the network. I created a new one of those that knows how to use the WF management comms stuff built on JBoss Remoting. JGroups provides a number of base classes to use in this transport area, so I was able to rely on a lot of existing functionality and could just focus on the details specific to this case. Q: What have you done using the POC? A: I created a master HC and a slave on my laptop and saw them form a cluster and exchange messages. Typical stuff like starting and stopping the HCs worked. I see no reason why having multiple slaves wouldn't have worked too; I just didn't do it. Q: What's next? A: Nothing really. We have a couple concrete use cases we're looking to solve. We need to figure out the best solution for those use cases. If this kind of thing is useful in that, great. If not, it was a fun POC. [1] https://github.com/wildfly/wildfly-core/compare/master...bstansberry:jgroups-dc . See the commit message on the single commit to learn a bit more. [2] https://developer.jboss.org/wiki/ADomainManagedServiceRegistry -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Tue Apr 12 09:44:29 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 12 Apr 2016 08:44:29 -0500 Subject: [wildfly-dev] Inter Host Controller group communication mesh In-Reply-To: <1EFCC9CF-4D53-4D45-ACA7-743F867694EE@redhat.com> References: <570BD797.9010706@redhat.com> <1EFCC9CF-4D53-4D45-ACA7-743F867694EE@redhat.com> Message-ID: <570CFBBD.9000805@redhat.com> Yes, I planned to look further into that. On 4/12/16 1:57 AM, Heiko Braun wrote: > > Have you seen the RAFT implementation in jgroups [1]? It maybe helpful > to implement the leader election. > > > [1] http://belaban.github.io/jgroups-raft/manual/index.html > > >> On 11 Apr 2016, at 18:57, Brian Stansberry >> > wrote: >> >> 1) A longstanding request to have automatic failover of the master HC to >> a backup. There are different ways to do this, but group communication >> based leader election is a possible solution. My preference, really. > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Tue Apr 12 09:52:01 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 12 Apr 2016 08:52:01 -0500 Subject: [wildfly-dev] Inter Host Controller group communication mesh In-Reply-To: References: <570BD797.9010706@redhat.com> Message-ID: <570CFD81.7000007@redhat.com> On 4/12/16 4:29 AM, Sebastian Laskawiec wrote: > Adding Bela to the thread... > > The POC looks really nice to me. I could try take it from herre and > finish WFLY-1066 implementation to see how everything works together. > > The only thing that comes into my mind is whether we should (or or not) > add capability and server group information to it? I think most of the > subsystems would be interested in that. > We'd still need a design for exactly how a distributed cache of topology info would work. Using JGroups opens up the possibility of using Infinispan, but the structure of the data in the cache is still TBD. I think capability and server group data will be part of that. We also have to work out how the servers access the cache data. As Ken pointed out having a large TCP mesh might be problematic, so do we want each HC in the cluster, or a subset, with then some other mechanism for the servers accessing the cache? > On Mon, Apr 11, 2016 at 6:57 PM, Brian Stansberry > > wrote: > > Just an FYI: I spent a couple days and worked up a POC[1] of creating a > JGroups-based reliable group communication mesh over the sockets our > Host Controllers use for intra-domain management communications. > > Currently those sockets are used to form a tree of connections; master > HC to slave HCs and then HCs to their servers. Slave HCs don't talk to > each other. That kind of topology works fine for our current use cases, > but not for other use cases, where a full communication mesh is more > appropriate. > > 2 use cases led me to explore this: > > 1) A longstanding request to have automatic failover of the master HC to > a backup. There are different ways to do this, but group communication > based leader election is a possible solution. My preference, really. > > 2) https://issues.jboss.org/browse/WFLY-1066, which has led to various > design alternatives, one of which is a distributed cache of topology > information, available via each HC. See [2] for some of that discussion. > > I don't know if this kind of communication is a good idea, or if it's > the right solution to either of these use cases. Lots of things need > careful thought!! But I figured it was worth some time to experiment. > And it worked in at least a basic POC way, hence this FYI. > > If you're interested in details, here are some Q&A: > > Q: Why JGroups? > > A: Because 1) I know it well 2) I trust it and 3) it's already used for > this kind of group communications in full WildFly. > > Q: Why the management sockets? Why not other sockets? > > A: Slave HCs already need configuration for how to discover the master. > Using the same sockets lets us reuse that discovery configuration for > the JGroups communications as well. If we're going to use this kind of > communication in an serious way, the configuration needs to be as easy > as possible. > > Q: How does it work? > > A: JGroups is based on a stack of "protocols" each of which handles one > aspect of reliable group communications. The POC creates and uses a > standard protocol stack, except it replaces two standard protocols with > custom ones: > > a) JGroups has various "Discovery" protocols which are used to find > possible peers. I implemented one that integrates with the HC's domain > controller discovery logic. It's basically a copy of the oft used > TCPPING protocol with about 10-15 lines of code changed. > > b) JGroups has various "Transport" protocols which are responsible for > actually sending/receiving over the network. I created a new one of > those that knows how to use the WF management comms stuff built on JBoss > Remoting. JGroups provides a number of base classes to use in this > transport area, so I was able to rely on a lot of existing functionality > and could just focus on the details specific to this case. > > Q: What have you done using the POC? > > A: I created a master HC and a slave on my laptop and saw them form a > cluster and exchange messages. Typical stuff like starting and stopping > the HCs worked. I see no reason why having multiple slaves wouldn't have > worked too; I just didn't do it. > > Q: What's next? > > A: Nothing really. We have a couple concrete use cases we're looking to > solve. We need to figure out the best solution for those use cases. If > this kind of thing is useful in that, great. If not, it was a fun POC. > > [1] > https://github.com/wildfly/wildfly-core/compare/master...bstansberry:jgroups-dc > . See the commit message on the single commit to learn a bit more. > > [2] https://developer.jboss.org/wiki/ADomainManagedServiceRegistry > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Tue Apr 12 12:49:20 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 12 Apr 2016 11:49:20 -0500 Subject: [wildfly-dev] Inter Host Controller group communication mesh In-Reply-To: <963282740.8779544.1460454201156.JavaMail.zimbra@redhat.com> References: <570BD797.9010706@redhat.com> <963282740.8779544.1460454201156.JavaMail.zimbra@redhat.com> Message-ID: <570D2710.2050507@redhat.com> On 4/12/16 4:43 AM, Ryan Emerson wrote: > Overall looks good to me, however I have a question about the automatic failover use case, how do you intend to handle split brain scenarios? > My basic thought was to require a quorum and if no quorum is available, provide a degraded level of service. A degraded level of service probably means no master. A domain can function with no master. I can brainstorm about possible slight enhancements to service beyond that, but I question whether they are worth the effort, at least initially. > Example scenarios: You have a network of {Master HC, Slave1, Slave2, Slave3, Slave4, Slave5} and the network splits into two partitions of {Master HC, Slave1, Slave2} and {Slave3, Slave4, Slave5}. Or even three distinct partitions consisting of #2 nodes. > I think we need a 3rd conceptual type -- a Potential Master. Not just any HC can become master. It has to: 1) Be the latest version. 2) Be configured such that it's keeping a complete set of the domain config and any domain managed content. 3) Is configured to use the group communication service used for leader election. 4) Most likely it would also have specific config saying it can be a master. I doubt this is something users will want to leave to chance. So, electing a leader requires a quorum of Potential Masters. > If no additional provisions were added, how detrimental would it be if two Master HCs were elected in distinct partitions and the network partitions became one again (resulting in two Master HCs)? > Two masters means two potentially inconsistent domain configurations (i.e. domain.xml and content repo) are possible. We don't want that, hence the quorum requirement. A question is what should slave HCs do in the absence of a master. They are isolated from control by a master, but don't know if there is still a functioning set of DC+slaves out there, meaning the slaves may be missing relevant config changes. Should they shut down, or keep going? We already have this issue though, and we've elected to have the slaves keep going, updating their config if they can reconnect to a master. We chose to keep the appservers running, and not to have them be vulnerable to problems with master-slave connectivity. Having autopromotion of a new master makes it slightly more valid to just shut down, since going masterless is less likely, but I still think it's not a good idea. > ----- Original Message ----- > From: "Brian Stansberry" > To: wildfly-dev at lists.jboss.org > Sent: Monday, 11 April, 2016 5:57:59 PM > Subject: [wildfly-dev] Inter Host Controller group communication mesh > > Just an FYI: I spent a couple days and worked up a POC[1] of creating a > JGroups-based reliable group communication mesh over the sockets our > Host Controllers use for intra-domain management communications. > > Currently those sockets are used to form a tree of connections; master > HC to slave HCs and then HCs to their servers. Slave HCs don't talk to > each other. That kind of topology works fine for our current use cases, > but not for other use cases, where a full communication mesh is more > appropriate. > > 2 use cases led me to explore this: > > 1) A longstanding request to have automatic failover of the master HC to > a backup. There are different ways to do this, but group communication > based leader election is a possible solution. My preference, really. > > 2) https://issues.jboss.org/browse/WFLY-1066, which has led to various > design alternatives, one of which is a distributed cache of topology > information, available via each HC. See [2] for some of that discussion. > > I don't know if this kind of communication is a good idea, or if it's > the right solution to either of these use cases. Lots of things need > careful thought!! But I figured it was worth some time to experiment. > And it worked in at least a basic POC way, hence this FYI. > > If you're interested in details, here are some Q&A: > > Q: Why JGroups? > > A: Because 1) I know it well 2) I trust it and 3) it's already used for > this kind of group communications in full WildFly. > > Q: Why the management sockets? Why not other sockets? > > A: Slave HCs already need configuration for how to discover the master. > Using the same sockets lets us reuse that discovery configuration for > the JGroups communications as well. If we're going to use this kind of > communication in an serious way, the configuration needs to be as easy > as possible. > > Q: How does it work? > > A: JGroups is based on a stack of "protocols" each of which handles one > aspect of reliable group communications. The POC creates and uses a > standard protocol stack, except it replaces two standard protocols with > custom ones: > > a) JGroups has various "Discovery" protocols which are used to find > possible peers. I implemented one that integrates with the HC's domain > controller discovery logic. It's basically a copy of the oft used > TCPPING protocol with about 10-15 lines of code changed. > > b) JGroups has various "Transport" protocols which are responsible for > actually sending/receiving over the network. I created a new one of > those that knows how to use the WF management comms stuff built on JBoss > Remoting. JGroups provides a number of base classes to use in this > transport area, so I was able to rely on a lot of existing functionality > and could just focus on the details specific to this case. > > Q: What have you done using the POC? > > A: I created a master HC and a slave on my laptop and saw them form a > cluster and exchange messages. Typical stuff like starting and stopping > the HCs worked. I see no reason why having multiple slaves wouldn't have > worked too; I just didn't do it. > > Q: What's next? > > A: Nothing really. We have a couple concrete use cases we're looking to > solve. We need to figure out the best solution for those use cases. If > this kind of thing is useful in that, great. If not, it was a fun POC. > > [1] > https://github.com/wildfly/wildfly-core/compare/master...bstansberry:jgroups-dc > . See the commit message on the single commit to learn a bit more. > > [2] https://developer.jboss.org/wiki/ADomainManagedServiceRegistry > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From manderse at redhat.com Wed Apr 13 06:40:49 2016 From: manderse at redhat.com (Max Rydahl Andersen) Date: Wed, 13 Apr 2016 12:40:49 +0200 Subject: [wildfly-dev] Question on jboss-app_7_0.xsd and why it inherits from application_6.xsd In-Reply-To: <570B4F1B.5070605@redhat.com> References: <5707B394.2070906@redhat.com> <570B4F1B.5070605@redhat.com> Message-ID: On 11 Apr 2016, at 9:15, Marek Novotny wrote: > Isn't JBoss AS 7.x compliant to Java EE 6 specs which is the XSD > schema > there referenced/imported from Sun? > > I guess you mixed Java EE 6 with JBoss AS 7 versions here. Rob - is the error you see on the jboss-application.xml you wrote or in the included xsd ? What 7.0 are you trying to set/add ? /max > > On 8.4.2016 15:35, Rob Stryker wrote: >> While investigating a jira >> (https://issues.jboss.org/browse/JBIDE-22141) >> I tried to make a minimalist jboss-application xml, and it had a >> really >> strange validation error: >> >> cvc-complex-type.3.1: Value '7.0' of attribute 'version' of element >> 'jboss-app' is not valid with respect to the corresponding attribute >> use. Attribute 'version' has a fixed value of '6'. >> >> When I dug into the current jboss-app_7_0.xsd to see what was going >> on >> (https://github.com/jboss/metadata/blob/master/ear/src/main/resources/schema/jboss-app_7_0.xsd) >> I saw the following: >> >> >> >> >> > schemaLocation="application_6.xsd"/> >> >> >> >> >> >> >> Shouldn't this be pulling from application_7.xsd at least? Also we >> don't seem to have a jboss-common_7_0.xsd. So these version >> inconsistancies are really angering the eclipse validator. >> >> Is there anything that can be done here at all? It really seems our >> schema have this recurring problem of not validating in eclipse, and >> often times it seems the problems lead back to our very own schema as >> the cause. It ends up causing errors in eclipse and our users get >> very >> confused why all our example projects or snippets of xml on redhat >> access often fail to validate. >> >> - Rob Stryker >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > -- > Marek Novotny > -- > Windup team member and Seam Project Lead > > Red Hat Czech s.r.o. > Purkynova 99 > 612 45 Brno > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev /max http://about.me/maxandersen From tomaz.cerar at gmail.com Wed Apr 13 07:15:03 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 13 Apr 2016 13:15:03 +0200 Subject: [wildfly-dev] undertow filters In-Reply-To: References: <57066CB3.9030803@redhat.com> Message-ID: On Thu, Apr 7, 2016 at 5:13 PM, Claudio Miranda wrote: > > This is what WFCORE-1106 is all about. > > > Thank you Brian In any case WFCORE-1106 is not really related to the problem you are seeing, beyond improving usability once it happens. You are ignoring the response you get from there server, as once you do remove filter, server says "reload-required" which means that before you can re-add filter with same name again you should reload server, or do this kind of operations in admin mode (not sure what your use case is). Said all that, looking at code it should be quite trivial to fix the code to no require reload on remove, so can you file jira to WFLY project and assign it to me. -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160413/fd84ba6c/attachment.html From rory.odonnell at oracle.com Fri Apr 15 04:41:09 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 15 Apr 2016 09:41:09 +0100 Subject: [wildfly-dev] Early Access builds of JDK 9 b113 & JDK 9 with Project Jigsaw b113 (#4848) are available on java.net Message-ID: <5710A925.60301@oracle.com> Hi Jason/Tomaz, Early Access b113 for JDK 9 is available on java.net, summary of changes are listed here . Early Access b113 (#4664) for JDK 9 with Project Jigsaw is available on java.net. * The important change in this build is that root modules when compiling code in the unnamed module, or when running and the main class is loaded from the class path, do not include the EE modules. More on this in JEP 261. * The other change in this build is that the -Xpatch option is now aligned with what we have documented in JEP 261, support for the old form has been removed. We are very interested in hearing your experiences in testing any Early Access builds. Have you have begun testing against JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered showstopper issues that you would like to discuss? We would really like to hear your findings so far, either reply to me or via the mailing lists [1], [2]. Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/ [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/ -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160415/7c539824/attachment.html From tomaz.cerar at gmail.com Fri Apr 15 05:44:13 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 15 Apr 2016 11:44:13 +0200 Subject: [wildfly-dev] Early Access builds of JDK 9 b113 & JDK 9 with Project Jigsaw b113 (#4848) are available on java.net In-Reply-To: <5710A925.60301@oracle.com> References: <5710A925.60301@oracle.com> Message-ID: Hey Rory, I've installed b113 on our CI yesterday and can happily report that wildfly-core testsuite now passses completly see https://ci.wildfly.org/viewLog.html?buildId=14254&tab=buildResultsDiv&buildTypeId=WildFlyCore_MasterLinuxJdk9 for details For now it is build from custom branch https://github.com/ctomc/wildfly-core/tree/jigsaw but we are working on integrating this into master. Once this is complete we will continue with WildFly full -- tomaz On Fri, Apr 15, 2016 at 10:41 AM, Rory O'Donnell wrote: > > Hi Jason/Tomaz, > > Early Access b113 for JDK 9 is > available on java.net, summary of changes are listed here > . > > Early Access b113 (#4664) for JDK 9 with > Project Jigsaw is available on java.net. > > - The important change in this build is that root modules when > compiling code in the unnamed module, or when running and the main class is > loaded from the class path, do not include the EE modules. More on this in > JEP 261. > - The other change in this build is that the -Xpatch option is now > aligned with what we have documented in JEP 261, support for the old form > has been removed. > > We are very interested in hearing your experiences in testing any Early > Access builds. Have you have begun testing against > JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered > showstopper issues that you would like to discuss? > We would really like to hear your findings so far, either reply to me or > via the mailing lists [1], [2]. > > Rgds,Rory > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/ > [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/ > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA, Dublin,Ireland > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160415/4077a715/attachment.html From rory.odonnell at oracle.com Fri Apr 15 06:01:10 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 15 Apr 2016 11:01:10 +0100 Subject: [wildfly-dev] Early Access builds of JDK 9 b113 & JDK 9 with Project Jigsaw b113 (#4848) are available on java.net In-Reply-To: References: <5710A925.60301@oracle.com> Message-ID: <5710BBE6.7090706@oracle.com> On 15/04/2016 10:44, Toma? Cerar wrote: > Hey Rory, > > I've installed b113 on our CI yesterday and can happily report that > wildfly-core testsuite now passses completly > see > https://ci.wildfly.org/viewLog.html?buildId=14254&tab=buildResultsDiv&buildTypeId=WildFlyCore_MasterLinuxJdk9 > for details Cool! > > For now it is build from custom branch > https://github.com/ctomc/wildfly-core/tree/jigsaw but we are working > on integrating this into master. That's great, thanks for the update. Rgds,Rory > > Once this is complete we will continue with WildFly full > > -- > tomaz > > > On Fri, Apr 15, 2016 at 10:41 AM, Rory O'Donnell > > wrote: > > > Hi Jason/Tomaz, > > Early Access b113 for JDK 9 is > available on java.net , summary of changes are > listed here > . > > Early Access b113 (#4664) for JDK > 9 with Project Jigsaw is available on java.net . > > * The important change in this build is that root modules when > compiling code in the unnamed module, or when running and the > main class is loaded from the class path, do not include the > EE modules. More on this in JEP 261. > * The other change in this build is that the -Xpatch option is > now aligned with what we have documented in JEP 261, support > for the old form has been removed. > > We are very interested in hearing your experiences in testing any > Early Access builds. Have you have begun testing against > JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you > uncovered showstopper issues that you would like to discuss? > We would really like to hear your findings so far, either reply to > me or via the mailing lists [1], [2]. > > Rgds,Rory > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/ > [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/ > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA, Dublin,Ireland > > -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160415/e2ed86ae/attachment-0001.html From brian.stansberry at redhat.com Mon Apr 18 11:04:57 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 18 Apr 2016 10:04:57 -0500 Subject: [wildfly-dev] Inter Host Controller group communication mesh In-Reply-To: <570C1502.4000808@redhat.com> References: <570BD797.9010706@redhat.com> <570C1502.4000808@redhat.com> Message-ID: <5714F799.1070708@redhat.com> As an FYI, copying Bela Ban, who I stupidly forgot to copy on the first post. Sebastian kindly copied him on the other main branch of the thread. Bela, tl;dr on this branch is it mostly discusses concerns about N^2 TCP connections in a possibly very large cluster. Whether the JGroups cluster would need to get very large depends on what use cases we used it to solve. On 4/11/16 4:20 PM, Brian Stansberry wrote: > On 4/11/16 3:43 PM, Ken Wills wrote: >> >> >> On Mon, Apr 11, 2016 at 11:57 AM, Brian Stansberry >> > wrote: >> >> Just an FYI: I spent a couple days and worked up a POC[1] of creating a >> JGroups-based reliable group communication mesh over the sockets our >> Host Controllers use for intra-domain management communications. >> >> >> Nice! I've been thinking about the mechanics of this a bit recently, but >> I hadn't gotten to any sort of transport details, this looks interesting. >> >> Currently those sockets are used to form a tree of connections; master >> HC to slave HCs and then HCs to their servers. Slave HCs don't talk to >> each other. That kind of topology works fine for our current use cases, >> but not for other use cases, where a full communication mesh is more >> appropriate. >> >> 2 use cases led me to explore this: >> >> 1) A longstanding request to have automatic failover of the master HC to >> a backup. There are different ways to do this, but group communication >> based leader election is a possible solution. My preference, really. >> >> >> I'd come to the same conclusion of it being an election. A deterministic >> election algorithm, perhaps allowing the configuration to supply some >> sort of weighted value to influence the election on each node, perhaps >> analogous to how the master browser smb election works (version + weight >> + etc). > > Yep. > > For sure the master must be running the latest version. > >> >> >> 2) https://issues.jboss.org/browse/WFLY-1066, which has led to various >> design alternatives, one of which is a distributed cache of topology >> information, available via each HC. See [2] for some of that discussion. >> >> I don't know if this kind of communication is a good idea, or if it's >> the right solution to either of these use cases. Lots of things need >> careful thought!! But I figured it was worth some time to experiment. >> And it worked in at least a basic POC way, hence this FYI. >> >> >> Not knowing a lot about jgroups .. for very large domains is the mesh >> NxN in size? > > Yes. > > For thousands of nodes would this become a problem, > > It's one concern I have, yes. There are large JGroups clusters, but they > may be based on the UDP multicast transport JGroups offers. > >> or would >> a mechanism to segment into local groups perhaps, with only certain >> nodes participating in the mesh and being eligible for election? > > > For sure we'd have something in the host.xml that controls whether a > particular HC joins the group. > > I don't think this is a big problem for the DC election use case, as you > don't need a large number of HCs in the group. You'd have a few > "potential" DCs that could join the group, and the remaining slaves > don't need to. > > For use cases where you want slave HCs to be in the cluster though, it's > a concern. The distributed topology cache thing may or may not need > that. It needs a few HCs to provide HA, but those could be the same ones > that are "potential" HCs. But if only a few are in the group, the > servers need to be told how to reach those HCs. Chicken and egg, as the > point of the topology cache is to provide that kind of data to servers! > If a server's own HC is required to be a part of the group though, that > helps cut through the chicken/egg problem. > > >> Ken >> > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Mon Apr 18 16:44:28 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 18 Apr 2016 15:44:28 -0500 Subject: [wildfly-dev] Inter Host Controller group communication mesh In-Reply-To: <5714FABA.5070001@redhat.com> References: <570BD797.9010706@redhat.com> <570C1502.4000808@redhat.com> <5714F799.1070708@redhat.com> <5714FABA.5070001@redhat.com> Message-ID: <5715472C.90905@redhat.com> On 4/18/16 10:18 AM, Bela Ban wrote: > Hey Brian, > > On 18/04/16 17:04, Brian Stansberry wrote: >> As an FYI, copying Bela Ban, who I stupidly forgot to copy on the first >> post. Sebastian kindly copied him on the other main branch of the thread. > > Yes, I read that thread. > >> Bela, tl;dr on this branch is it mostly discusses concerns about N^2 TCP >> connections in a possibly very large cluster. Whether the JGroups >> cluster would need to get very large depends on what use cases we used >> it to solve. > > When I tested on a 2000+ node cluster running over TCP in Google Compute > Engine, TCP wasn't that much of an issue. Good! > The main drawbacks were that > every node needed to have ~2000 connections open, which means 1 reader > thread running per connection. However, connections are closed after a > configurable idle time. > > TCP_NIO2 is much better in that respect as it gets rid of the reader > threads even if the connection is open. > In the POC I did, the transport uses the NIO-based JBoss Remoting infrastructure we already use for intra-domain communications. All connections are created using a single remoting Endpoint instance, which in turn uses a Xnio worker. That worker is configured with two io threads, and then a pool of 5 min, max 10 threads for handling tasks. That pool size is just the settings that were already in the code for the existing uses of the endpoint (CLI requests, intra-domain comms etc) and I spent zero time when I did the POC thinking about whether those settings are appropriate if we also add JGroups traffic to the mix. For the existing management uses of the endpoint, most of the work actually gets shunted off to threads from a separate pool. A management request comes in and the xnio worker threads deal with the initial work of reading it off the wire or writing the response, but the bulk of the work in between of actually doing the management stuff is done on another thread. I'd need to refamiliarize myself with TP and the thread pools JGroups uses to see if we get a similar effect with the JGroups communications. I have some vague memories of up pools and down pools and OOB pools and .... ;) All surely out of date. > The other option is to use UDP without multicasting, ie. ip_mcast=false. > This would not create N-1 connections and possibly N-1 reader threads > and sockets, but only 2 sockets (constant) and no reader threads. A > message would still need to be sent N-1 times though, creating increased > traffic. > I don't think we could do that, at least not with this approach using the existing JBoss Remoting server sockets. That's all TCP based. > A potential solution for going from N-1 to a constant number of > connections/threads would be daisy chaining where you only connect to > your neighbor and a multicast basically is 1 round across the logical > overlay, see [1] for details. I'd have to revisit this protocol though > if you wanted to use it, so let me know asap for me to include this in > the roadmap. Ok, good to know. Will do. > Cheers, > > [1] http://belaban.blogspot.ch/2010/08/daisychaining-in-clouds.html > >> On 4/11/16 4:20 PM, Brian Stansberry wrote: >>> On 4/11/16 3:43 PM, Ken Wills wrote: >>>> >>>> >>>> On Mon, Apr 11, 2016 at 11:57 AM, Brian Stansberry >>>> > >>>> wrote: >>>> >>>> Just an FYI: I spent a couple days and worked up a POC[1] of >>>> creating a >>>> JGroups-based reliable group communication mesh over the sockets >>>> our >>>> Host Controllers use for intra-domain management communications. >>>> >>>> >>>> Nice! I've been thinking about the mechanics of this a bit recently, >>>> but >>>> I hadn't gotten to any sort of transport details, this looks >>>> interesting. >>>> >>>> Currently those sockets are used to form a tree of connections; >>>> master >>>> HC to slave HCs and then HCs to their servers. Slave HCs don't >>>> talk to >>>> each other. That kind of topology works fine for our current use >>>> cases, >>>> but not for other use cases, where a full communication mesh is >>>> more >>>> appropriate. >>>> >>>> 2 use cases led me to explore this: >>>> >>>> 1) A longstanding request to have automatic failover of the >>>> master HC to >>>> a backup. There are different ways to do this, but group >>>> communication >>>> based leader election is a possible solution. My preference, >>>> really. >>>> >>>> >>>> I'd come to the same conclusion of it being an election. A >>>> deterministic >>>> election algorithm, perhaps allowing the configuration to supply some >>>> sort of weighted value to influence the election on each node, perhaps >>>> analogous to how the master browser smb election works (version + >>>> weight >>>> + etc). >>> >>> Yep. >>> >>> For sure the master must be running the latest version. >>> >>>> >>>> >>>> 2) https://issues.jboss.org/browse/WFLY-1066, which has led to >>>> various >>>> design alternatives, one of which is a distributed cache of >>>> topology >>>> information, available via each HC. See [2] for some of that >>>> discussion. >>>> >>>> I don't know if this kind of communication is a good idea, or if >>>> it's >>>> the right solution to either of these use cases. Lots of things >>>> need >>>> careful thought!! But I figured it was worth some time to >>>> experiment. >>>> And it worked in at least a basic POC way, hence this FYI. >>>> >>>> >>>> Not knowing a lot about jgroups .. for very large domains is the mesh >>>> NxN in size? >>> >>> Yes. >>> >>> For thousands of nodes would this become a problem, >>> >>> It's one concern I have, yes. There are large JGroups clusters, but they >>> may be based on the UDP multicast transport JGroups offers. >>> >>>> or would >>>> a mechanism to segment into local groups perhaps, with only certain >>>> nodes participating in the mesh and being eligible for election? >>> >>> >>> For sure we'd have something in the host.xml that controls whether a >>> particular HC joins the group. >>> >>> I don't think this is a big problem for the DC election use case, as you >>> don't need a large number of HCs in the group. You'd have a few >>> "potential" DCs that could join the group, and the remaining slaves >>> don't need to. >>> >>> For use cases where you want slave HCs to be in the cluster though, it's >>> a concern. The distributed topology cache thing may or may not need >>> that. It needs a few HCs to provide HA, but those could be the same ones >>> that are "potential" HCs. But if only a few are in the group, the >>> servers need to be told how to reach those HCs. Chicken and egg, as the >>> point of the topology cache is to provide that kind of data to servers! >>> If a server's own HC is required to be a part of the group though, that >>> helps cut through the chicken/egg problem. >>> >>> >>>> Ken >>>> >>> >>> >> >> > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From marko.luksa at gmail.com Wed Apr 20 10:58:46 2016 From: marko.luksa at gmail.com (=?UTF-8?Q?Marko_Luk=c5=a1a?=) Date: Wed, 20 Apr 2016 16:58:46 +0200 Subject: [wildfly-dev] Graceful shutdown on SIGTERM? Message-ID: <57179926.1070805@gmail.com> Any plans to hook graceful shutdown to SIGTERM or is the plan to always require the CLI for this? Regards Marko From brian.stansberry at redhat.com Wed Apr 20 11:52:11 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 20 Apr 2016 10:52:11 -0500 Subject: [wildfly-dev] Graceful shutdown on SIGTERM? In-Reply-To: <57179926.1070805@gmail.com> References: <57179926.1070805@gmail.com> Message-ID: <5717A5AB.8040900@redhat.com> I'm not aware of any plans, but it's doable via a change to BootstrapImpl.ShutdownHook, which would need to add some logic similar to what ServerShutdownHandler does. The basic question is what's the timeout? I'm not motivated to make that be configurable, but some hardcoded small number like 5 secs could be reasonable. On 4/20/16 9:58 AM, Marko Luk?a wrote: > Any plans to hook graceful shutdown to SIGTERM or is the plan to always > require the CLI for this? > > Regards > Marko > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From stuart.w.douglas at gmail.com Wed Apr 20 22:05:57 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 21 Apr 2016 02:05:57 +0000 Subject: [wildfly-dev] Graceful startup Message-ID: Hi, I have come across a few bug reports [1][2] (and a feature request from the Swarm team) recently that are essentially caused by an application being accessed before it is fully deployed. Basically even though we have service dependencies that make sure individual components dependencies are up, once a request has been accepted it can potentially programmatically access other parts of the deployment that are not up yet (basically the same problem we have with graceful shutdown, but in reverse). I propose we solve this using a 'graceful startup' mechanism, that holds or rejects new requests until a server or deployment is fully started. The specifics of how this would work are: - If the server is booting all external requests will be held or rejected until the the boot process is complete - When deploying a new deployment all requests for that deployment will be held or rejected until MSC has attained stability This would be implemented for the following endpoints/subsystems: - Undertow will hold requests until the deployment is done (so if you try and load a page while deployment is happening it could be a bit of a wait) - Remote EJB will hold requests until deployment is done - mod_cluster will not send availability messages until deployment is done - JMS will delay message delivery until deployment is done - EJB persistent timers will not fire until deployment is done - Possibly some other cases I can't think of right now One thing I am not really sure about is if we need a configuration switch for hold/reject behavior. e.g. for Undertow the request holding behavior is very developer friendly, as it means they can just hit refresh in their browser and as soon as the redeployment is done the page will display, however I am worried that it might not be ideal for load balancers that may prefer a quick error response that could then be attempted on another node (although if mod_cluster is not sending out availability till the deployment is 100% complete this may not be a big deal). If you want to see this in action I have a very simple PR at [3] that enables this for Undertow at server boot. Thoughts? Stuart [1] https://issues.jboss.org/browse/WFLY-6402 [2] https://issues.jboss.org/browse/JBEAP-867 [3] https://github.com/wildfly/wildfly/pull/8858 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160421/b0e82a6f/attachment.html From tomaz.cerar at gmail.com Thu Apr 21 05:49:35 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 21 Apr 2016 11:49:35 +0200 Subject: [wildfly-dev] Graceful startup In-Reply-To: References: Message-ID: On Thu, Apr 21, 2016 at 4:05 AM, Stuart Douglas wrote: > One thing I am not really sure about is if we need a configuration switch > for hold/reject behavior. e.g. for Undertow the request holding behavior is > very developer friendly, as it means they can just hit refresh in their > browser and as soon as the redeployment is done the page will display, > however I am worried that it might not be ideal for load balancers that may > prefer a quick error response that could then be attempted on another node > (although if mod_cluster is not sending out availability till the > deployment is 100% complete this may not be a big deal). Wouldn't for load balancers be better to just return 503 instead? This is similar to what we have with "default-response-code" config for host, with only difference being that would also make sure other subsystems are up as well. -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160421/e782f5bb/attachment-0001.html From david.lloyd at redhat.com Thu Apr 21 07:50:47 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 21 Apr 2016 06:50:47 -0500 Subject: [wildfly-dev] Graceful startup In-Reply-To: References: Message-ID: <5718BE97.9010405@redhat.com> On 04/20/2016 09:05 PM, Stuart Douglas wrote: > Hi, > > I have come across a few bug reports [1][2] (and a feature request from > the Swarm team) recently that are essentially caused by an application > being accessed before it is fully deployed. Basically even though we > have service dependencies that make sure individual components > dependencies are up, once a request has been accepted it can potentially > programmatically access other parts of the deployment that are not up > yet (basically the same problem we have with graceful shutdown, but in > reverse). > > I propose we solve this using a 'graceful startup' mechanism, that holds > or rejects new requests until a server or deployment is fully started. > The specifics of how this would work are: > > - If the server is booting all external requests will be held or > rejected until the the boot process is complete > - When deploying a new deployment all requests for that deployment will > be held or rejected until MSC has attained stability > > This would be implemented for the following endpoints/subsystems: > > - Undertow will hold requests until the deployment is done (so if you > try and load a page while deployment is happening it could be a bit of a > wait) > - Remote EJB will hold requests until deployment is done > - mod_cluster will not send availability messages until deployment is done > - JMS will delay message delivery until deployment is done > - EJB persistent timers will not fire until deployment is done > - Possibly some other cases I can't think of right now > > One thing I am not really sure about is if we need a configuration > switch for hold/reject behavior. e.g. for Undertow the request holding > behavior is very developer friendly, as it means they can just hit > refresh in their browser and as soon as the redeployment is done the > page will display, however I am worried that it might not be ideal for > load balancers that may prefer a quick error response that could then be > attempted on another node (although if mod_cluster is not sending out > availability till the deployment is 100% complete this may not be a big > deal). I think load balancers should not have a server that is being started up in the rotation anyway; this already probably doesn't work great today. I like the idea overall. -- - DML From rstryker at redhat.com Thu Apr 21 12:08:05 2016 From: rstryker at redhat.com (Rob Stryker) Date: Thu, 21 Apr 2016 12:08:05 -0400 Subject: [wildfly-dev] question on jboss-app_7_0.xsd intermingling jee versions Message-ID: <5718FAE5.2020307@redhat.com> Hi guys: I recently opened https://issues.jboss.org/browse/JBMETA-394 because it seems our application schema are intermingling jee versions between ee6 and ee7, and it's causing problems for our eclipse validators. Who's in charge of these schema, specifically? Who would be the right person to ping to get it fixed? - Rob Stryker From rstryker at redhat.com Thu Apr 21 12:13:51 2016 From: rstryker at redhat.com (Rob Stryker) Date: Thu, 21 Apr 2016 12:13:51 -0400 Subject: [wildfly-dev] question on jboss-app_7_0.xsd intermingling jee versions In-Reply-To: <5718FAE5.2020307@redhat.com> References: <5718FAE5.2020307@redhat.com> Message-ID: <5718FC3F.4020300@redhat.com> Ok, seems I missed some responses before. > Max Anderson wrote: Rob - is the error you see on the jboss-application.xml you wrote or in the included xsd ? I opened https://issues.jboss.org/browse/JBMETA-394 for a more clear explanation as to the specific error. The error is in a user's jboss-application.xml. > Marek wrote: I guess you mixed Java EE 6 with JBoss AS 7 versions here. I'll try to find out where the example is coming from. If it's from one of our published examples, then I would guess it needs to be fixed there. Looking at the released versions of jboss-app_x_y.xsd, it would seem Marek is probably right and the versions there match the jboss/wf releases, and not the ee version. I'll dig deeper. Thanks. On 04/21/2016 12:08 PM, Rob Stryker wrote: > Hi guys: > > I recently opened https://issues.jboss.org/browse/JBMETA-394 because it > seems our application schema are intermingling jee versions between ee6 > and ee7, and it's causing problems for our eclipse validators. > > Who's in charge of these schema, specifically? Who would be the right > person to ping to get it fixed? > > - Rob Stryker > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Thu Apr 21 14:44:48 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 21 Apr 2016 13:44:48 -0500 Subject: [wildfly-dev] Graceful startup In-Reply-To: References: Message-ID: <57191FA0.9070800@redhat.com> On 4/20/16 9:05 PM, Stuart Douglas wrote: > Hi, > > I have come across a few bug reports [1][2] (and a feature request from > the Swarm team) recently that are essentially caused by an application > being accessed before it is fully deployed. Basically even though we > have service dependencies that make sure individual components > dependencies are up, once a request has been accepted it can potentially > programmatically access other parts of the deployment that are not up > yet (basically the same problem we have with graceful shutdown, but in > reverse). > > I propose we solve this using a 'graceful startup' mechanism, that holds > or rejects new requests until a server or deployment is fully started. > The specifics of how this would work are: > > - If the server is booting all external requests will be held or > rejected until the the boot process is complete > - When deploying a new deployment all requests for that deployment will > be held or rejected until MSC has attained stability > > This would be implemented for the following endpoints/subsystems: > > - Undertow will hold requests until the deployment is done (so if you > try and load a page while deployment is happening it could be a bit of a > wait) > - Remote EJB will hold requests until deployment is done > - mod_cluster will not send availability messages until deployment is done Isn't this what mod_cluster does on a per-deployment basis anyway? The basic idea of mod_cluster is the LB isn't notified the context is available on a backend server until it's....available. > - JMS will delay message delivery until deployment is done > - EJB persistent timers will not fire until deployment is done > - Possibly some other cases I can't think of right now > > One thing I am not really sure about is if we need a configuration > switch for hold/reject behavior. e.g. for Undertow the request holding > behavior is very developer friendly, as it means they can just hit > refresh in their browser and as soon as the redeployment is done the > page will display, however I am worried that it might not be ideal for > load balancers that may prefer a quick error response that could then be > attempted on another node (although if mod_cluster is not sending out > availability till the deployment is 100% complete this may not be a big > deal). > > If you want to see this in action I have a very simple PR at [3] that > enables this for Undertow at server boot. > > Thoughts? > > Stuart > > [1] https://issues.jboss.org/browse/WFLY-6402 > [2] https://issues.jboss.org/browse/JBEAP-867 > [3] https://github.com/wildfly/wildfly/pull/8858 > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jdoyle at redhat.com Thu Apr 21 15:07:18 2016 From: jdoyle at redhat.com (John Doyle) Date: Thu, 21 Apr 2016 15:07:18 -0400 Subject: [wildfly-dev] Graceful startup In-Reply-To: <57191FA0.9070800@redhat.com> References: <57191FA0.9070800@redhat.com> Message-ID: On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry wrote: > On 4/20/16 9:05 PM, Stuart Douglas wrote: >> Hi, >> >> I have come across a few bug reports [1][2] (and a feature request from >> the Swarm team) recently that are essentially caused by an application >> being accessed before it is fully deployed. Basically even though we >> have service dependencies that make sure individual components >> dependencies are up, once a request has been accepted it can potentially >> programmatically access other parts of the deployment that are not up >> yet (basically the same problem we have with graceful shutdown, but in >> reverse). >> >> I propose we solve this using a 'graceful startup' mechanism, that holds >> or rejects new requests until a server or deployment is fully started. >> The specifics of how this would work are: >> >> - If the server is booting all external requests will be held or >> rejected until the the boot process is complete >> - When deploying a new deployment all requests for that deployment will >> be held or rejected until MSC has attained stability >> >> This would be implemented for the following endpoints/subsystems: >> >> - Undertow will hold requests until the deployment is done (so if you >> try and load a page while deployment is happening it could be a bit of a >> wait) >> - Remote EJB will hold requests until deployment is done >> - mod_cluster will not send availability messages until deployment is done > > Isn't this what mod_cluster does on a per-deployment basis anyway? The > basic idea of mod_cluster is the LB isn't notified the context is > available on a backend server until it's....available. True, but not everyone is using mod_cluster. > >> - JMS will delay message delivery until deployment is done >> - EJB persistent timers will not fire until deployment is done >> - Possibly some other cases I can't think of right now >> >> One thing I am not really sure about is if we need a configuration >> switch for hold/reject behavior. e.g. for Undertow the request holding >> behavior is very developer friendly, as it means they can just hit >> refresh in their browser and as soon as the redeployment is done the >> page will display, however I am worried that it might not be ideal for >> load balancers that may prefer a quick error response that could then be >> attempted on another node (although if mod_cluster is not sending out >> availability till the deployment is 100% complete this may not be a big >> deal). >> >> If you want to see this in action I have a very simple PR at [3] that >> enables this for Undertow at server boot. >> >> Thoughts? >> >> Stuart >> >> [1] https://issues.jboss.org/browse/WFLY-6402 >> [2] https://issues.jboss.org/browse/JBEAP-867 >> [3] https://github.com/wildfly/wildfly/pull/8858 >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Thu Apr 21 16:39:56 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 21 Apr 2016 15:39:56 -0500 Subject: [wildfly-dev] Graceful startup In-Reply-To: References: <57191FA0.9070800@redhat.com> Message-ID: <57193A9C.1040103@redhat.com> On 4/21/16 2:07 PM, John Doyle wrote: > On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry > wrote: >> On 4/20/16 9:05 PM, Stuart Douglas wrote: >>> Hi, >>> >>> I have come across a few bug reports [1][2] (and a feature request from >>> the Swarm team) recently that are essentially caused by an application >>> being accessed before it is fully deployed. Basically even though we >>> have service dependencies that make sure individual components >>> dependencies are up, once a request has been accepted it can potentially >>> programmatically access other parts of the deployment that are not up >>> yet (basically the same problem we have with graceful shutdown, but in >>> reverse). >>> >>> I propose we solve this using a 'graceful startup' mechanism, that holds >>> or rejects new requests until a server or deployment is fully started. >>> The specifics of how this would work are: >>> >>> - If the server is booting all external requests will be held or >>> rejected until the the boot process is complete >>> - When deploying a new deployment all requests for that deployment will >>> be held or rejected until MSC has attained stability >>> >>> This would be implemented for the following endpoints/subsystems: >>> >>> - Undertow will hold requests until the deployment is done (so if you >>> try and load a page while deployment is happening it could be a bit of a >>> wait) >>> - Remote EJB will hold requests until deployment is done >>> - mod_cluster will not send availability messages until deployment is done >> >> Isn't this what mod_cluster does on a per-deployment basis anyway? The >> basic idea of mod_cluster is the LB isn't notified the context is >> available on a backend server until it's....available. > > True, but not everyone is using mod_cluster. > Sure, but the statement I was commenting on was about proposed new behavior of our mod_cluster subsystem. But the proposed new behavior sounds like what the existing behavior should already be. So I wonder if I'm missing something. >> >>> - JMS will delay message delivery until deployment is done >>> - EJB persistent timers will not fire until deployment is done >>> - Possibly some other cases I can't think of right now >>> >>> One thing I am not really sure about is if we need a configuration >>> switch for hold/reject behavior. e.g. for Undertow the request holding >>> behavior is very developer friendly, as it means they can just hit >>> refresh in their browser and as soon as the redeployment is done the >>> page will display, however I am worried that it might not be ideal for >>> load balancers that may prefer a quick error response that could then be >>> attempted on another node (although if mod_cluster is not sending out >>> availability till the deployment is 100% complete this may not be a big >>> deal). >>> >>> If you want to see this in action I have a very simple PR at [3] that >>> enables this for Undertow at server boot. >>> >>> Thoughts? >>> >>> Stuart >>> >>> [1] https://issues.jboss.org/browse/WFLY-6402 >>> [2] https://issues.jboss.org/browse/JBEAP-867 >>> [3] https://github.com/wildfly/wildfly/pull/8858 >>> >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From stuart.w.douglas at gmail.com Thu Apr 21 18:59:54 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 21 Apr 2016 22:59:54 +0000 Subject: [wildfly-dev] Graceful startup In-Reply-To: <57191FA0.9070800@redhat.com> References: <57191FA0.9070800@redhat.com> Message-ID: > > - Undertow will hold requests until the deployment is done (so if you > > try and load a page while deployment is happening it could be a bit of a > > wait) > > - Remote EJB will hold requests until deployment is done > > - mod_cluster will not send availability messages until deployment is > done > > Isn't this what mod_cluster does on a per-deployment basis anyway? The > basic idea of mod_cluster is the LB isn't notified the context is > available on a backend server until it's....available. > > At the moment it is sent when the Undertow service comes up. It is still possible that there could be other services (especially in a multi module EAR deployment) that have not come up yet. In practice for a lot of deployments this window will be very small or even non existent, and the behavior will be basically indistinguishable. Stuart -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160421/52d3edbd/attachment-0001.html From brian.stansberry at redhat.com Thu Apr 21 21:30:17 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 21 Apr 2016 20:30:17 -0500 Subject: [wildfly-dev] Graceful startup In-Reply-To: References: <57191FA0.9070800@redhat.com> Message-ID: <57197EA9.1090203@redhat.com> On 4/21/16 5:59 PM, Stuart Douglas wrote: > > > - Undertow will hold requests until the deployment is done (so if you > > try and load a page while deployment is happening it could be a > bit of a > > wait) > > - Remote EJB will hold requests until deployment is done > > - mod_cluster will not send availability messages until > deployment is done > > Isn't this what mod_cluster does on a per-deployment basis anyway? The > basic idea of mod_cluster is the LB isn't notified the context is > available on a backend server until it's....available. > > > At the moment it is sent when the Undertow service comes up. It is still > possible that there could be other services (especially in a multi > module EAR deployment) that have not come up yet. > > In practice for a lot of deployments this window will be very small or > even non existent, and the behavior will be basically indistinguishable. > Thanks. That's a good hole to close. > Stuart -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From gaoyonglu at 126.com Thu Apr 21 22:00:12 2016 From: gaoyonglu at 126.com (gaoyonglu at 126.com) Date: Fri, 22 Apr 2016 10:00:12 +0800 Subject: [wildfly-dev] Graceful startup References: Message-ID: <201604221000083970284@126.com> One thing I am not really sure about is if we need a configuration > switch for hold/reject behavior I think use reject is better. The weblogic server start graceful use reject and if use hold option we must set queue to hold request. I very much looking forward to this feature gaoyonglu at 126.com From: wildfly-dev-request Date: 2016-04-22 07:00 To: wildfly-dev Subject: wildfly-dev Digest, Vol 37, Issue 9 Send wildfly-dev mailing list submissions to wildfly-dev at lists.jboss.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.jboss.org/mailman/listinfo/wildfly-dev or, via email, send a message with subject or body 'help' to wildfly-dev-request at lists.jboss.org You can reach the person managing the list at wildfly-dev-owner at lists.jboss.org When replying, please edit your Subject line so it is more specific than "Re: Contents of wildfly-dev digest..." Today's Topics: 1. Re: Graceful startup (David M. Lloyd) 2. question on jboss-app_7_0.xsd intermingling jee versions (Rob Stryker) 3. Re: question on jboss-app_7_0.xsd intermingling jee versions (Rob Stryker) 4. Re: Graceful startup (Brian Stansberry) 5. Re: Graceful startup (John Doyle) 6. Re: Graceful startup (Brian Stansberry) 7. Re: Graceful startup (Stuart Douglas) ---------------------------------------------------------------------- Message: 1 Date: Thu, 21 Apr 2016 06:50:47 -0500 From: "David M. Lloyd" Subject: Re: [wildfly-dev] Graceful startup To: wildfly-dev at lists.jboss.org Message-ID: <5718BE97.9010405 at redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed On 04/20/2016 09:05 PM, Stuart Douglas wrote: > Hi, > > I have come across a few bug reports [1][2] (and a feature request from > the Swarm team) recently that are essentially caused by an application > being accessed before it is fully deployed. Basically even though we > have service dependencies that make sure individual components > dependencies are up, once a request has been accepted it can potentially > programmatically access other parts of the deployment that are not up > yet (basically the same problem we have with graceful shutdown, but in > reverse). > > I propose we solve this using a 'graceful startup' mechanism, that holds > or rejects new requests until a server or deployment is fully started. > The specifics of how this would work are: > > - If the server is booting all external requests will be held or > rejected until the the boot process is complete > - When deploying a new deployment all requests for that deployment will > be held or rejected until MSC has attained stability > > This would be implemented for the following endpoints/subsystems: > > - Undertow will hold requests until the deployment is done (so if you > try and load a page while deployment is happening it could be a bit of a > wait) > - Remote EJB will hold requests until deployment is done > - mod_cluster will not send availability messages until deployment is done > - JMS will delay message delivery until deployment is done > - EJB persistent timers will not fire until deployment is done > - Possibly some other cases I can't think of right now > > One thing I am not really sure about is if we need a configuration > switch for hold/reject behavior. e.g. for Undertow the request holding > behavior is very developer friendly, as it means they can just hit > refresh in their browser and as soon as the redeployment is done the > page will display, however I am worried that it might not be ideal for > load balancers that may prefer a quick error response that could then be > attempted on another node (although if mod_cluster is not sending out > availability till the deployment is 100% complete this may not be a big > deal). I think load balancers should not have a server that is being started up in the rotation anyway; this already probably doesn't work great today. I like the idea overall. -- - DML ------------------------------ Message: 2 Date: Thu, 21 Apr 2016 12:08:05 -0400 From: Rob Stryker Subject: [wildfly-dev] question on jboss-app_7_0.xsd intermingling jee versions To: "wildfly-dev at lists.jboss.org" Message-ID: <5718FAE5.2020307 at redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Hi guys: I recently opened https://issues.jboss.org/browse/JBMETA-394 because it seems our application schema are intermingling jee versions between ee6 and ee7, and it's causing problems for our eclipse validators. Who's in charge of these schema, specifically? Who would be the right person to ping to get it fixed? - Rob Stryker ------------------------------ Message: 3 Date: Thu, 21 Apr 2016 12:13:51 -0400 From: Rob Stryker Subject: Re: [wildfly-dev] question on jboss-app_7_0.xsd intermingling jee versions To: wildfly-dev at lists.jboss.org Message-ID: <5718FC3F.4020300 at redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Ok, seems I missed some responses before. > Max Anderson wrote: Rob - is the error you see on the jboss-application.xml you wrote or in the included xsd ? I opened https://issues.jboss.org/browse/JBMETA-394 for a more clear explanation as to the specific error. The error is in a user's jboss-application.xml. > Marek wrote: I guess you mixed Java EE 6 with JBoss AS 7 versions here. I'll try to find out where the example is coming from. If it's from one of our published examples, then I would guess it needs to be fixed there. Looking at the released versions of jboss-app_x_y.xsd, it would seem Marek is probably right and the versions there match the jboss/wf releases, and not the ee version. I'll dig deeper. Thanks. On 04/21/2016 12:08 PM, Rob Stryker wrote: > Hi guys: > > I recently opened https://issues.jboss.org/browse/JBMETA-394 because it > seems our application schema are intermingling jee versions between ee6 > and ee7, and it's causing problems for our eclipse validators. > > Who's in charge of these schema, specifically? Who would be the right > person to ping to get it fixed? > > - Rob Stryker > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev ------------------------------ Message: 4 Date: Thu, 21 Apr 2016 13:44:48 -0500 From: Brian Stansberry Subject: Re: [wildfly-dev] Graceful startup To: wildfly-dev at lists.jboss.org Message-ID: <57191FA0.9070800 at redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed On 4/20/16 9:05 PM, Stuart Douglas wrote: > Hi, > > I have come across a few bug reports [1][2] (and a feature request from > the Swarm team) recently that are essentially caused by an application > being accessed before it is fully deployed. Basically even though we > have service dependencies that make sure individual components > dependencies are up, once a request has been accepted it can potentially > programmatically access other parts of the deployment that are not up > yet (basically the same problem we have with graceful shutdown, but in > reverse). > > I propose we solve this using a 'graceful startup' mechanism, that holds > or rejects new requests until a server or deployment is fully started. > The specifics of how this would work are: > > - If the server is booting all external requests will be held or > rejected until the the boot process is complete > - When deploying a new deployment all requests for that deployment will > be held or rejected until MSC has attained stability > > This would be implemented for the following endpoints/subsystems: > > - Undertow will hold requests until the deployment is done (so if you > try and load a page while deployment is happening it could be a bit of a > wait) > - Remote EJB will hold requests until deployment is done > - mod_cluster will not send availability messages until deployment is done Isn't this what mod_cluster does on a per-deployment basis anyway? The basic idea of mod_cluster is the LB isn't notified the context is available on a backend server until it's....available. > - JMS will delay message delivery until deployment is done > - EJB persistent timers will not fire until deployment is done > - Possibly some other cases I can't think of right now > > One thing I am not really sure about is if we need a configuration > switch for hold/reject behavior. e.g. for Undertow the request holding > behavior is very developer friendly, as it means they can just hit > refresh in their browser and as soon as the redeployment is done the > page will display, however I am worried that it might not be ideal for > load balancers that may prefer a quick error response that could then be > attempted on another node (although if mod_cluster is not sending out > availability till the deployment is 100% complete this may not be a big > deal). > > If you want to see this in action I have a very simple PR at [3] that > enables this for Undertow at server boot. > > Thoughts? > > Stuart > > [1] https://issues.jboss.org/browse/WFLY-6402 > [2] https://issues.jboss.org/browse/JBEAP-867 > [3] https://github.com/wildfly/wildfly/pull/8858 > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat ------------------------------ Message: 5 Date: Thu, 21 Apr 2016 15:07:18 -0400 From: John Doyle Subject: Re: [wildfly-dev] Graceful startup To: Brian Stansberry Cc: wildfly-dev at lists.jboss.org Message-ID: Content-Type: text/plain; charset=UTF-8 On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry wrote: > On 4/20/16 9:05 PM, Stuart Douglas wrote: >> Hi, >> >> I have come across a few bug reports [1][2] (and a feature request from >> the Swarm team) recently that are essentially caused by an application >> being accessed before it is fully deployed. Basically even though we >> have service dependencies that make sure individual components >> dependencies are up, once a request has been accepted it can potentially >> programmatically access other parts of the deployment that are not up >> yet (basically the same problem we have with graceful shutdown, but in >> reverse). >> >> I propose we solve this using a 'graceful startup' mechanism, that holds >> or rejects new requests until a server or deployment is fully started. >> The specifics of how this would work are: >> >> - If the server is booting all external requests will be held or >> rejected until the the boot process is complete >> - When deploying a new deployment all requests for that deployment will >> be held or rejected until MSC has attained stability >> >> This would be implemented for the following endpoints/subsystems: >> >> - Undertow will hold requests until the deployment is done (so if you >> try and load a page while deployment is happening it could be a bit of a >> wait) >> - Remote EJB will hold requests until deployment is done >> - mod_cluster will not send availability messages until deployment is done > > Isn't this what mod_cluster does on a per-deployment basis anyway? The > basic idea of mod_cluster is the LB isn't notified the context is > available on a backend server until it's....available. True, but not everyone is using mod_cluster. > >> - JMS will delay message delivery until deployment is done >> - EJB persistent timers will not fire until deployment is done >> - Possibly some other cases I can't think of right now >> >> One thing I am not really sure about is if we need a configuration >> switch for hold/reject behavior. e.g. for Undertow the request holding >> behavior is very developer friendly, as it means they can just hit >> refresh in their browser and as soon as the redeployment is done the >> page will display, however I am worried that it might not be ideal for >> load balancers that may prefer a quick error response that could then be >> attempted on another node (although if mod_cluster is not sending out >> availability till the deployment is 100% complete this may not be a big >> deal). >> >> If you want to see this in action I have a very simple PR at [3] that >> enables this for Undertow at server boot. >> >> Thoughts? >> >> Stuart >> >> [1] https://issues.jboss.org/browse/WFLY-6402 >> [2] https://issues.jboss.org/browse/JBEAP-867 >> [3] https://github.com/wildfly/wildfly/pull/8858 >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev ------------------------------ Message: 6 Date: Thu, 21 Apr 2016 15:39:56 -0500 From: Brian Stansberry Subject: Re: [wildfly-dev] Graceful startup To: John Doyle Cc: wildfly-dev at lists.jboss.org Message-ID: <57193A9C.1040103 at redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed On 4/21/16 2:07 PM, John Doyle wrote: > On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry > wrote: >> On 4/20/16 9:05 PM, Stuart Douglas wrote: >>> Hi, >>> >>> I have come across a few bug reports [1][2] (and a feature request from >>> the Swarm team) recently that are essentially caused by an application >>> being accessed before it is fully deployed. Basically even though we >>> have service dependencies that make sure individual components >>> dependencies are up, once a request has been accepted it can potentially >>> programmatically access other parts of the deployment that are not up >>> yet (basically the same problem we have with graceful shutdown, but in >>> reverse). >>> >>> I propose we solve this using a 'graceful startup' mechanism, that holds >>> or rejects new requests until a server or deployment is fully started. >>> The specifics of how this would work are: >>> >>> - If the server is booting all external requests will be held or >>> rejected until the the boot process is complete >>> - When deploying a new deployment all requests for that deployment will >>> be held or rejected until MSC has attained stability >>> >>> This would be implemented for the following endpoints/subsystems: >>> >>> - Undertow will hold requests until the deployment is done (so if you >>> try and load a page while deployment is happening it could be a bit of a >>> wait) >>> - Remote EJB will hold requests until deployment is done >>> - mod_cluster will not send availability messages until deployment is done >> >> Isn't this what mod_cluster does on a per-deployment basis anyway? The >> basic idea of mod_cluster is the LB isn't notified the context is >> available on a backend server until it's....available. > > True, but not everyone is using mod_cluster. > Sure, but the statement I was commenting on was about proposed new behavior of our mod_cluster subsystem. But the proposed new behavior sounds like what the existing behavior should already be. So I wonder if I'm missing something. >> >>> - JMS will delay message delivery until deployment is done >>> - EJB persistent timers will not fire until deployment is done >>> - Possibly some other cases I can't think of right now >>> >>> One thing I am not really sure about is if we need a configuration >>> switch for hold/reject behavior. e.g. for Undertow the request holding >>> behavior is very developer friendly, as it means they can just hit >>> refresh in their browser and as soon as the redeployment is done the >>> page will display, however I am worried that it might not be ideal for >>> load balancers that may prefer a quick error response that could then be >>> attempted on another node (although if mod_cluster is not sending out >>> availability till the deployment is 100% complete this may not be a big >>> deal). >>> >>> If you want to see this in action I have a very simple PR at [3] that >>> enables this for Undertow at server boot. >>> >>> Thoughts? >>> >>> Stuart >>> >>> [1] https://issues.jboss.org/browse/WFLY-6402 >>> [2] https://issues.jboss.org/browse/JBEAP-867 >>> [3] https://github.com/wildfly/wildfly/pull/8858 >>> >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat ------------------------------ Message: 7 Date: Thu, 21 Apr 2016 22:59:54 +0000 From: Stuart Douglas Subject: Re: [wildfly-dev] Graceful startup To: Brian Stansberry , wildfly-dev at lists.jboss.org Message-ID: Content-Type: text/plain; charset="utf-8" > > - Undertow will hold requests until the deployment is done (so if you > > try and load a page while deployment is happening it could be a bit of a > > wait) > > - Remote EJB will hold requests until deployment is done > > - mod_cluster will not send availability messages until deployment is > done > > Isn't this what mod_cluster does on a per-deployment basis anyway? The > basic idea of mod_cluster is the LB isn't notified the context is > available on a backend server until it's....available. > > At the moment it is sent when the Undertow service comes up. It is still possible that there could be other services (especially in a multi module EAR deployment) that have not come up yet. In practice for a lot of deployments this window will be very small or even non existent, and the behavior will be basically indistinguishable. Stuart -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160421/52d3edbd/attachment.html ------------------------------ _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev End of wildfly-dev Digest, Vol 37, Issue 9 ****************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160422/a577246c/attachment-0001.html From stuart.w.douglas at gmail.com Thu Apr 21 23:00:44 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Fri, 22 Apr 2016 03:00:44 +0000 Subject: [wildfly-dev] Graceful startup In-Reply-To: <201604221000083970284@126.com> References: <201604221000083970284@126.com> Message-ID: At the moment I am leaning towards holding request rather than rejecting. If the user really wants reject behavior they can uses suspend/resume to achieve this. Stuart On Fri, 22 Apr 2016 at 12:00 gaoyonglu at 126.com wrote: > One thing I am not really sure about is if we need a configuration > > switch for hold/reject behavior > > I think use reject is better. The weblogic server start graceful use > reject and if use hold option we must set queue to hold request. > > I very much looking forward to this feature > ------------------------------ > gaoyonglu at 126.com > > *From:* wildfly-dev-request > *Date:* 2016-04-22 07:00 > *To:* wildfly-dev > *Subject:* wildfly-dev Digest, Vol 37, Issue 9 > Send wildfly-dev mailing list submissions to > wildfly-dev at lists.jboss.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.jboss.org/mailman/listinfo/wildfly-dev > or, via email, send a message with subject or body 'help' to > wildfly-dev-request at lists.jboss.org > > You can reach the person managing the list at > wildfly-dev-owner at lists.jboss.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wildfly-dev digest..." > > > Today's Topics: > > 1. Re: Graceful startup (David M. Lloyd) > 2. question on jboss-app_7_0.xsd intermingling jee versions > (Rob Stryker) > 3. Re: question on jboss-app_7_0.xsd intermingling jee versions > (Rob Stryker) > 4. Re: Graceful startup (Brian Stansberry) > 5. Re: Graceful startup (John Doyle) > 6. Re: Graceful startup (Brian Stansberry) > 7. Re: Graceful startup (Stuart Douglas) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 21 Apr 2016 06:50:47 -0500 > From: "David M. Lloyd" > Subject: Re: [wildfly-dev] Graceful startup > To: wildfly-dev at lists.jboss.org > Message-ID: <5718BE97.9010405 at redhat.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 04/20/2016 09:05 PM, Stuart Douglas wrote: > > Hi, > > > > I have come across a few bug reports [1][2] (and a feature request from > > the Swarm team) recently that are essentially caused by an application > > being accessed before it is fully deployed. Basically even though we > > have service dependencies that make sure individual components > > dependencies are up, once a request has been accepted it can potentially > > programmatically access other parts of the deployment that are not up > > yet (basically the same problem we have with graceful shutdown, but in > > reverse). > > > > I propose we solve this using a 'graceful startup' mechanism, that holds > > or rejects new requests until a server or deployment is fully started. > > The specifics of how this would work are: > > > > - If the server is booting all external requests will be held or > > rejected until the the boot process is complete > > - When deploying a new deployment all requests for that deployment will > > be held or rejected until MSC has attained stability > > > > This would be implemented for the following endpoints/subsystems: > > > > - Undertow will hold requests until the deployment is done (so if you > > try and load a page while deployment is happening it could be a bit of a > > wait) > > - Remote EJB will hold requests until deployment is done > > - mod_cluster will not send availability messages until deployment is > done > > - JMS will delay message delivery until deployment is done > > - EJB persistent timers will not fire until deployment is done > > - Possibly some other cases I can't think of right now > > > > One thing I am not really sure about is if we need a configuration > > switch for hold/reject behavior. e.g. for Undertow the request holding > > behavior is very developer friendly, as it means they can just hit > > refresh in their browser and as soon as the redeployment is done the > > page will display, however I am worried that it might not be ideal for > > load balancers that may prefer a quick error response that could then be > > attempted on another node (although if mod_cluster is not sending out > > availability till the deployment is 100% complete this may not be a big > > deal). > > I think load balancers should not have a server that is being started up > in the rotation anyway; this already probably doesn't work great today. > > I like the idea overall. > > -- > - DML > > > ------------------------------ > > Message: 2 > Date: Thu, 21 Apr 2016 12:08:05 -0400 > From: Rob Stryker > Subject: [wildfly-dev] question on jboss-app_7_0.xsd intermingling jee > versions > To: "wildfly-dev at lists.jboss.org" > Message-ID: <5718FAE5.2020307 at redhat.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi guys: > > I recently opened https://issues.jboss.org/browse/JBMETA-394 because it > seems our application schema are intermingling jee versions between ee6 > and ee7, and it's causing problems for our eclipse validators. > > Who's in charge of these schema, specifically? Who would be the right > person to ping to get it fixed? > > - Rob Stryker > > > ------------------------------ > > Message: 3 > Date: Thu, 21 Apr 2016 12:13:51 -0400 > From: Rob Stryker > Subject: Re: [wildfly-dev] question on jboss-app_7_0.xsd intermingling > jee versions > To: wildfly-dev at lists.jboss.org > Message-ID: <5718FC3F.4020300 at redhat.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Ok, seems I missed some responses before. > > > Max Anderson wrote: Rob - is the error you see on the > jboss-application.xml you wrote or in the included xsd ? > > I opened https://issues.jboss.org/browse/JBMETA-394 for a more clear > explanation as to the specific error. The error is in a user's > jboss-application.xml. > > > Marek wrote: I guess you mixed Java EE 6 with JBoss AS 7 versions here. > > I'll try to find out where the example is coming from. If it's from one > of our published examples, then I would guess it needs to be fixed > there. Looking at the released versions of jboss-app_x_y.xsd, it would > seem Marek is probably right and the versions there match the jboss/wf > releases, and not the ee version. > > I'll dig deeper. Thanks. > > On 04/21/2016 12:08 PM, Rob Stryker wrote: > > Hi guys: > > > > I recently opened https://issues.jboss.org/browse/JBMETA-394 because it > > seems our application schema are intermingling jee versions between ee6 > > and ee7, and it's causing problems for our eclipse validators. > > > > Who's in charge of these schema, specifically? Who would be the right > > person to ping to get it fixed? > > > > - Rob Stryker > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > ------------------------------ > > Message: 4 > Date: Thu, 21 Apr 2016 13:44:48 -0500 > From: Brian Stansberry > Subject: Re: [wildfly-dev] Graceful startup > To: wildfly-dev at lists.jboss.org > Message-ID: <57191FA0.9070800 at redhat.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > On 4/20/16 9:05 PM, Stuart Douglas wrote: > > Hi, > > > > I have come across a few bug reports [1][2] (and a feature request from > > the Swarm team) recently that are essentially caused by an application > > being accessed before it is fully deployed. Basically even though we > > have service dependencies that make sure individual components > > dependencies are up, once a request has been accepted it can potentially > > programmatically access other parts of the deployment that are not up > > yet (basically the same problem we have with graceful shutdown, but in > > reverse). > > > > I propose we solve this using a 'graceful startup' mechanism, that holds > > or rejects new requests until a server or deployment is fully started. > > The specifics of how this would work are: > > > > - If the server is booting all external requests will be held or > > rejected until the the boot process is complete > > - When deploying a new deployment all requests for that deployment will > > be held or rejected until MSC has attained stability > > > > This would be implemented for the following endpoints/subsystems: > > > > - Undertow will hold requests until the deployment is done (so if you > > try and load a page while deployment is happening it could be a bit of a > > wait) > > - Remote EJB will hold requests until deployment is done > > - mod_cluster will not send availability messages until deployment is > done > > Isn't this what mod_cluster does on a per-deployment basis anyway? The > basic idea of mod_cluster is the LB isn't notified the context is > available on a backend server until it's....available. > > > - JMS will delay message delivery until deployment is done > > - EJB persistent timers will not fire until deployment is done > > - Possibly some other cases I can't think of right now > > > > One thing I am not really sure about is if we need a configuration > > switch for hold/reject behavior. e.g. for Undertow the request holding > > behavior is very developer friendly, as it means they can just hit > > refresh in their browser and as soon as the redeployment is done the > > page will display, however I am worried that it might not be ideal for > > load balancers that may prefer a quick error response that could then be > > attempted on another node (although if mod_cluster is not sending out > > availability till the deployment is 100% complete this may not be a big > > deal). > > > > If you want to see this in action I have a very simple PR at [3] that > > enables this for Undertow at server boot. > > > > Thoughts? > > > > Stuart > > > > [1] https://issues.jboss.org/browse/WFLY-6402 > > [2] https://issues.jboss.org/browse/JBEAP-867 > > [3] https://github.com/wildfly/wildfly/pull/8858 > > > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > > > ------------------------------ > > Message: 5 > Date: Thu, 21 Apr 2016 15:07:18 -0400 > From: John Doyle > Subject: Re: [wildfly-dev] Graceful startup > To: Brian Stansberry > Cc: wildfly-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry > wrote: > > On 4/20/16 9:05 PM, Stuart Douglas wrote: > >> Hi, > >> > >> I have come across a few bug reports [1][2] (and a feature request from > >> the Swarm team) recently that are essentially caused by an application > >> being accessed before it is fully deployed. Basically even though we > >> have service dependencies that make sure individual components > >> dependencies are up, once a request has been accepted it can potentially > >> programmatically access other parts of the deployment that are not up > >> yet (basically the same problem we have with graceful shutdown, but in > >> reverse). > >> > >> I propose we solve this using a 'graceful startup' mechanism, that holds > >> or rejects new requests until a server or deployment is fully started. > >> The specifics of how this would work are: > >> > >> - If the server is booting all external requests will be held or > >> rejected until the the boot process is complete > >> - When deploying a new deployment all requests for that deployment will > >> be held or rejected until MSC has attained stability > >> > >> This would be implemented for the following endpoints/subsystems: > >> > >> - Undertow will hold requests until the deployment is done (so if you > >> try and load a page while deployment is happening it could be a bit of a > >> wait) > >> - Remote EJB will hold requests until deployment is done > >> - mod_cluster will not send availability messages until deployment is > done > > > > Isn't this what mod_cluster does on a per-deployment basis anyway? The > > basic idea of mod_cluster is the LB isn't notified the context is > > available on a backend server until it's....available. > > True, but not everyone is using mod_cluster. > > > > >> - JMS will delay message delivery until deployment is done > >> - EJB persistent timers will not fire until deployment is done > >> - Possibly some other cases I can't think of right now > >> > >> One thing I am not really sure about is if we need a configuration > >> switch for hold/reject behavior. e.g. for Undertow the request holding > >> behavior is very developer friendly, as it means they can just hit > >> refresh in their browser and as soon as the redeployment is done the > >> page will display, however I am worried that it might not be ideal for > >> load balancers that may prefer a quick error response that could then be > >> attempted on another node (although if mod_cluster is not sending out > >> availability till the deployment is 100% complete this may not be a big > >> deal). > >> > >> If you want to see this in action I have a very simple PR at [3] that > >> enables this for Undertow at server boot. > >> > >> Thoughts? > >> > >> Stuart > >> > >> [1] https://issues.jboss.org/browse/WFLY-6402 > >> [2] https://issues.jboss.org/browse/JBEAP-867 > >> [3] https://github.com/wildfly/wildfly/pull/8858 > >> > >> > >> > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > > > > > > -- > > Brian Stansberry > > Senior Principal Software Engineer > > JBoss by Red Hat > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > ------------------------------ > > Message: 6 > Date: Thu, 21 Apr 2016 15:39:56 -0500 > From: Brian Stansberry > Subject: Re: [wildfly-dev] Graceful startup > To: John Doyle > Cc: wildfly-dev at lists.jboss.org > Message-ID: <57193A9C.1040103 at redhat.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 4/21/16 2:07 PM, John Doyle wrote: > > On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry > > wrote: > >> On 4/20/16 9:05 PM, Stuart Douglas wrote: > >>> Hi, > >>> > >>> I have come across a few bug reports [1][2] (and a feature request from > >>> the Swarm team) recently that are essentially caused by an application > >>> being accessed before it is fully deployed. Basically even though we > >>> have service dependencies that make sure individual components > >>> dependencies are up, once a request has been accepted it can > potentially > >>> programmatically access other parts of the deployment that are not up > >>> yet (basically the same problem we have with graceful shutdown, but in > >>> reverse). > >>> > >>> I propose we solve this using a 'graceful startup' mechanism, that > holds > >>> or rejects new requests until a server or deployment is fully started. > >>> The specifics of how this would work are: > >>> > >>> - If the server is booting all external requests will be held or > >>> rejected until the the boot process is complete > >>> - When deploying a new deployment all requests for that deployment will > >>> be held or rejected until MSC has attained stability > >>> > >>> This would be implemented for the following endpoints/subsystems: > >>> > >>> - Undertow will hold requests until the deployment is done (so if you > >>> try and load a page while deployment is happening it could be a bit of > a > >>> wait) > >>> - Remote EJB will hold requests until deployment is done > >>> - mod_cluster will not send availability messages until deployment is > done > >> > >> Isn't this what mod_cluster does on a per-deployment basis anyway? The > >> basic idea of mod_cluster is the LB isn't notified the context is > >> available on a backend server until it's....available. > > > > True, but not everyone is using mod_cluster. > > > > Sure, but the statement I was commenting on was about proposed new > behavior of our mod_cluster subsystem. But the proposed new behavior > sounds like what the existing behavior should already be. So I wonder if > I'm missing something. > > >> > >>> - JMS will delay message delivery until deployment is done > >>> - EJB persistent timers will not fire until deployment is done > >>> - Possibly some other cases I can't think of right now > >>> > >>> One thing I am not really sure about is if we need a configuration > >>> switch for hold/reject behavior. e.g. for Undertow the request holding > >>> behavior is very developer friendly, as it means they can just hit > >>> refresh in their browser and as soon as the redeployment is done the > >>> page will display, however I am worried that it might not be ideal for > >>> load balancers that may prefer a quick error response that could then > be > >>> attempted on another node (although if mod_cluster is not sending out > >>> availability till the deployment is 100% complete this may not be a big > >>> deal). > >>> > >>> If you want to see this in action I have a very simple PR at [3] that > >>> enables this for Undertow at server boot. > >>> > >>> Thoughts? > >>> > >>> Stuart > >>> > >>> [1] https://issues.jboss.org/browse/WFLY-6402 > >>> [2] https://issues.jboss.org/browse/JBEAP-867 > >>> [3] https://github.com/wildfly/wildfly/pull/8858 > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> wildfly-dev mailing list > >>> wildfly-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>> > >> > >> > >> -- > >> Brian Stansberry > >> Senior Principal Software Engineer > >> JBoss by Red Hat > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > > > ------------------------------ > > Message: 7 > Date: Thu, 21 Apr 2016 22:59:54 +0000 > From: Stuart Douglas > Subject: Re: [wildfly-dev] Graceful startup > To: Brian Stansberry , > wildfly-dev at lists.jboss.org > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > > > - Undertow will hold requests until the deployment is done (so if you > > > try and load a page while deployment is happening it could be a bit of > a > > > wait) > > > - Remote EJB will hold requests until deployment is done > > > - mod_cluster will not send availability messages until deployment is > > done > > > > Isn't this what mod_cluster does on a per-deployment basis anyway? The > > basic idea of mod_cluster is the LB isn't notified the context is > > available on a backend server until it's....available. > > > > > At the moment it is sent when the Undertow service comes up. It is still > possible that there could be other services (especially in a multi module > EAR deployment) that have not come up yet. > > In practice for a lot of deployments this window will be very small or even > non existent, and the behavior will be basically indistinguishable. > > Stuart > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160421/52d3edbd/attachment.html > > ------------------------------ > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > End of wildfly-dev Digest, Vol 37, Issue 9 > ****************************************** > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160422/caaeb936/attachment-0001.html From hbraun at redhat.com Fri Apr 22 03:09:44 2016 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 22 Apr 2016 09:09:44 +0200 Subject: [wildfly-dev] Graceful startup In-Reply-To: References: <201604221000083970284@126.com> Message-ID: <8B29C698-A6E0-4E0E-9623-031F6A450473@redhat.com> How would suspend/resume be applied in this situation? I think we speak about server startup, right? > On 22 Apr 2016, at 05:00, Stuart Douglas wrote: > > If the user really wants reject behavior they can uses suspend/resume to achieve this. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160422/f7cc45cc/attachment.html From stuart.w.douglas at gmail.com Fri Apr 22 03:51:08 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Fri, 22 Apr 2016 07:51:08 +0000 Subject: [wildfly-dev] Graceful startup In-Reply-To: <8B29C698-A6E0-4E0E-9623-031F6A450473@redhat.com> References: <201604221000083970284@126.com> <8B29C698-A6E0-4E0E-9623-031F6A450473@redhat.com> Message-ID: On Fri, 22 Apr 2016 at 17:10 Heiko Braun wrote: > How would suspend/resume be applied in this situation? I think we speak > about server startup, right? > Good point. I was actually thinking about redeploy, but you are right that there is not really any way to apply suspend/resume in this case. I think a switch between reject/hold may be the best idea then, as there are pros and cons of each. Stuart > > On 22 Apr 2016, at 05:00, Stuart Douglas > wrote: > > If the user really wants reject behavior they can uses suspend/resume to > achieve this. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160422/f66bfe87/attachment.html From brian.stansberry at redhat.com Fri Apr 22 11:10:49 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 22 Apr 2016 10:10:49 -0500 Subject: [wildfly-dev] Pattern defined RBAC scoped roles Message-ID: <571A3EF9.7050002@redhat.com> Yesterday afternoon I decided to scratch an itch I've had for a year. My scratching seems to work so I'm tossing the idea out to get feedback on whether it's wanted. Idea is to let users create scoped roles for WildFly's management RBAC feature that are based on address pattern matching. For example this role would create a role where a user has non-sensitive write permissions to resources in the logging subsystem, either on a DC or a server: .... A role like this could be used when the server config is really meant to be locked down after boot, but you want to allow logging tweaks to get diagnostic data if necessary. A scoped role in our RBAC impl is one where the user gets the permissions of some other role if the target resource is considered "in scope", while if it's not they get lesser permissions (just non-sensitive read perms, or for some cases no perms at all.) What we have now are server group scoped roles and host scoped roles, where what's "in scope" is calculated based on a configurable list of server groups or hosts. This new type of scoped role instead does pattern matching of the target address against a configurable list of regular expressions. If there is no match the user gets non-sensitive read perms. There can be more than one pattern; a match against any means the scoping constraint is satisfied. The address matching is against the CLI-style representation of the target resource address. When authorizing JMX operations the match is against the canonical form of the ObjectName. JMX ops against the mbeans in the jboss.as[.expr] domains match against the CLI-style address of the management resource underlying the facade mbeans. I have this working, see [1]. Needs tests but it works with manual testing. [1] https://github.com/wildfly/wildfly-core/pull/1516 -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From lthon at redhat.com Sat Apr 23 02:38:13 2016 From: lthon at redhat.com (Ladislav Thon) Date: Sat, 23 Apr 2016 08:38:13 +0200 Subject: [wildfly-dev] Pattern defined RBAC scoped roles In-Reply-To: <571A3EF9.7050002@redhat.com> References: <571A3EF9.7050002@redhat.com> Message-ID: <571B1855.9040401@redhat.com> I only have a single comment: writing a regular expression can sometimes be a bit tricky. Just see the example you used: > (/profile=[^/]+)??/subsystem=logging(/.*)* It's also fairly easy to write a regular expression that doesn't quite do what you want it to do, in some corner cases. Finally, some well-crafted regular expressions have running time in years or more (at least in the java.util.regex implementation). This all leads me to believe that maybe regular expressions are not the best choice. Instead, I'm thinking about address prefixes. So the role would be specified by a set of valid addresses (including the "*" wildcard), and only the specified resources and all their children would be accessible. I'm specifically not thinking about _textual_ prefix, so e.g. prefix of /subsystem=messaging would give you access to the old messaging subsystem, but it _wouldn't_ give you access to the new /subsystem=messaging-activemq, even if /subsystem=messaging is a textual prefix. Granted, that's way less powerful than regular expressions, but also easier and safer to use. WDYT? Am I being too paranoid here? LT From jtymel at redhat.com Mon Apr 25 04:52:28 2016 From: jtymel at redhat.com (Jan Tymel) Date: Mon, 25 Apr 2016 04:52:28 -0400 (EDT) Subject: [wildfly-dev] Issues in tests with Security Manager In-Reply-To: <56DC523C.60605@redhat.com> References: <56DC523C.60605@redhat.com> Message-ID: <1730677265.81800941.1461574348698.JavaMail.zimbra@redhat.com> JBEAP umbrella issue was created a few months ago, WildFly umbrella issue was created recently. Here are the links: JBEAP issue: https://issues.jboss.org/browse/JBEAP-971 WildFly issue: https://issues.jboss.org/browse/WFLY-6542 If you create a new issue, please add a link to JBEAP/WFLY issue to make tracking SecMgr issues feasible. ----- Original Message ----- From: "David M. Lloyd" To: wildfly-dev at lists.jboss.org Sent: Sunday, March 6, 2016 4:52:28 PM Subject: Re: [wildfly-dev] Issues in tests with Security Manager Maybe have one JBEAP issue, and one parent WFLY issue with all the specific problems being sub-tasks? On 03/06/2016 06:51 AM, Eduardo Sant?Ana da Silva wrote: > Hi all, > > I'm looking at the opened issues on JIRA related to tests with the > security manager. > Probably the cause is only one, but we have a plethora of issues > regarding this subject that it will be a nightmare to track later. > > Shouldn't we have only one on WFLY and another on JBEAP with the > description like JBEAP-971: Fix issues in tests with Security Manager > > The last opened issue has two days of age, and I think that will > continue have more of them sooner or later. > > https://issues.jboss.org/browse/WFLY-6189 > https://issues.jboss.org/browse/JBEAP-3376 > https://issues.jboss.org/browse/WFLY-6191 > https://issues.jboss.org/browse/JBEAP-3377 > https://issues.jboss.org/browse/WFLY-6190 > https://issues.jboss.org/browse/WFLY-6192 > https://issues.jboss.org/browse/JBEAP-3378 > https://issues.jboss.org/browse/WFLY-6193 > https://issues.jboss.org/browse/JBEAP-3380 > https://issues.jboss.org/browse/WFLY-6194 > https://issues.jboss.org/browse/JBEAP-3381 > https://issues.jboss.org/browse/WFLY-6195 > https://issues.jboss.org/browse/JBEAP-3382 > https://issues.jboss.org/browse/WFLY-6196 > https://issues.jboss.org/browse/JBEAP-3390 > https://issues.jboss.org/browse/WFLY-6189 > https://issues.jboss.org/browse/JBEAP-3375 > https://issues.jboss.org/browse/JBEAP-971 > https://issues.jboss.org/browse/JBEAP-3382 > > > Regards, > -- > ___________________________ > Eduardo Sant'Ana da Silva - Ph.D. > Researcher / IT Consultant > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Mon Apr 25 08:55:13 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 25 Apr 2016 07:55:13 -0500 Subject: [wildfly-dev] Pattern defined RBAC scoped roles In-Reply-To: <571B1855.9040401@redhat.com> References: <571A3EF9.7050002@redhat.com> <571B1855.9040401@redhat.com> Message-ID: <571E13B1.1010102@redhat.com> Perhaps. I'm a bit bit reluctant to move away from something powerful and standard to something custom. Mostly because it's hard to move the other way in the future while remaining compatible. But your point is well taken. How would you propose discriminating these cases? 1) /subsystem=messaging is not allowed but its children are. 2) /subsystem=messaging and its children are. We also need to think about ObjectName patterns, which are not inherently hierarchical. On 4/23/16 1:38 AM, Ladislav Thon wrote: > I only have a single comment: writing a regular expression can sometimes > be a bit tricky. Just see the example you used: > >> (/profile=[^/]+)??/subsystem=logging(/.*)* > > It's also fairly easy to write a regular expression that doesn't quite > do what you want it to do, in some corner cases. Finally, some > well-crafted regular expressions have running time in years or more (at > least in the java.util.regex implementation). > > This all leads me to believe that maybe regular expressions are not the > best choice. > > Instead, I'm thinking about address prefixes. So the role would be > specified by a set of valid addresses (including the "*" wildcard), and > only the specified resources and all their children would be accessible. > > I'm specifically not thinking about _textual_ prefix, so e.g. prefix of > /subsystem=messaging would give you access to the old messaging > subsystem, but it _wouldn't_ give you access to the new > /subsystem=messaging-activemq, even if /subsystem=messaging is a textual > prefix. > > Granted, that's way less powerful than regular expressions, but also > easier and safer to use. > > WDYT? Am I being too paranoid here? > > LT > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From anilsaldhana at gmail.com Mon Apr 25 09:09:34 2016 From: anilsaldhana at gmail.com (Anil Saldanha) Date: Mon, 25 Apr 2016 08:09:34 -0500 Subject: [wildfly-dev] Pattern defined RBAC scoped roles In-Reply-To: <571E13B1.1010102@redhat.com> References: <571A3EF9.7050002@redhat.com> <571B1855.9040401@redhat.com> <571E13B1.1010102@redhat.com> Message-ID: The challenge with pattern based matching is that you provide access when you should not. Explicit definition of the grants is recommended. So I support your thinking, Brian. > On Apr 25, 2016, at 7:55 AM, Brian Stansberry wrote: > > Perhaps. I'm a bit bit reluctant to move away from something powerful > and standard to something custom. Mostly because it's hard to move the > other way in the future while remaining compatible. But your point is > well taken. > > How would you propose discriminating these cases? > > 1) /subsystem=messaging is not allowed but its children are. > > 2) /subsystem=messaging and its children are. > > We also need to think about ObjectName patterns, which are not > inherently hierarchical. > >> On 4/23/16 1:38 AM, Ladislav Thon wrote: >> I only have a single comment: writing a regular expression can sometimes >> be a bit tricky. Just see the example you used: >> >>> (/profile=[^/]+)??/subsystem=logging(/.*)* >> >> It's also fairly easy to write a regular expression that doesn't quite >> do what you want it to do, in some corner cases. Finally, some >> well-crafted regular expressions have running time in years or more (at >> least in the java.util.regex implementation). >> >> This all leads me to believe that maybe regular expressions are not the >> best choice. >> >> Instead, I'm thinking about address prefixes. So the role would be >> specified by a set of valid addresses (including the "*" wildcard), and >> only the specified resources and all their children would be accessible. >> >> I'm specifically not thinking about _textual_ prefix, so e.g. prefix of >> /subsystem=messaging would give you access to the old messaging >> subsystem, but it _wouldn't_ give you access to the new >> /subsystem=messaging-activemq, even if /subsystem=messaging is a textual >> prefix. >> >> Granted, that's way less powerful than regular expressions, but also >> easier and safer to use. >> >> WDYT? Am I being too paranoid here? >> >> LT >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From lthon at redhat.com Mon Apr 25 09:26:56 2016 From: lthon at redhat.com (Ladislav Thon) Date: Mon, 25 Apr 2016 15:26:56 +0200 Subject: [wildfly-dev] Pattern defined RBAC scoped roles In-Reply-To: <571E13B1.1010102@redhat.com> References: <571A3EF9.7050002@redhat.com> <571B1855.9040401@redhat.com> <571E13B1.1010102@redhat.com> Message-ID: <571E1B20.3090805@redhat.com> > How would you propose discriminating these cases? > > 1) /subsystem=messaging is not allowed but its children are. > > 2) /subsystem=messaging and its children are. Well, there's not a lot of possibilities with a rigid scheme I'm proposing. A boolean attribute 'children-only' is the only thing I can come up with. I'll be the first to admit that a regexp-based scheme is inherently very flexible, no doubt about that. (But with great power ...) LT From kabir.khan at jboss.com Mon Apr 25 09:38:51 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Mon, 25 Apr 2016 14:38:51 +0100 Subject: [wildfly-dev] Pattern defined RBAC scoped roles In-Reply-To: <571E1B20.3090805@redhat.com> References: <571A3EF9.7050002@redhat.com> <571B1855.9040401@redhat.com> <571E13B1.1010102@redhat.com> <571E1B20.3090805@redhat.com> Message-ID: > On 25 Apr 2016, at 14:26, Ladislav Thon wrote: > >> How would you propose discriminating these cases? >> >> 1) /subsystem=messaging is not allowed but its children are. >> >> 2) /subsystem=messaging and its children are. > > Well, there's not a lot of possibilities with a rigid scheme I'm > proposing. A boolean attribute 'children-only' is the only thing I can > come up with. > > I'll be the first to admit that a regexp-based scheme is inherently very > flexible, no doubt about that. (But with great power ...) To help with this, could we not add an operation which shows which resources will be granted access? > > LT > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Mon Apr 25 10:28:57 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 25 Apr 2016 09:28:57 -0500 Subject: [wildfly-dev] Pattern defined RBAC scoped roles In-Reply-To: References: <571A3EF9.7050002@redhat.com> <571B1855.9040401@redhat.com> <571E13B1.1010102@redhat.com> Message-ID: <571E29A9.8090003@redhat.com> On 4/25/16 8:09 AM, Anil Saldanha wrote: > The challenge with pattern based matching is that you provide access when you should not. Explicit definition of the grants is recommended. > > So I support your thinking, Brian. > Did you mean you support Ladislav's thinking? His proposed approach is more explicit. >> On Apr 25, 2016, at 7:55 AM, Brian Stansberry wrote: >> >> Perhaps. I'm a bit bit reluctant to move away from something powerful >> and standard to something custom. Mostly because it's hard to move the >> other way in the future while remaining compatible. But your point is >> well taken. >> >> How would you propose discriminating these cases? >> >> 1) /subsystem=messaging is not allowed but its children are. >> >> 2) /subsystem=messaging and its children are. >> >> We also need to think about ObjectName patterns, which are not >> inherently hierarchical. >> >>> On 4/23/16 1:38 AM, Ladislav Thon wrote: >>> I only have a single comment: writing a regular expression can sometimes >>> be a bit tricky. Just see the example you used: >>> >>>> (/profile=[^/]+)??/subsystem=logging(/.*)* >>> >>> It's also fairly easy to write a regular expression that doesn't quite >>> do what you want it to do, in some corner cases. Finally, some >>> well-crafted regular expressions have running time in years or more (at >>> least in the java.util.regex implementation). >>> >>> This all leads me to believe that maybe regular expressions are not the >>> best choice. >>> >>> Instead, I'm thinking about address prefixes. So the role would be >>> specified by a set of valid addresses (including the "*" wildcard), and >>> only the specified resources and all their children would be accessible. >>> >>> I'm specifically not thinking about _textual_ prefix, so e.g. prefix of >>> /subsystem=messaging would give you access to the old messaging >>> subsystem, but it _wouldn't_ give you access to the new >>> /subsystem=messaging-activemq, even if /subsystem=messaging is a textual >>> prefix. >>> >>> Granted, that's way less powerful than regular expressions, but also >>> easier and safer to use. >>> >>> WDYT? Am I being too paranoid here? >>> >>> LT >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Mon Apr 25 10:37:26 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 25 Apr 2016 09:37:26 -0500 Subject: [wildfly-dev] Pattern defined RBAC scoped roles In-Reply-To: References: <571A3EF9.7050002@redhat.com> <571B1855.9040401@redhat.com> <571E13B1.1010102@redhat.com> <571E1B20.3090805@redhat.com> Message-ID: <571E2BA6.5000302@redhat.com> On 4/25/16 8:38 AM, Kabir Khan wrote: > >> On 25 Apr 2016, at 14:26, Ladislav Thon wrote: >> >>> How would you propose discriminating these cases? >>> >>> 1) /subsystem=messaging is not allowed but its children are. >>> >>> 2) /subsystem=messaging and its children are. >> >> Well, there's not a lot of possibilities with a rigid scheme I'm >> proposing. A boolean attribute 'children-only' is the only thing I can >> come up with. >> Darn! I was hoping for an easy answer and asked because I didn't have time at the moment to think. I'm still hoping. ;) TBH, 'children-only' isn't so terrible if there isn't some standard syntax for this kind of thing. >> I'll be the first to admit that a regexp-based scheme is inherently very >> flexible, no doubt about that. (But with great power ...) > To help with this, could we not add an operation which shows which resources will be granted access? I'm not sure how that could work if the base-role is Operator, which only has rights to runtime-only changes. For base roles with perms to write the config we could recursively test OperationContext.readResourceForUpdate() but that wouldn't show any perms at all for Operator. >> >> LT >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From anilsaldhana at gmail.com Mon Apr 25 11:07:11 2016 From: anilsaldhana at gmail.com (Anil Saldanha) Date: Mon, 25 Apr 2016 10:07:11 -0500 Subject: [wildfly-dev] Pattern defined RBAC scoped roles In-Reply-To: <571E29A9.8090003@redhat.com> References: <571A3EF9.7050002@redhat.com> <571B1855.9040401@redhat.com> <571E13B1.1010102@redhat.com> <571E29A9.8090003@redhat.com> Message-ID: Hi Brian - I was just making a generic statement about staying away from pattern matching in ACLs given it is hard to debug and the possibility of Allow instead of Deny in unintended cases. Having explicit grants will make it cleaner. On Mon, Apr 25, 2016 at 9:28 AM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > On 4/25/16 8:09 AM, Anil Saldanha wrote: > >> The challenge with pattern based matching is that you provide access when >> you should not. Explicit definition of the grants is recommended. >> >> So I support your thinking, Brian. >> >> > Did you mean you support Ladislav's thinking? His proposed approach is > more explicit. > > > On Apr 25, 2016, at 7:55 AM, Brian Stansberry >>> wrote: >>> >>> Perhaps. I'm a bit bit reluctant to move away from something powerful >>> and standard to something custom. Mostly because it's hard to move the >>> other way in the future while remaining compatible. But your point is >>> well taken. >>> >>> How would you propose discriminating these cases? >>> >>> 1) /subsystem=messaging is not allowed but its children are. >>> >>> 2) /subsystem=messaging and its children are. >>> >>> We also need to think about ObjectName patterns, which are not >>> inherently hierarchical. >>> >>> On 4/23/16 1:38 AM, Ladislav Thon wrote: >>>> I only have a single comment: writing a regular expression can sometimes >>>> be a bit tricky. Just see the example you used: >>>> >>>> (/profile=[^/]+)??/subsystem=logging(/.*)* >>>>> >>>> >>>> It's also fairly easy to write a regular expression that doesn't quite >>>> do what you want it to do, in some corner cases. Finally, some >>>> well-crafted regular expressions have running time in years or more (at >>>> least in the java.util.regex implementation). >>>> >>>> This all leads me to believe that maybe regular expressions are not the >>>> best choice. >>>> >>>> Instead, I'm thinking about address prefixes. So the role would be >>>> specified by a set of valid addresses (including the "*" wildcard), and >>>> only the specified resources and all their children would be accessible. >>>> >>>> I'm specifically not thinking about _textual_ prefix, so e.g. prefix of >>>> /subsystem=messaging would give you access to the old messaging >>>> subsystem, but it _wouldn't_ give you access to the new >>>> /subsystem=messaging-activemq, even if /subsystem=messaging is a textual >>>> prefix. >>>> >>>> Granted, that's way less powerful than regular expressions, but also >>>> easier and safer to use. >>>> >>>> WDYT? Am I being too paranoid here? >>>> >>>> LT >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >>> -- >>> Brian Stansberry >>> Senior Principal Software Engineer >>> JBoss by Red Hat >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160425/126188f6/attachment.html From jmesnil at redhat.com Mon Apr 25 11:15:24 2016 From: jmesnil at redhat.com (Jeff Mesnil) Date: Mon, 25 Apr 2016 17:15:24 +0200 Subject: [wildfly-dev] Proposal to improve resource description and registration Message-ID: <386B359A-0D7D-443D-BF8B-FB965CC5CDDD@redhat.com> TL;DR - I propose to simplify subsystem development by moving some of the validation logic from the resource definitions to the management resource registration. The goal is to provide a static representation of the resources and let the MMR dynamically pick the ?meaningful? parts. Last week an user complains that the messaging-activemq subsystem?s statistics were not updated in domain mode. It turned out that he was reading the metrics on the DC (/profile=full/subsytem=messaging-activemq/?) instead of reading on the server (/host=master/server=server-one/subsystem=messaging-activemq/?) It is a bug[1] in the messaging-activemq because its resources register their metrics without checking whether that makes sense. The correct check is to look at context.isRuntimeOnlyRegistrationValid() to check whether a resource can register its metrics (the same check applies also for runtime attributes/operations). I looked at other subsystems and undertow has the same issue. This check does not work well with the PersistentResourceDefinition that is used throughout the messaging-activemq and undertow subsystems. This API works best when the definition of the resources uses a bunch of static instances for the resource itself, its attributes, metrics, etc. These static instances are also used by the companion PersistentResourceXMLDescription to provide a static XML representation of the subsystem. If I have to pass this context.isRuntimeOnlyRegistrationValid() boolean to every resources in the subsystem, I get rid of the static representations used by the PersistentResourceDefinition and PersistentResourceXMLDescription and I have to add a lot of simple but boilerplate code in all my resource definitions. The datasources subsystem does not exhibit this issue. It works around it by installing a Service at RUNTIME step to register (resp. unregister) statistics resource definitions when the service is started (res. stopped). Since services are only installed when runtime is supported, it ensures that the datasources metrics are available only on server and not on the DC. It looks correct but I?m not a big fan of this solution. It makes the subsystem definition more complex to understand and it also involves boilerplate code that every subsystem providing runtime should write. I was wondering if we could simplify the development of the subsystems by moving some of the logic dealing with that use case in the ManagementResourceRegistration instead. My proposal would be to have the resource definitions be ?complete?. The resource always defines its attributes/metrics/operations. When the MMR takes this definition and registers the different parts, it would only register the ?meaningful? one depending on the ProcessType and RunningMode. E.g. the MRR of the DC or a admin-only server would not register metrics & runtime attributes/operations while the MMR on a normal server would register everything. This increase the complexity of the MMR which has to figure out whether to actually register something or discard it but it makes writing subsystem simpler and more robust. Brian told me there might some exceptions (e.g. a runtime op that could be invoked on the DC) but these case could be handled by adding metadata to the resource definitions. This approach segues quite well with the idea to generate subsystem using annotations. All the subsystem developers has to do is describe extensively the subsystem resources (using static objects now, annotations in a future version) and let the MMR decides which parts of the resources are actually registered. To sum up, the definition of a resource is static, while its registration is dynamic. Do you see any issue with that proposal? As a first step, I?ll start by creating the corresponding WFCORE issue to fix WFLY-6546 issue by ensuring the MMR does not register metric if the runtime registration is not valid. This should not have any API impact (but the behaviour will certainly change). jeff [1] https://issues.jboss.org/browse/WFLY-6546 -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From brian.stansberry at redhat.com Mon Apr 25 11:46:48 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 25 Apr 2016 10:46:48 -0500 Subject: [wildfly-dev] Proposal to improve resource description and registration In-Reply-To: <386B359A-0D7D-443D-BF8B-FB965CC5CDDD@redhat.com> References: <386B359A-0D7D-443D-BF8B-FB965CC5CDDD@redhat.com> Message-ID: <571E3BE8.9090206@redhat.com> I think it's the right direction. It will just take some care to not break stuff by not registering stuff that really should be registered. Good news is I had the same concern about https://issues.jboss.org/browse/WFCORE-831 but it seems there wasn't much of a problem. Twists to think about in this: 1) The "runtime-only but ok on the DC" case I mentioned, but I think that's solvable with more metadata, and we don't support it now so you won't break anything. 2) Subsystems running on the HC. I don't have any good reason why these would be an issue; I'm just pointing them out as something to remember as pretty much no one but Kabir has dealt with them. The context.isRuntimeOnlyRegistrationValid() provides the correct response for those. 3) Definitions of runtime-only child resources. This one is a bit more tricky. To be consistent they should be handled similarly to how you propose dealing with metrics. But they are different -- the code that registers the runtime-only ResourceDef may then go on and try to use the returned MRR, or may even come back later and look it up. But really the MRR shouldn't end up in the tree at all. Good news about 3) is code that is doing what I describe is probably already guarding that work with context.isRuntimeOnlyRegistrationValid(). So changing something probably won't break that code. 4) API change. Doing this is going to introduce management API changes, by removing stuff that should have never been there. So we need to account for that (probably bump API versions, check for console breakage.) BTW, the datasource subsystem thing is a bit of a different beast. The actual list of metrics is not known until runtime, because they vary based on the driver. That's why the registration is done that way. - Brian On 4/25/16 10:15 AM, Jeff Mesnil wrote: > TL;DR - I propose to simplify subsystem development by moving some of the validation logic from the resource definitions to the management resource registration. The goal is to provide a static representation of the resources and let the MMR dynamically pick the ?meaningful? parts. > > Last week an user complains that the messaging-activemq subsystem?s statistics were not updated in domain mode. > It turned out that he was reading the metrics on the DC (/profile=full/subsytem=messaging-activemq/?) instead of reading on the server (/host=master/server=server-one/subsystem=messaging-activemq/?) > > It is a bug[1] in the messaging-activemq because its resources register their metrics without checking whether that makes sense. The correct check is to look at context.isRuntimeOnlyRegistrationValid() to check whether a resource can register its metrics (the same check applies also for runtime attributes/operations). > I looked at other subsystems and undertow has the same issue. > > This check does not work well with the PersistentResourceDefinition that is used throughout the messaging-activemq and undertow subsystems. This API works best when the definition of the resources uses a bunch of static instances for the resource itself, its attributes, metrics, etc. These static instances are also used by the companion PersistentResourceXMLDescription to provide a static XML representation of the subsystem. > If I have to pass this context.isRuntimeOnlyRegistrationValid() boolean to every resources in the subsystem, I get rid of the static representations used by the PersistentResourceDefinition and PersistentResourceXMLDescription and I have to add a lot of simple but boilerplate code in all my resource definitions. > > The datasources subsystem does not exhibit this issue. It works around it by installing a Service at RUNTIME step to register (resp. unregister) statistics resource definitions when the service is started (res. stopped). Since services are only installed when runtime is supported, it ensures that the datasources metrics are available only on server and not on the DC. > It looks correct but I?m not a big fan of this solution. It makes the subsystem definition more complex to understand and it also involves boilerplate code that every subsystem providing runtime should write. > > I was wondering if we could simplify the development of the subsystems by moving some of the logic dealing with that use case in the ManagementResourceRegistration instead. > > My proposal would be to have the resource definitions be ?complete?. The resource always defines its attributes/metrics/operations. > When the MMR takes this definition and registers the different parts, it would only register the ?meaningful? one depending on the ProcessType and RunningMode. E.g. the MRR of the DC or a admin-only server would not register metrics & runtime attributes/operations while the MMR on a normal server would register everything. > This increase the complexity of the MMR which has to figure out whether to actually register something or discard it but it makes writing subsystem simpler and more robust. > > Brian told me there might some exceptions (e.g. a runtime op that could be invoked on the DC) but these case could be handled by adding metadata to the resource definitions. > > This approach segues quite well with the idea to generate subsystem using annotations. All the subsystem developers has to do is describe extensively the subsystem resources (using static objects now, annotations in a future version) and let the MMR decides which parts of the resources are actually registered. > > To sum up, the definition of a resource is static, while its registration is dynamic. > > Do you see any issue with that proposal? > As a first step, I?ll start by creating the corresponding WFCORE issue to fix WFLY-6546 issue by ensuring the MMR does not register metric if the runtime registration is not valid. This should not have any API impact (but the behaviour will certainly change). > > jeff > > [1] https://issues.jboss.org/browse/WFLY-6546 > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Mon Apr 25 11:59:46 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 25 Apr 2016 10:59:46 -0500 Subject: [wildfly-dev] Pattern defined RBAC scoped roles In-Reply-To: References: <571A3EF9.7050002@redhat.com> <571B1855.9040401@redhat.com> <571E13B1.1010102@redhat.com> <571E29A9.8090003@redhat.com> Message-ID: <571E3EF2.2060703@redhat.com> Gotcha; thanks. I think there are two basic (non-regex) patterns that are likely to be useful: 1) Cross-profile perms /profile=*/subsystem=logging vs /profile=default/subsystem=logging /profile=ha/subsystem=logging ... /profile=prof-52/subsystem=logging 2) Granting perms for an address and its children/ /subsystem=logging/** Clean handling of 2) is a must. I'm sure we'd get complaints if we didn't support 1). But full regex support isn't needed for those two. On 4/25/16 10:07 AM, Anil Saldanha wrote: > Hi Brian - I was just making a generic statement about staying away from > pattern matching in ACLs given it is hard to debug and the possibility > of Allow instead of Deny in unintended cases. Having explicit grants > will make it cleaner. > > On Mon, Apr 25, 2016 at 9:28 AM, Brian Stansberry > > wrote: > > On 4/25/16 8:09 AM, Anil Saldanha wrote: > > The challenge with pattern based matching is that you provide > access when you should not. Explicit definition of the grants is > recommended. > > So I support your thinking, Brian. > > > Did you mean you support Ladislav's thinking? His proposed approach > is more explicit. > > > On Apr 25, 2016, at 7:55 AM, Brian Stansberry > > wrote: > > Perhaps. I'm a bit bit reluctant to move away from something > powerful > and standard to something custom. Mostly because it's hard > to move the > other way in the future while remaining compatible. But your > point is > well taken. > > How would you propose discriminating these cases? > > 1) /subsystem=messaging is not allowed but its children are. > > 2) /subsystem=messaging and its children are. > > We also need to think about ObjectName patterns, which are not > inherently hierarchical. > > On 4/23/16 1:38 AM, Ladislav Thon wrote: > I only have a single comment: writing a regular > expression can sometimes > be a bit tricky. Just see the example you used: > > (/profile=[^/]+)??/subsystem=logging(/.*)* > > > It's also fairly easy to write a regular expression that > doesn't quite > do what you want it to do, in some corner cases. > Finally, some > well-crafted regular expressions have running time in > years or more (at > least in the java.util.regex implementation). > > This all leads me to believe that maybe regular > expressions are not the > best choice. > > Instead, I'm thinking about address prefixes. So the > role would be > specified by a set of valid addresses (including the "*" > wildcard), and > only the specified resources and all their children > would be accessible. > > I'm specifically not thinking about _textual_ prefix, so > e.g. prefix of > /subsystem=messaging would give you access to the old > messaging > subsystem, but it _wouldn't_ give you access to the new > /subsystem=messaging-activemq, even if > /subsystem=messaging is a textual > prefix. > > Granted, that's way less powerful than regular > expressions, but also > easier and safer to use. > > WDYT? Am I being too paranoid here? > > LT > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From mazz at redhat.com Mon Apr 25 12:15:45 2016 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 25 Apr 2016 12:15:45 -0400 (EDT) Subject: [wildfly-dev] trying to run subsystem extension in host controller In-Reply-To: <560093326.114160.1461599174992.JavaMail.zimbra@redhat.com> Message-ID: <1376054931.123913.1461600945091.JavaMail.zimbra@redhat.com> Trying to run a subsystem extension in host controller and it fails because some of its service dependencies are missing. Am I doing something wrong (it would not be a shocker if I was) or are these services really not deployed inside the Host Controller? I'm trying to get a subsystem extension to run inside of the Host Controller. This is a subsystem extension that runs fine in a standalone WildFly container - just trying to get it to run in a host controller (and maybe later in a domain controller as well). In domain/configuration/host.xml, I add my own in the - and that seems to run OK (well, not OK, but I know it is getting its initialization method invoked by the container). Because I need an outbound socket binding defined, I put add a socket-binding-groups in the host.xml (there are no socket-binding-groups in here by default): That causes the container to abort with "WFLYCTL0198: Unexpected element '{urn:jboss:domain:4.0}socket-binding-groups' encountered" So I remove so that is a direct child of the top-level . The container starts OK when I do this. But now the problems - my subsystem registers itself with a few service dependencies that do not exist at the time my service is initialized - specifically: jboss.naming.context.java (o.j.a.naming.deployment.ContextNames.JAVA_CONTEXT_SERVICE_NAME) jboss.outbound-socket-binding (o.j.a.network.OutboundSocketBinding.OUTBOUND_SOCKET_BINDING_BASE_SERVICE_NAME) jboss.server.environment (o.j.a.server.ServerEnvironmentService.SERVICE_NAME) jboss.as.server-controller (o.j.a.server.Services.JBOSS_SERVER_CONTROLLER) When the host controller runs, I get this startup error: ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("host" => "master"), ("subsystem" => "hawkular-wildfly-agent") ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => [ "\"org.hawkular.agent.\".hawkular-wildfly-agent is missing [jboss.outbound-socket-binding.hawkular, jboss.server.environment, jboss.as.server-controller]", "jboss.naming.context.java.abc is missing [jboss.naming.context.java]" ]} Sooo..... my question is - what happens if a subsystem needs these things? Do I need to do something special to make them available or are they really not deployed in the host controller? What I need these for is: jboss.naming.context.java - so I can store something in JNDI (actually, for my use case, I can probably skip this dependency - I don't think I will need it when running in the host controller) jboss.outbound-socket-binding - my subsystem needs to talk to an external server and this defines what host/port that server is on jboss.server.environment - I need this to find out where the host controller's data directory is (e.g. domain/data). Is there another way to get this? jboss.as.server-controller - I need this to obtain information from the management model such as "/:uuid" (which it looks like HCs do not have), the "/:launch-type" attribute and others. From tomaz.cerar at gmail.com Mon Apr 25 12:46:28 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 25 Apr 2016 18:46:28 +0200 Subject: [wildfly-dev] Proposal to improve resource description and registration In-Reply-To: <571E3BE8.9090206@redhat.com> References: <386B359A-0D7D-443D-BF8B-FB965CC5CDDD@redhat.com> <571E3BE8.9090206@redhat.com> Message-ID: There was already discussion to change PeristentResourceDefinition and others to behave the way you describe. One part of that was related to https://issues.jboss.org/browse/WFCORE-831 as Brian pointed out already. The other part was potential breaking / change in APIs and was the reason why it was postponed to after EAP7. In short, lets do this. -- tomaz On Mon, Apr 25, 2016 at 5:46 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > I think it's the right direction. It will just take some care to not > break stuff by not registering stuff that really should be registered. > > Good news is I had the same concern about > https://issues.jboss.org/browse/WFCORE-831 but it seems there wasn't > much of a problem. > > Twists to think about in this: > > 1) The "runtime-only but ok on the DC" case I mentioned, but I think > that's solvable with more metadata, and we don't support it now so you > won't break anything. > > 2) Subsystems running on the HC. I don't have any good reason why these > would be an issue; I'm just pointing them out as something to remember > as pretty much no one but Kabir has dealt with them. The > context.isRuntimeOnlyRegistrationValid() provides the correct response > for those. > > 3) Definitions of runtime-only child resources. This one is a bit more > tricky. To be consistent they should be handled similarly to how you > propose dealing with metrics. But they are different -- the code that > registers the runtime-only ResourceDef may then go on and try to use the > returned MRR, or may even come back later and look it up. But really the > MRR shouldn't end up in the tree at all. > > Good news about 3) is code that is doing what I describe is probably > already guarding that work with > context.isRuntimeOnlyRegistrationValid(). So changing something probably > won't break that code. > > 4) API change. Doing this is going to introduce management API changes, > by removing stuff that should have never been there. So we need to > account for that (probably bump API versions, check for console breakage.) > > > BTW, the datasource subsystem thing is a bit of a different beast. The > actual list of metrics is not known until runtime, because they vary > based on the driver. That's why the registration is done that way. > > - Brian > > On 4/25/16 10:15 AM, Jeff Mesnil wrote: > > TL;DR - I propose to simplify subsystem development by moving some of > the validation logic from the resource definitions to the management > resource registration. The goal is to provide a static representation of > the resources and let the MMR dynamically pick the ?meaningful? parts. > > > > Last week an user complains that the messaging-activemq subsystem?s > statistics were not updated in domain mode. > > It turned out that he was reading the metrics on the DC > (/profile=full/subsytem=messaging-activemq/?) instead of reading on the > server (/host=master/server=server-one/subsystem=messaging-activemq/?) > > > > It is a bug[1] in the messaging-activemq because its resources register > their metrics without checking whether that makes sense. The correct check > is to look at context.isRuntimeOnlyRegistrationValid() to check whether a > resource can register its metrics (the same check applies also for runtime > attributes/operations). > > I looked at other subsystems and undertow has the same issue. > > > > This check does not work well with the PersistentResourceDefinition that > is used throughout the messaging-activemq and undertow subsystems. This API > works best when the definition of the resources uses a bunch of static > instances for the resource itself, its attributes, metrics, etc. These > static instances are also used by the companion > PersistentResourceXMLDescription to provide a static XML representation of > the subsystem. > > If I have to pass this context.isRuntimeOnlyRegistrationValid() boolean > to every resources in the subsystem, I get rid of the static > representations used by the PersistentResourceDefinition and > PersistentResourceXMLDescription and I have to add a lot of simple but > boilerplate code in all my resource definitions. > > > > The datasources subsystem does not exhibit this issue. It works around > it by installing a Service at RUNTIME step to register (resp. unregister) > statistics resource definitions when the service is started (res. stopped). > Since services are only installed when runtime is supported, it ensures > that the datasources metrics are available only on server and not on the DC. > > It looks correct but I?m not a big fan of this solution. It makes the > subsystem definition more complex to understand and it also involves > boilerplate code that every subsystem providing runtime should write. > > > > I was wondering if we could simplify the development of the subsystems > by moving some of the logic dealing with that use case in the > ManagementResourceRegistration instead. > > > > My proposal would be to have the resource definitions be ?complete?. The > resource always defines its attributes/metrics/operations. > > When the MMR takes this definition and registers the different parts, it > would only register the ?meaningful? one depending on the ProcessType and > RunningMode. E.g. the MRR of the DC or a admin-only server would not > register metrics & runtime attributes/operations while the MMR on a normal > server would register everything. > > This increase the complexity of the MMR which has to figure out whether > to actually register something or discard it but it makes writing subsystem > simpler and more robust. > > > > Brian told me there might some exceptions (e.g. a runtime op that could > be invoked on the DC) but these case could be handled by adding metadata to > the resource definitions. > > > > This approach segues quite well with the idea to generate subsystem > using annotations. All the subsystem developers has to do is describe > extensively the subsystem resources (using static objects now, annotations > in a future version) and let the MMR decides which parts of the resources > are actually registered. > > > > To sum up, the definition of a resource is static, while its > registration is dynamic. > > > > Do you see any issue with that proposal? > > As a first step, I?ll start by creating the corresponding WFCORE issue > to fix WFLY-6546 issue by ensuring the MMR does not register metric if the > runtime registration is not valid. This should not have any API impact (but > the behaviour will certainly change). > > > > jeff > > > > [1] https://issues.jboss.org/browse/WFLY-6546 > > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160425/08626f95/attachment-0001.html From kabir.khan at jboss.com Mon Apr 25 13:39:15 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Mon, 25 Apr 2016 18:39:15 +0100 Subject: [wildfly-dev] trying to run subsystem extension in host controller In-Reply-To: <1376054931.123913.1461600945091.JavaMail.zimbra@redhat.com> References: <1376054931.123913.1461600945091.JavaMail.zimbra@redhat.com> Message-ID: <6D912028-E5D1-47E6-B708-8D6917306F56@jboss.com> Seems you have hit some of the tweaks needed that I mentioned :) I'll try to explain a bit below. Other things to look out for are that all the paths relating to data, configuration paths etc. have a different name in the HC to on a server (see the constants in ServerEnvironment vs HostControllerEnvironment). > On 25 Apr 2016, at 17:15, John Mazzitelli wrote: > > > > Trying to run a subsystem extension in host controller and it fails because some of its service dependencies are missing. Am I doing something wrong (it would not be a shocker if I was) or are these services really not deployed inside the Host Controller? > > > > I'm trying to get a subsystem extension to run inside of the Host Controller. This is a subsystem extension that runs fine in a standalone WildFly container - just trying to get it to run in a host controller (and maybe later in a domain controller as well). > > In domain/configuration/host.xml, I add my own in the - and that seems to run OK (well, not OK, but I know it is getting its initialization method invoked by the container). > > Because I need an outbound socket binding defined, I put add a socket-binding-groups in the host.xml (there are no socket-binding-groups in here by default): > > > > > > > > > > That causes the container to abort with "WFLYCTL0198: Unexpected element '{urn:jboss:domain:4.0}socket-binding-groups' encountered" So I remove so that is a direct child of the top-level . The container starts OK when I do this. Correct. According to the xsd, only one socket-binding-group is allowed in host.xml > > But now the problems - my subsystem registers itself with a few service dependencies that do not exist at the time my service is initialized - specifically: > > jboss.naming.context.java (o.j.a.naming.deployment.ContextNames.JAVA_CONTEXT_SERVICE_NAME) This would be installed by the naming subsystem, which is not a host capable subsystem. So there cannot be any jndi on a HC at the moment. > > jboss.outbound-socket-binding (o.j.a.network.OutboundSocketBinding.OUTBOUND_SOCKET_BINDING_BASE_SERVICE_NAME) I see the same thing https://issues.jboss.org/browse/WFCORE-1505. > > jboss.server.environment (o.j.a.server.ServerEnvironmentService.SERVICE_NAME) This would only be available in a server. However, there is no corresponding service in a host controller to get the HostControllerEnvironment. Perhaps we should add one https://issues.jboss.org/browse/WFCORE-1506. > > jboss.as.server-controller (o.j.a.server.Services.JBOSS_SERVER_CONTROLLER) In a HC you need to depend on the DomainModelControllerService instead, it's name is in DomainModelControllerService.SERVICE_NAME. Both services contain a ModelController, you will need to choose the name to depend on according to the process type. > > When the host controller runs, I get this startup error: > > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("host" => "master"), > ("subsystem" => "hawkular-wildfly-agent") > ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => [ > "\"org.hawkular.agent.\".hawkular-wildfly-agent is missing [jboss.outbound-socket-binding.hawkular, jboss.server.environment, jboss.as.server-controller]", > "jboss.naming.context.java.abc is missing [jboss.naming.context.java]" > ]} > > Sooo..... my question is - what happens if a subsystem needs these things? Do I need to do something special to make them available or are they really not deployed in the host controller? > > What I need these for is: > > jboss.naming.context.java - so I can store something in JNDI (actually, for my use case, I can probably skip this dependency - I don't think I will need it when running in the host controller) I don't think this is anything we can do at the moment, so hopefully you can do without. > > jboss.outbound-socket-binding - my subsystem needs to talk to an external server and this defines what host/port that server is on I'll look at adding this to WildFly. If this needs backporting to EAP 7.0.x, please let us know so we can put it into the process. > > jboss.server.environment - I need this to find out where the host controller's data directory is (e.g. domain/data). Is there another way to get this? I believe you should be able to get this by reading the following system property (taken from HostControllerEnvironment): /** * Constant that holds the name of the system property * for specifying {@link #getDomainDataDir()} the domain data directory}. * *

Defaults to DOMAIN_BASE_DIR/data. */ public static final String DOMAIN_DATA_DIR = "jboss.domain.data.dir"; > jboss.as.server-controller - I need this to obtain information from the management model such as "/:uuid" (which it looks like HCs do not have), the "/:launch-type" attribute and others. You will need to use the HC one as mentioned above I think that of the bugs/missing things you mention https://issues.jboss.org/browse/WFCORE-1505 (missing outbound socket binding service) is the one that looks like it blocks you the most, so I will see if that is fixable first. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From kabir.khan at jboss.com Mon Apr 25 13:56:47 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Mon, 25 Apr 2016 18:56:47 +0100 Subject: [wildfly-dev] trying to run subsystem extension in host controller In-Reply-To: <6D912028-E5D1-47E6-B708-8D6917306F56@jboss.com> References: <1376054931.123913.1461600945091.JavaMail.zimbra@redhat.com> <6D912028-E5D1-47E6-B708-8D6917306F56@jboss.com> Message-ID: > On 25 Apr 2016, at 18:39, Kabir Khan wrote: > > Seems you have hit some of the tweaks needed that I mentioned :) > > I'll try to explain a bit below. Other things to look out for are that all the paths relating to data, configuration paths etc. have a different name in the HC to on a server (see the constants in ServerEnvironment vs HostControllerEnvironment). >> On 25 Apr 2016, at 17:15, John Mazzitelli wrote: >> >> >> >> Trying to run a subsystem extension in host controller and it fails because some of its service dependencies are missing. Am I doing something wrong (it would not be a shocker if I was) or are these services really not deployed inside the Host Controller? >> >> >> >> I'm trying to get a subsystem extension to run inside of the Host Controller. This is a subsystem extension that runs fine in a standalone WildFly container - just trying to get it to run in a host controller (and maybe later in a domain controller as well). >> >> In domain/configuration/host.xml, I add my own in the - and that seems to run OK (well, not OK, but I know it is getting its initialization method invoked by the container). >> >> Because I need an outbound socket binding defined, I put add a socket-binding-groups in the host.xml (there are no socket-binding-groups in here by default): >> >> >> >> >> >> >> >> >> >> That causes the container to abort with "WFLYCTL0198: Unexpected element '{urn:jboss:domain:4.0}socket-binding-groups' encountered" So I remove so that is a direct child of the top-level . The container starts OK when I do this. > Correct. According to the xsd, only one socket-binding-group is allowed in host.xml > >> >> But now the problems - my subsystem registers itself with a few service dependencies that do not exist at the time my service is initialized - specifically: >> >> jboss.naming.context.java (o.j.a.naming.deployment.ContextNames.JAVA_CONTEXT_SERVICE_NAME) > This would be installed by the naming subsystem, which is not a host capable subsystem. So there cannot be any jndi on a HC at the moment. >> >> jboss.outbound-socket-binding (o.j.a.network.OutboundSocketBinding.OUTBOUND_SOCKET_BINDING_BASE_SERVICE_NAME) > I see the same thing https://issues.jboss.org/browse/WFCORE-1505. > >> >> jboss.server.environment (o.j.a.server.ServerEnvironmentService.SERVICE_NAME) > This would only be available in a server. However, there is no corresponding service in a host controller to get the HostControllerEnvironment. Perhaps we should add one https://issues.jboss.org/browse/WFCORE-1506. >> >> jboss.as.server-controller (o.j.a.server.Services.JBOSS_SERVER_CONTROLLER) > > In a HC you need to depend on the DomainModelControllerService instead, it's name is in DomainModelControllerService.SERVICE_NAME. > Both services contain a ModelController, you will need to choose the name to depend on according to the process type. > >> >> When the host controller runs, I get this startup error: >> >> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ >> ("host" => "master"), >> ("subsystem" => "hawkular-wildfly-agent") >> ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => [ >> "\"org.hawkular.agent.\".hawkular-wildfly-agent is missing [jboss.outbound-socket-binding.hawkular, jboss.server.environment, jboss.as.server-controller]", >> "jboss.naming.context.java.abc is missing [jboss.naming.context.java]" >> ]} >> >> Sooo..... my question is - what happens if a subsystem needs these things? Do I need to do something special to make them available or are they really not deployed in the host controller? >> >> What I need these for is: >> >> jboss.naming.context.java - so I can store something in JNDI (actually, for my use case, I can probably skip this dependency - I don't think I will need it when running in the host controller) > I don't think this is anything we can do at the moment, so hopefully you can do without. >> >> jboss.outbound-socket-binding - my subsystem needs to talk to an external server and this defines what host/port that server is on > I'll look at adding this to WildFly. If this needs backporting to EAP 7.0.x, please let us know so we can put it into the process. >> >> jboss.server.environment - I need this to find out where the host controller's data directory is (e.g. domain/data). Is there another way to get this? > I believe you should be able to get this by reading the following system property (taken from HostControllerEnvironment): > > > /** > * Constant that holds the name of the system property > * for specifying {@link #getDomainDataDir()} the domain data directory}. > * > *

Defaults to DOMAIN_BASE_DIR/data. > */ > public static final String DOMAIN_DATA_DIR = "jboss.domain.data.dir"; > > >> jboss.as.server-controller - I need this to obtain information from the management model such as "/:uuid" (which it looks like HCs do not have), the "/:launch-type" attribute and others. > You will need to use the HC one as mentioned above > > > I think that of the bugs/missing things you mention https://issues.jboss.org/browse/WFCORE-1505 (missing outbound socket binding service) is the one that looks like it blocks you the most, so I will see if that is fixable first. https://github.com/wildfly/wildfly-core/pull/1520 >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From kabir.khan at jboss.com Mon Apr 25 14:51:10 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Mon, 25 Apr 2016 19:51:10 +0100 Subject: [wildfly-dev] trying to run subsystem extension in host controller In-Reply-To: References: <1376054931.123913.1461600945091.JavaMail.zimbra@redhat.com> <6D912028-E5D1-47E6-B708-8D6917306F56@jboss.com> Message-ID: <219BD9A2-ACC5-4E4C-991C-2455A9A86061@jboss.com> > On 25 Apr 2016, at 18:56, Kabir Khan wrote: > > >> On 25 Apr 2016, at 18:39, Kabir Khan wrote: >> >> Seems you have hit some of the tweaks needed that I mentioned :) >> >> I'll try to explain a bit below. Other things to look out for are that all the paths relating to data, configuration paths etc. have a different name in the HC to on a server (see the constants in ServerEnvironment vs HostControllerEnvironment). >>> On 25 Apr 2016, at 17:15, John Mazzitelli wrote: >>> >>> >>> >>> Trying to run a subsystem extension in host controller and it fails because some of its service dependencies are missing. Am I doing something wrong (it would not be a shocker if I was) or are these services really not deployed inside the Host Controller? >>> >>> >>> >>> I'm trying to get a subsystem extension to run inside of the Host Controller. This is a subsystem extension that runs fine in a standalone WildFly container - just trying to get it to run in a host controller (and maybe later in a domain controller as well). >>> >>> In domain/configuration/host.xml, I add my own in the - and that seems to run OK (well, not OK, but I know it is getting its initialization method invoked by the container). >>> >>> Because I need an outbound socket binding defined, I put add a socket-binding-groups in the host.xml (there are no socket-binding-groups in here by default): >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> That causes the container to abort with "WFLYCTL0198: Unexpected element '{urn:jboss:domain:4.0}socket-binding-groups' encountered" So I remove so that is a direct child of the top-level . The container starts OK when I do this. >> Correct. According to the xsd, only one socket-binding-group is allowed in host.xml >> >>> >>> But now the problems - my subsystem registers itself with a few service dependencies that do not exist at the time my service is initialized - specifically: >>> >>> jboss.naming.context.java (o.j.a.naming.deployment.ContextNames.JAVA_CONTEXT_SERVICE_NAME) >> This would be installed by the naming subsystem, which is not a host capable subsystem. So there cannot be any jndi on a HC at the moment. >>> >>> jboss.outbound-socket-binding (o.j.a.network.OutboundSocketBinding.OUTBOUND_SOCKET_BINDING_BASE_SERVICE_NAME) >> I see the same thing https://issues.jboss.org/browse/WFCORE-1505. >> >>> >>> jboss.server.environment (o.j.a.server.ServerEnvironmentService.SERVICE_NAME) >> This would only be available in a server. However, there is no corresponding service in a host controller to get the HostControllerEnvironment. Perhaps we should add one https://issues.jboss.org/browse/WFCORE-1506. >>> >>> jboss.as.server-controller (o.j.a.server.Services.JBOSS_SERVER_CONTROLLER) >> >> In a HC you need to depend on the DomainModelControllerService instead, it's name is in DomainModelControllerService.SERVICE_NAME. >> Both services contain a ModelController, you will need to choose the name to depend on according to the process type. >> >>> >>> When the host controller runs, I get this startup error: >>> >>> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ >>> ("host" => "master"), >>> ("subsystem" => "hawkular-wildfly-agent") >>> ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => [ >>> "\"org.hawkular.agent.\".hawkular-wildfly-agent is missing [jboss.outbound-socket-binding.hawkular, jboss.server.environment, jboss.as.server-controller]", >>> "jboss.naming.context.java.abc is missing [jboss.naming.context.java]" >>> ]} >>> >>> Sooo..... my question is - what happens if a subsystem needs these things? Do I need to do something special to make them available or are they really not deployed in the host controller? >>> >>> What I need these for is: >>> >>> jboss.naming.context.java - so I can store something in JNDI (actually, for my use case, I can probably skip this dependency - I don't think I will need it when running in the host controller) >> I don't think this is anything we can do at the moment, so hopefully you can do without. >>> >>> jboss.outbound-socket-binding - my subsystem needs to talk to an external server and this defines what host/port that server is on >> I'll look at adding this to WildFly. If this needs backporting to EAP 7.0.x, please let us know so we can put it into the process. >>> >>> jboss.server.environment - I need this to find out where the host controller's data directory is (e.g. domain/data). Is there another way to get this? >> I believe you should be able to get this by reading the following system property (taken from HostControllerEnvironment): >> >> >> /** >> * Constant that holds the name of the system property >> * for specifying {@link #getDomainDataDir()} the domain data directory}. >> * >> *

Defaults to DOMAIN_BASE_DIR/data. >> */ >> public static final String DOMAIN_DATA_DIR = "jboss.domain.data.dir"; >> >> >>> jboss.as.server-controller - I need this to obtain information from the management model such as "/:uuid" (which it looks like HCs do not have), the "/:launch-type" attribute and others. >> You will need to use the HC one as mentioned above >> >> >> I think that of the bugs/missing things you mention https://issues.jboss.org/browse/WFCORE-1505 (missing outbound socket binding service) is the one that looks like it blocks you the most, so I will see if that is fixable first. > https://github.com/wildfly/wildfly-core/pull/1520 WFCORE-1506 and WFCORE-1504 also have PRs now. >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From mazz at redhat.com Mon Apr 25 15:29:02 2016 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 25 Apr 2016 15:29:02 -0400 (EDT) Subject: [wildfly-dev] trying to run subsystem extension in host controller In-Reply-To: <6D912028-E5D1-47E6-B708-8D6917306F56@jboss.com> References: <1376054931.123913.1461600945091.JavaMail.zimbra@redhat.com> <6D912028-E5D1-47E6-B708-8D6917306F56@jboss.com> Message-ID: <1721983450.169233.1461612542096.JavaMail.zimbra@redhat.com> Thanks, Kabir! Some comments inline: ----- Original Message ----- [chomp] > > But now the problems - my subsystem registers itself with a few service > > dependencies that do not exist at the time my service is initialized - > > specifically: > > > > jboss.naming.context.java > > (o.j.a.naming.deployment.ContextNames.JAVA_CONTEXT_SERVICE_NAME) > > This would be installed by the naming subsystem, which is not a host capable > subsystem. So there cannot be any jndi on a HC at the moment. I'm pretty sure I won't need this as my later comment mentioned. So don't worry about this for now. [chomp] > > jboss.server.environment > > (o.j.a.server.ServerEnvironmentService.SERVICE_NAME) > This would only be available in a server. However, there is no corresponding > service in a host controller to get the HostControllerEnvironment. Perhaps > we should add one https://issues.jboss.org/browse/WFCORE-1506. > > > > jboss.as.server-controller (o.j.a.server.Services.JBOSS_SERVER_CONTROLLER) > > In a HC you need to depend on the DomainModelControllerService instead, it's > name is in DomainModelControllerService.SERVICE_NAME. > Both services contain a ModelController, you will need to choose the name to > depend on according to the process type. This brings up another question. How does my subsystem know what the process type is? Is there an API or other way to know if it is deployed in a Host Controller versus a Standalone server (and I suppose you'd need to know if its in a Domain Controller, too)? [chomp] > > jboss.outbound-socket-binding - my subsystem needs to talk to an external > > server and this defines what host/port that server is on > I'll look at adding this to WildFly. If this needs backporting to EAP 7.0.x, > please let us know so we can put it into the process. I will let you know about backporting. Not sure yet if we need it. From brian.stansberry at redhat.com Mon Apr 25 15:34:08 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 25 Apr 2016 14:34:08 -0500 Subject: [wildfly-dev] trying to run subsystem extension in host controller In-Reply-To: <1721983450.169233.1461612542096.JavaMail.zimbra@redhat.com> References: <1376054931.123913.1461600945091.JavaMail.zimbra@redhat.com> <6D912028-E5D1-47E6-B708-8D6917306F56@jboss.com> <1721983450.169233.1461612542096.JavaMail.zimbra@redhat.com> Message-ID: <571E7130.2000009@redhat.com> On 4/25/16 2:29 PM, John Mazzitelli wrote: > Thanks, Kabir! Some comments inline: > > ----- Original Message ----- > [chomp] >>> But now the problems - my subsystem registers itself with a few service >>> dependencies that do not exist at the time my service is initialized - >>> specifically: >>> >>> jboss.naming.context.java >>> (o.j.a.naming.deployment.ContextNames.JAVA_CONTEXT_SERVICE_NAME) >> >> This would be installed by the naming subsystem, which is not a host capable >> subsystem. So there cannot be any jndi on a HC at the moment. > > > I'm pretty sure I won't need this as my later comment mentioned. So don't worry about this for now. > > > [chomp] >>> jboss.server.environment >>> (o.j.a.server.ServerEnvironmentService.SERVICE_NAME) >> This would only be available in a server. However, there is no corresponding >> service in a host controller to get the HostControllerEnvironment. Perhaps >> we should add one https://issues.jboss.org/browse/WFCORE-1506. >>> >>> jboss.as.server-controller (o.j.a.server.Services.JBOSS_SERVER_CONTROLLER) >> >> In a HC you need to depend on the DomainModelControllerService instead, it's >> name is in DomainModelControllerService.SERVICE_NAME. >> Both services contain a ModelController, you will need to choose the name to >> depend on according to the process type. > > > This brings up another question. How does my subsystem know what the process type is? Is there an API or other way to know if it is deployed in a Host Controller versus a Standalone server When you Extension is registering your subsystem it can call ExtensionContext.getProcessType(). When you subsystem's OperationStepHandlers are executing they can call OperationContext.getProcessType(). > (and I suppose you'd need to know if its in a Domain Controller, too)? You hopefully don't need to know that. It's not exposed via any simple API like the above. > > > [chomp] >>> jboss.outbound-socket-binding - my subsystem needs to talk to an external >>> server and this defines what host/port that server is on >> I'll look at adding this to WildFly. If this needs backporting to EAP 7.0.x, >> please let us know so we can put it into the process. > > > I will let you know about backporting. Not sure yet if we need it. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Mon Apr 25 15:38:20 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 25 Apr 2016 14:38:20 -0500 Subject: [wildfly-dev] trying to run subsystem extension in host controller In-Reply-To: <219BD9A2-ACC5-4E4C-991C-2455A9A86061@jboss.com> References: <1376054931.123913.1461600945091.JavaMail.zimbra@redhat.com> <6D912028-E5D1-47E6-B708-8D6917306F56@jboss.com> <219BD9A2-ACC5-4E4C-991C-2455A9A86061@jboss.com> Message-ID: <571E722C.9070205@redhat.com> >>> On 25 Apr 2016, at 18:39, Kabir Khan wrote: >>> >>> Seems you have hit some of the tweaks needed that I mentioned :) >>> >>> I'll try to explain a bit below. Other things to look out for are that all the paths relating to data, configuration paths etc. have a different name in the HC to on a server (see the constants in ServerEnvironment vs HostControllerEnvironment). >>>> On 25 Apr 2016, at 17:15, John Mazzitelli wrote: >>>> >>>> >>>> >>>> jboss.as.server-controller (o.j.a.server.Services.JBOSS_SERVER_CONTROLLER) >>> >>> In a HC you need to depend on the DomainModelControllerService instead, it's name is in DomainModelControllerService.SERVICE_NAME. >>> Both services contain a ModelController, you will need to choose the name to depend on according to the process type. >>> I filed a JIRA[1] for getting rid of the need to use a different code path for this one depending on what the process type is. But I don't want to rush to make that change so it's better if you go ahead and use different code paths for now. [1] https://issues.jboss.org/browse/WFCORE-1507 -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From kabir.khan at jboss.com Mon Apr 25 15:45:05 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Mon, 25 Apr 2016 20:45:05 +0100 Subject: [wildfly-dev] trying to run subsystem extension in host controller In-Reply-To: <1721983450.169233.1461612542096.JavaMail.zimbra@redhat.com> References: <1376054931.123913.1461600945091.JavaMail.zimbra@redhat.com> <6D912028-E5D1-47E6-B708-8D6917306F56@jboss.com> <1721983450.169233.1461612542096.JavaMail.zimbra@redhat.com> Message-ID: <23A8F18F-FC16-423A-9BE2-67020CBB185B@jboss.com> > On 25 Apr 2016, at 20:29, John Mazzitelli wrote: > > Thanks, Kabir! Some comments inline: > > ----- Original Message ----- > [chomp] >>> But now the problems - my subsystem registers itself with a few service >>> dependencies that do not exist at the time my service is initialized - >>> specifically: >>> >>> jboss.naming.context.java >>> (o.j.a.naming.deployment.ContextNames.JAVA_CONTEXT_SERVICE_NAME) >> >> This would be installed by the naming subsystem, which is not a host capable >> subsystem. So there cannot be any jndi on a HC at the moment. > > > I'm pretty sure I won't need this as my later comment mentioned. So don't worry about this for now. > > > [chomp] >>> jboss.server.environment >>> (o.j.a.server.ServerEnvironmentService.SERVICE_NAME) >> This would only be available in a server. However, there is no corresponding >> service in a host controller to get the HostControllerEnvironment. Perhaps >> we should add one https://issues.jboss.org/browse/WFCORE-1506. >>> >>> jboss.as.server-controller (o.j.a.server.Services.JBOSS_SERVER_CONTROLLER) >> >> In a HC you need to depend on the DomainModelControllerService instead, it's >> name is in DomainModelControllerService.SERVICE_NAME. >> Both services contain a ModelController, you will need to choose the name to >> depend on according to the process type. > > > This brings up another question. How does my subsystem know what the process type is? Is there an API or other way to know if it is deployed in a Host Controller versus a Standalone server (and I suppose you'd need to know if its in a Domain Controller, too)? In the operation handlers you can do OperationContext.getProcessType().isServer(). Also at Extension registration time there is an ExtensionContext.getProcessType() which works the same > > > [chomp] >>> jboss.outbound-socket-binding - my subsystem needs to talk to an external >>> server and this defines what host/port that server is on >> I'll look at adding this to WildFly. If this needs backporting to EAP 7.0.x, >> please let us know so we can put it into the process. > > > I will let you know about backporting. Not sure yet if we need it. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From lthon at redhat.com Tue Apr 26 02:36:53 2016 From: lthon at redhat.com (Ladislav Thon) Date: Tue, 26 Apr 2016 08:36:53 +0200 Subject: [wildfly-dev] Pattern defined RBAC scoped roles In-Reply-To: <571E3EF2.2060703@redhat.com> References: <571A3EF9.7050002@redhat.com> <571B1855.9040401@redhat.com> <571E13B1.1010102@redhat.com> <571E29A9.8090003@redhat.com> <571E3EF2.2060703@redhat.com> Message-ID: <571F0C85.8070703@redhat.com> > 1) Cross-profile perms > > /profile=*/subsystem=logging Exactly, this is a syntax we already have. > 2) Granting perms for an address and its children/ > > /subsystem=logging/** > > Clean handling of 2) is a must. Based on your previous question, this could actually mean 3 different things: a) only the resource and not its children b) the resource and its children c) only the resource's children, not the resource itself I think /subsystem=logging could be used for a) or b). For c), I was briefly thinking about /subsystem=logging/*=*, but I thought that we surely don't support that, so I didn't bother trying and directly went to the 'children-only' attribute. I tried it now and indeed we don't support .../*=* :-) But if we had to support all of a), b) and c), a multi-valued attribute like children=yes|no|only (or recursive=yes|no|children-only, I didn't give it much thought) could work. LT From alexey.loubyansky at redhat.com Tue Apr 26 15:19:25 2016 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Tue, 26 Apr 2016 21:19:25 +0200 Subject: [wildfly-dev] syntax enhancement for cli boolean operation parameters Message-ID: <571FBF3D.2080307@redhat.com> Just a brief announcement of a syntax enhancement in the CLI for boolean parameters in operation requests. Just to advertise it and avoid confusion with the changes in the tab-completion. It's been quite some time ago since somebody (probably Kabir) gave me an idea of how we could enhance the syntax for boolean parameters set to true. I.e. instead of typing :read-resource(recursive=true) all the time :read-resource(recursive) should be enough. So, the presence of a boolean parameter name w/o a value would mean the parameter is implicitly set by the user to true. While I liked the idea, I never actually implemented it. So I mentioned it to Jeff (jfdenise) who is getting his hands on the CLI now and he went ahead and did it. So now :read-resource(recursive) is equivalent to :read-resource(recursive=true) Both syntaxes are allowed. False is still set explicitly, i.g. :read-resource(recursive=false) The absence of the parameter still means the parameter was not provided by the user. Tab-completion has also been enhanced to suggest the shorter form for true and still suggests the explicit form for false. We hope you'll like it. Thanks Jeff for actually implementing it! Alexey From kabir.khan at jboss.com Tue Apr 26 15:27:49 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Tue, 26 Apr 2016 20:27:49 +0100 Subject: [wildfly-dev] syntax enhancement for cli boolean operation parameters In-Reply-To: <571FBF3D.2080307@redhat.com> References: <571FBF3D.2080307@redhat.com> Message-ID: <73D861A4-91FA-47EA-AB62-36116DF3E026@jboss.com> > On 26 Apr 2016, at 20:19, Alexey Loubyansky wrote: > > Just a brief announcement of a syntax enhancement in the CLI for boolean > parameters in operation requests. Just to advertise it and avoid > confusion with the changes in the tab-completion. > > It's been quite some time ago since somebody (probably Kabir) gave me an > idea of how we could enhance the syntax for boolean parameters set to true. > I.e. instead of typing :read-resource(recursive=true) all the time > :read-resource(recursive) should be enough. > > So, the presence of a boolean parameter name w/o a value would mean the > parameter is implicitly set by the user to true. > > While I liked the idea, I never actually implemented it. So I mentioned > it to Jeff (jfdenise) who is getting his hands on the CLI now and he > went ahead and did it. > > So now > > :read-resource(recursive) is equivalent to :read-resource(recursive=true) > > Both syntaxes are allowed. > > False is still set explicitly, i.g. :read-resource(recursive=false) Could that be abbreviated as well? To for example :read-resource(!recursive) I don't know if the new reserved character would have a negative impact though > > The absence of the parameter still means the parameter was not provided > by the user. > > Tab-completion has also been enhanced to suggest the shorter form for > true and still suggests the explicit form for false. > > We hope you'll like it. Thanks Jeff for actually implementing it! > > Alexey > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From hbraun at redhat.com Wed Apr 27 00:25:00 2016 From: hbraun at redhat.com (Heiko Braun) Date: Wed, 27 Apr 2016 06:25:00 +0200 Subject: [wildfly-dev] syntax enhancement for cli boolean operation parameters In-Reply-To: <571FBF3D.2080307@redhat.com> References: <571FBF3D.2080307@redhat.com> Message-ID: A small useful enhancement when you use the CLI daily > Am 26.04.2016 um 21:19 schrieb Alexey Loubyansky : > > Just a brief announcement of a syntax enhancement in the CLI for boolean > parameters in operation requests. Just to advertise it and avoid > confusion with the changes in the tab-completion. > > It's been quite some time ago since somebody (probably Kabir) gave me an > idea of how we could enhance the syntax for boolean parameters set to true. > I.e. instead of typing :read-resource(recursive=true) all the time > :read-resource(recursive) should be enough. > > So, the presence of a boolean parameter name w/o a value would mean the > parameter is implicitly set by the user to true. > > While I liked the idea, I never actually implemented it. So I mentioned > it to Jeff (jfdenise) who is getting his hands on the CLI now and he > went ahead and did it. > > So now > > :read-resource(recursive) is equivalent to :read-resource(recursive=true) > > Both syntaxes are allowed. > > False is still set explicitly, i.g. :read-resource(recursive=false) > > The absence of the parameter still means the parameter was not provided > by the user. > > Tab-completion has also been enhanced to suggest the shorter form for > true and still suggests the explicit form for false. > > We hope you'll like it. Thanks Jeff for actually implementing it! > > Alexey > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jdenise at redhat.com Wed Apr 27 12:17:54 2016 From: jdenise at redhat.com (Jean-Francois Denise) Date: Wed, 27 Apr 2016 18:17:54 +0200 Subject: [wildfly-dev] syntax enhancement for cli boolean operation parameters In-Reply-To: <73D861A4-91FA-47EA-AB62-36116DF3E026@jboss.com> References: <571FBF3D.2080307@redhat.com> <73D861A4-91FA-47EA-AB62-36116DF3E026@jboss.com> Message-ID: <5720E632.9020504@redhat.com> Hi Kabir, I just logged https://issues.jboss.org/browse/WFCORE-1514 I have started to work on it. Thanks. JF On 26/04/16 21:27, Kabir Khan wrote: >> On 26 Apr 2016, at 20:19, Alexey Loubyansky wrote: >> >> Just a brief announcement of a syntax enhancement in the CLI for boolean >> parameters in operation requests. Just to advertise it and avoid >> confusion with the changes in the tab-completion. >> >> It's been quite some time ago since somebody (probably Kabir) gave me an >> idea of how we could enhance the syntax for boolean parameters set to true. >> I.e. instead of typing :read-resource(recursive=true) all the time >> :read-resource(recursive) should be enough. >> >> So, the presence of a boolean parameter name w/o a value would mean the >> parameter is implicitly set by the user to true. >> >> While I liked the idea, I never actually implemented it. So I mentioned >> it to Jeff (jfdenise) who is getting his hands on the CLI now and he >> went ahead and did it. >> >> So now >> >> :read-resource(recursive) is equivalent to :read-resource(recursive=true) >> >> Both syntaxes are allowed. >> >> False is still set explicitly, i.g. :read-resource(recursive=false) > Could that be abbreviated as well? To for example > :read-resource(!recursive) > > I don't know if the new reserved character would have a negative impact though > >> The absence of the parameter still means the parameter was not provided >> by the user. >> >> Tab-completion has also been enhanced to suggest the shorter form for >> true and still suggests the explicit form for false. >> >> We hope you'll like it. Thanks Jeff for actually implementing it! >> >> Alexey >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From mazz at redhat.com Wed Apr 27 17:09:03 2016 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 27 Apr 2016 17:09:03 -0400 (EDT) Subject: [wildfly-dev] best way to get extensions to apply model changes immediately at runtime? In-Reply-To: <843678650.1041002.1461790635158.JavaMail.zimbra@redhat.com> Message-ID: <1413674511.1057508.1461791343541.JavaMail.zimbra@redhat.com> I'm in the need to support runtime changes to my subsystem extension (for example, someone should be able to use the CLI to add a child resource or change a resource's attribute and have those changes take effect immediately - i.e. support Flag.RESTART_NONE rather than Flag.RESTART_RESOURCE_SERVICES). I'm assuming I need to do this in the AddStepHandler but I'm confused if I should override AbstractAddStepHandler.populateModel or AbstractAddStepHandler.performRuntime. Can someone fill me in on which one is recommended to be used? I'm not sure under which conditions each of those should be used and why. The other thing is, it seems this is only for adding child resources (or removing them; I assume it is analogous for Remove Step Handlers). How do you intercept the changing of an attribute value for an existing resource, particularly if my resource extends PersistentResourceDefinition? Thanks for any help, John Mazz From brian.stansberry at redhat.com Wed Apr 27 18:50:44 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 27 Apr 2016 17:50:44 -0500 Subject: [wildfly-dev] best way to get extensions to apply model changes immediately at runtime? In-Reply-To: <1413674511.1057508.1461791343541.JavaMail.zimbra@redhat.com> References: <1413674511.1057508.1461791343541.JavaMail.zimbra@redhat.com> Message-ID: <57214244.4020702@redhat.com> On 4/27/16 4:09 PM, John Mazzitelli wrote: > I'm in the need to support runtime changes to my subsystem extension (for example, someone should be able to use the CLI to add a child resource or change a resource's attribute and have those changes take effect immediately - i.e. support Flag.RESTART_NONE rather than Flag.RESTART_RESOURCE_SERVICES). > > I'm assuming I need to do this in the AddStepHandler You use an AbstractAddStepHandler subclass for adding a child resource. You use an AbstractWriteAttributeHandler subclass for changing an existing resource's attribute (i.e. the write-attribute operation.) >but I'm confused if I should override AbstractAddStepHandler.populateModel or AbstractAddStepHandler.performRuntime. > Flag.RESTART_NONE and Flag.RESTART_RESOURCE_SERVICES refer to how the operation affects runtime services, so what's relevant there is performRuntime. Or in the case of AbstractWriteAttributeHandler, applyUpdateToRuntime. You have an AttributeDefinition for each of your attributes. If you pass all of them to the AbstractAddStepHandler constructor you normally do not need to override populateModel as the default behavior is fine. > Can someone fill me in on which one is recommended to be used? I'm not sure under which conditions each of those should be used and why. > Operations execute in stages. There are five[1], but really only two are relevant to people not working on the kernel code. Stage.MODEL -- changes to the in-memory configuration model are made here. AbstractAddStepHandler.populateModel executes in this stage. It takes the parameters from the operation and sticks them in the in-memory configuration model. Stage.RUNTIME -- all in-memory configuration model changes have been made and whatever model integrity checks we do have been performed. Now it's time to make changes to the running container to reflect what's in the configuration model. For example, add or remove MSC services. AbstractAddStepHandler.performRuntime is called in this stage, as is AbstractWriteAttributeHandler.applyUpdateToRuntime. > The other thing is, it seems this is only for adding child resources (or removing them; I assume it is analogous for Remove Step Handlers). How do you intercept the changing of an attribute value for an existing resource, particularly if my resource extends PersistentResourceDefinition? > See above re AbstractWriteAttributeHandler. You'll need to write your own subclass which in applyUpdateToRuntime integrates with your runtime stuff and makes changes. For example looks up your service in MSC and calls a setter on the service's value object. In revertUpdateToRuntime, which is called in case of rollback you reverse the change. To register your custom handler you need to override PersistentResourceDefinition.registerAttributes so instead of calling the superclass (which registers ReloadRequiredWriteAttributeHandler for all attributes) instead you register your handler(s). (Tomaz, I think we need to make this write handler registration easier. Perhaps something like a PersistentResourceDefinition.getAttributeHandlers() method that returns a Map. And then registerAttributes uses the map instead of hardcoding ReloadRequiredWriteAttributeHandler. Default impl just fills the map values with ReloadRequiredWriteAttributeHandler.) [1] https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/OperationContext.java#L983 > Thanks for any help, > > John Mazz > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From tomaz.cerar at gmail.com Thu Apr 28 08:36:08 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 28 Apr 2016 14:36:08 +0200 Subject: [wildfly-dev] best way to get extensions to apply model changes immediately at runtime? In-Reply-To: <57214244.4020702@redhat.com> References: <1413674511.1057508.1461791343541.JavaMail.zimbra@redhat.com> <57214244.4020702@redhat.com> Message-ID: On Thu, Apr 28, 2016 at 12:50 AM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > (Tomaz, I think we need to make this write handler registration easier. > Perhaps something like a > PersistentResourceDefinition.getAttributeHandlers() method that returns > a Map. And then registerAttributes uses > the map instead of hardcoding ReloadRequiredWriteAttributeHandler. > Default impl just fills the map values with > ReloadRequiredWriteAttributeHandler.) > created https://issues.jboss.org/browse/WFCORE-1515 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160428/284b13fb/attachment.html From jmesnil at redhat.com Thu Apr 28 08:42:08 2016 From: jmesnil at redhat.com (Jeff Mesnil) Date: Thu, 28 Apr 2016 14:42:08 +0200 Subject: [wildfly-dev] best way to get extensions to apply model changes immediately at runtime? In-Reply-To: <57214244.4020702@redhat.com> References: <1413674511.1057508.1461791343541.JavaMail.zimbra@redhat.com> <57214244.4020702@redhat.com> Message-ID: <216A6266-BA9A-4A4E-9FB2-09F0EEE3234E@redhat.com> > To register your custom handler you need to override > PersistentResourceDefinition.registerAttributes so instead of calling > the superclass (which registers ReloadRequiredWriteAttributeHandler for > all attributes) instead you register your handler(s). > > (Tomaz, I think we need to make this write handler registration easier. > Perhaps something like a > PersistentResourceDefinition.getAttributeHandlers() method that returns > a Map. And then registerAttributes uses > the map instead of hardcoding ReloadRequiredWriteAttributeHandler. > Default impl just fills the map values with > ReloadRequiredWriteAttributeHandler.) Couldn?t we add a setWriteAttributeHandler(OSH) on the AttributeDefinition and default to ReloadRequiredWriteAttributeHandler if it?s not present? -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From brian.stansberry at redhat.com Thu Apr 28 08:53:31 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 28 Apr 2016 07:53:31 -0500 Subject: [wildfly-dev] best way to get extensions to apply model changes immediately at runtime? In-Reply-To: <216A6266-BA9A-4A4E-9FB2-09F0EEE3234E@redhat.com> References: <1413674511.1057508.1461791343541.JavaMail.zimbra@redhat.com> <57214244.4020702@redhat.com> <216A6266-BA9A-4A4E-9FB2-09F0EEE3234E@redhat.com> Message-ID: <572207CB.5030101@redhat.com> On 4/28/16 7:42 AM, Jeff Mesnil wrote: >> To register your custom handler you need to override >> PersistentResourceDefinition.registerAttributes so instead of calling >> the superclass (which registers ReloadRequiredWriteAttributeHandler for >> all attributes) instead you register your handler(s). >> >> (Tomaz, I think we need to make this write handler registration easier. >> Perhaps something like a >> PersistentResourceDefinition.getAttributeHandlers() method that returns >> a Map. And then registerAttributes uses >> the map instead of hardcoding ReloadRequiredWriteAttributeHandler. >> Default impl just fills the map values with >> ReloadRequiredWriteAttributeHandler.) > > Couldn?t we add a setWriteAttributeHandler(OSH) on the AttributeDefinition and default to ReloadRequiredWriteAttributeHandler if it?s not present? > Not without making AD mutable, which I don't want to do, just because. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jmesnil at redhat.com Thu Apr 28 08:54:41 2016 From: jmesnil at redhat.com (Jeff Mesnil) Date: Thu, 28 Apr 2016 14:54:41 +0200 Subject: [wildfly-dev] best way to get extensions to apply model changes immediately at runtime? In-Reply-To: <572207CB.5030101@redhat.com> References: <1413674511.1057508.1461791343541.JavaMail.zimbra@redhat.com> <57214244.4020702@redhat.com> <216A6266-BA9A-4A4E-9FB2-09F0EEE3234E@redhat.com> <572207CB.5030101@redhat.com> Message-ID: > On 28 Apr 2016, at 14:53, Brian Stansberry wrote: > > On 4/28/16 7:42 AM, Jeff Mesnil wrote: >>> To register your custom handler you need to override >>> PersistentResourceDefinition.registerAttributes so instead of calling >>> the superclass (which registers ReloadRequiredWriteAttributeHandler for >>> all attributes) instead you register your handler(s). >>> >>> (Tomaz, I think we need to make this write handler registration easier. >>> Perhaps something like a >>> PersistentResourceDefinition.getAttributeHandlers() method that returns >>> a Map. And then registerAttributes uses >>> the map instead of hardcoding ReloadRequiredWriteAttributeHandler. >>> Default impl just fills the map values with >>> ReloadRequiredWriteAttributeHandler.) >> >> Couldn?t we add a setWriteAttributeHandler(OSH) on the AttributeDefinition and default to ReloadRequiredWriteAttributeHandler if it?s not present? >> > > Not without making AD mutable, which I don't want to do, just because. I sent my mail too fast! :) I meant on the AttributeDefinitionBuilder. -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From brian.stansberry at redhat.com Thu Apr 28 09:06:55 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 28 Apr 2016 08:06:55 -0500 Subject: [wildfly-dev] best way to get extensions to apply model changes immediately at runtime? In-Reply-To: References: <1413674511.1057508.1461791343541.JavaMail.zimbra@redhat.com> <57214244.4020702@redhat.com> <216A6266-BA9A-4A4E-9FB2-09F0EEE3234E@redhat.com> <572207CB.5030101@redhat.com> Message-ID: <57220AEF.5050001@redhat.com> On 4/28/16 7:54 AM, Jeff Mesnil wrote: > >> On 28 Apr 2016, at 14:53, Brian Stansberry wrote: >> >> On 4/28/16 7:42 AM, Jeff Mesnil wrote: >>>> To register your custom handler you need to override >>>> PersistentResourceDefinition.registerAttributes so instead of calling >>>> the superclass (which registers ReloadRequiredWriteAttributeHandler for >>>> all attributes) instead you register your handler(s). >>>> >>>> (Tomaz, I think we need to make this write handler registration easier. >>>> Perhaps something like a >>>> PersistentResourceDefinition.getAttributeHandlers() method that returns >>>> a Map. And then registerAttributes uses >>>> the map instead of hardcoding ReloadRequiredWriteAttributeHandler. >>>> Default impl just fills the map values with >>>> ReloadRequiredWriteAttributeHandler.) >>> >>> Couldn?t we add a setWriteAttributeHandler(OSH) on the AttributeDefinition and default to ReloadRequiredWriteAttributeHandler if it?s not present? >>> >> >> Not without making AD mutable, which I don't want to do, just because. > > I sent my mail too fast! :) I meant on the AttributeDefinitionBuilder. > I was thinking along those lines as I responded, but I think you get a kind of chicken/egg situation, since the OSH needs the AD in its constructor. Hmm, but the OSH could accept builders instead of ADs and then call setWriteAttributeHandler(this). This would need some trickery in the builders, e.g. avoid building the same AD multiple times for use in the MRR, add handler and write-attribute handler. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From rory.odonnell at oracle.com Fri Apr 29 09:22:38 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 29 Apr 2016 14:22:38 +0100 Subject: [wildfly-dev] Early Access builds of JDK 9 b116 & JDK 9 with Project Jigsaw b115 (#4909) are available on java.net Message-ID: <5723601E.2090308@oracle.com> Hi Jason/Tomaz, Early Access b116 for JDK 9 is available on java.net, summary of changes are listed here . Early Access b115 (#4909) for JDK 9 with Project Jigsaw is available on java.net. Recent changes: * in b114 o Replace ?com.apple.eawt ?com.apple.eio With platform independent alternatives in java.awt * in b115 o As per JEP 260, all non-Critical types/members should be moved out of sun/reflect and placed into a non-exported package. Only critical APIs should remain in sun.reflect. We are very interested in hearing your experiences in testing any Early Access builds. Have you have begun testing against JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered showstopper issues that you would like to discuss? We would really like to hear your findings so far, either reply to me or via the mailing lists [1], [2]. Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/ [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/ -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160429/0fecf891/attachment.html