From rory.odonnell at oracle.com Mon Jul 2 05:24:47 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 2 Jul 2018 10:24:47 +0100 Subject: [wildfly-dev] JDK 11 is now in Rampdown Phase one Message-ID: <34319a69-d8cc-2c12-b21a-5f94ce8a689b@oracle.com> Hi Jason/Tomaz, *JDK 11 is now in Rampdown Phase one*** The overall feature set is frozen. No further JEPs will be targeted to this release.We?ve forked the main-line source repository, jdk/jdk, to the jdk/jdk11 stabilization repository. Any changes pushed to jdk/jdk or jdk/client are now bound for JDK 12. * For more details , see Mark Reinhold's email to jdk-dev mailing list [1] * The Rampdown Phase one process? [2]. *Note: -* Early-Access build archive format on Windows has changed to zip. Since our last email the following JEPs have been targeted to JDK 11 : * 181: Nest-Based Access Control * 315: Improve Aarch64 Intrinsics * 330: Launch Single-File Source-Code Programs * 331: Low-Overhead Heap Profiling * 332: Transport Layer Security (TLS) 1.3 * 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) * 335: *Deprecate the Nashorn JavaScript Engine* * 336: *Deprecate the Pack200 Tools and API* Other important changes since last email: Build 19: JDK-8205043 : G1 enables adaptive parallel reference processing by default Build 18: JDK-8196141 : Add GoDaddy root certificates JDK-8204243 : *remove Thread.destroy() and Thread.stop(Throwable)* JDK-8202088 : Japanese New Era Implementation Build 17: JDK-8189949 : Remove Baltimore Cybertrust Code Signing CA JDK-8191031 : Remove several Symantec Root CAs JDK-8072996 : Deprecate stream-based GSSContext methods Build 16: JDK-8191844 : Remove SECOM root Rgds, Rory [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001509.html [2] http://openjdk.java.net/projects/jdk/11/#Schedule -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180702/e99ecfcb/attachment.html From slaskawi at redhat.com Tue Jul 10 09:32:58 2018 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Tue, 10 Jul 2018 15:32:58 +0200 Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan Openshift Template In-Reply-To: References: Message-ID: Hey Tom! Could you please tell me what is the status of this? It seems one of the Keycloak users got hit by this problem: http://lists.jboss.org/pipermail/keycloak-dev/2018-July/010985.html Thanks, Sebastian On Thu, May 10, 2018 at 11:10 AM Tom Jenkinson wrote: > Sure - thanks! > > On 10 May 2018 at 02:56, Sebastian Laskawiec wrote: > >> I'm sorry for delay... I got sucked by the Summit prep activities. >> >> Yes, to all, what you said! Shall I create a JIRA for you? >> >> >> >> On Wed, May 9, 2018 at 9:39 AM Tom Jenkinson >> wrote: >> >>> Thanks Brian. Does it work for you Sebastian? >>> >>> On 8 May 2018 at 23:05, Brian Stansberry >>> wrote: >>> >>>> Ah, ok. I was thinking of scripting in the broad sense the various >>>> stuff that goes into creating images. >>>> >>>> In any case, I don't see any downside to having node-identifier="${ >>>> jboss.tx.node.id:1}" in the standard WF config files. >>>> >>>> >>>> >>>> On Tue, May 8, 2018 at 3:07 PM, Tom Jenkinson >>> > wrote: >>>> >>>>> I think they want to avoid changing the standalone.xml file and just >>>>> want to control it from their startup script. >>>>> >>>>> On 8 May 2018 at 18:45, Brian Stansberry >>>>> wrote: >>>>> >>>>>> I might have missed something along the way, but if they are going to >>>>>> do scripting wouldn't they just set the attribute to ${ >>>>>> jboss.node.name} and count on the fact that this is unique per pod? >>>>>> >>>>>> On Tue, May 8, 2018 at 3:28 AM, Tom Jenkinson < >>>>>> tom.jenkinson at redhat.com> wrote: >>>>>> >>>>>>> Thanks for confirming Brian. >>>>>>> >>>>>>> Perhaps we could set it to: >>>>>>> node-identifier="${jboss.tx.node.id:1}" >>>>>>> (a bit like >>>>>>> https://github.com/jboss-developer/jboss-eap-quickstarts/tree/7.1/jts >>>>>>> ) >>>>>>> >>>>>>> Sebastian could set -Djboss.tx.node.id during startup in a script? >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 7 May 2018 at 22:08, Brian Stansberry < >>>>>>> brian.stansberry at redhat.com> wrote: >>>>>>> >>>>>>>> If it's not already set, WildFly sets the system property >>>>>>>> jboss.node.name at the very beginning of server boot, so ${ >>>>>>>> jboss.node.name*:1*} would not resolve to 1. >>>>>>>> >>>>>>>> On Sun, May 6, 2018 at 6:10 PM, Sebastian Laskawiec < >>>>>>>> slaskawi at redhat.com> wrote: >>>>>>>> >>>>>>>>> Ok, so how about doing the same thing you suggested, but just more >>>>>>>>> explicitly - adding node-identifier="${jboss.node.name*:1*}". >>>>>>>>> This way the bare metal deployment should be happy (since the default is >>>>>>>>> still 1) and we wouldn't need to override it in Infinispan. >>>>>>>>> >>>>>>>>> On Tue, May 1, 2018 at 10:09 AM Tom Jenkinson < >>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>> >>>>>>>>>> I am not sure - the default should be "1" for the bare metal case >>>>>>>>>> so the warning is reliably triggered but the default can be the pod name >>>>>>>>>> for OpenShift templates that only allow a single instance of the >>>>>>>>>> application server - does that help? >>>>>>>>>> >>>>>>>>>> The file you looked to want to edit is shared by bare metal and >>>>>>>>>> other deployment environments so it would be confusing to set the default >>>>>>>>>> to jboss.node.name there IMO. >>>>>>>>>> >>>>>>>>>> On 1 May 2018 at 03:39, Sebastian Laskawiec >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Fair enough Tom. Thanks for explanation. >>>>>>>>>>> >>>>>>>>>>> One more request - would you guys be OK with me adding >>>>>>>>>>> a node-identifier="${jboss.node.name}" to the transaction >>>>>>>>>>> subsystem template [1]? This way we wouldn't need to copy it into >>>>>>>>>>> Infinispan (since we need to set it). >>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>> https://github.com/wildfly/wildfly/blob/master/transactions/src/main/resources/subsystem-templates/transactions.xml#L6 >>>>>>>>>>> >>>>>>>>>>> On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson < >>>>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec < >>>>>>>>>>>> slaskawi at redhat.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hey Tom, >>>>>>>>>>>>> >>>>>>>>>>>>> Comments inlined. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Sebastian >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson < >>>>>>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 16 April 2018 at 09:31, <> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Adding +WildFly Dev to the >>>>>>>>>>>>>>> loop >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for the explanation Rado. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> TL;DR: A while ago Sanne pointed out that we do not set >>>>>>>>>>>>>>> `node-identifier` >>>>>>>>>>>>>>> in transaction subsystem by default. The default value for >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> `node-identifier` attribute it `1`. Not setting this >>>>>>>>>>>>>>> attribute might cause >>>>>>>>>>>>>>> problems in transaction recovery. Perhaps we could follow >>>>>>>>>>>>>>> Rado's idea and >>>>>>>>>>>>>>> set it to node name by default? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Indeed - it would cause serious data integrity problems if a >>>>>>>>>>>>>> non-unique node-identifier is used. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Some more comments inlined. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Sebastian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar >>>>>>>>>>>>>> redhat.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > Hi Sebastian, >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>> > > Hey Rado, Paul, >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > I started looking into this issue and it turned out that >>>>>>>>>>>>>>> WF subsystem >>>>>>>>>>>>>>> > > template doesn't provide `node-identifier` attribute [1]. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > I assume you mean that the default WildFly server profiles >>>>>>>>>>>>>>> do not >>>>>>>>>>>>>>> >>>>>>>>>>>>>> > explicitly define the attribute. Right ? thus the value >>>>>>>>>>>>>>> defaults in >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> > the model to "1" >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/subsystem/TransactionSubsystemRootResourceDefinition.java#L97 >>>>>>>>>>>>>>> > which sole intention seems to be to log a warning on boot >>>>>>>>>>>>>>> if the value >>>>>>>>>>>>>>> > is unchanged. >>>>>>>>>>>>>>> > Why they decided on a constant that will be inherently not >>>>>>>>>>>>>>> unique as >>>>>>>>>>>>>>> > opposed to defaulting to the node name (which we already >>>>>>>>>>>>>>> require to be >>>>>>>>>>>>>>> > unique) as clustering node name or undertow instance-id >>>>>>>>>>>>>>> does, is >>>>>>>>>>>>>>> > unclear to me. >>>>>>>>>>>>>>> > Some context is on >>>>>>>>>>>>>>> https://issues.jboss.org/browse/WFLY-1119. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In OpenShift environment we could set it to `hostname`. This >>>>>>>>>>>>>>> is guaranteed >>>>>>>>>>>>>>> to be unique in whole OpenShift cluster. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We do this too in EAP images. >>>>>>>>>>>>>> To Rado's point, the default is "1" so we can print the >>>>>>>>>>>>>> warning to alert people they are misconfigured - it seems to be working :) >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This is the point. From my understanding, if we set it to node >>>>>>>>>>>>> name (instead of "1"), we could make it always work correctly. We could >>>>>>>>>>>>> even remove the code that emits the warning (since the node name needs to >>>>>>>>>>>>> be unique). >>>>>>>>>>>>> >>>>>>>>>>>>> To sum it up - if we decided to proceed this way, there would >>>>>>>>>>>>> be no requirement of setting the node-identifier at all. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> For OpenShift you are right there is no requirement for someone >>>>>>>>>>>> to change the node-identifier from the podname and so that is why EAP >>>>>>>>>>>> images do that. >>>>>>>>>>>> >>>>>>>>>>>> For bare-metal it is different as there can be two servers on >>>>>>>>>>>> the same machine so they were configured to use the hostname as they >>>>>>>>>>>> node-identifier then if they were also connected to the same resource >>>>>>>>>>>> managers or the same object store they would interfere with each other. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> > > I'm not sure if you guys are the right people to ask, >>>>>>>>>>>>>>> but is it safe to >>>>>>>>>>>>>>> > > leave it set to default? Or shall I override our >>>>>>>>>>>>>>> Infinispan templates and >>>>>>>>>>>>>>> > > add this parameter (as I mentioned before, in OpenShift >>>>>>>>>>>>>>> this I wanted to >>>>>>>>>>>>>>> > set >>>>>>>>>>>>>>> > > it as Pod name trimmed to the last 23 chars since this >>>>>>>>>>>>>>> is the limit). >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Putting a response to this in line - I am not certain who >>>>>>>>>>>>>> originally proposed this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> You must use a globally unique node-identifier. If you are >>>>>>>>>>>>>> certain the last 23 characters guarantee that it would be valid - if there >>>>>>>>>>>>>> is a chance they are not unique it is not valid to trim. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> If that's not an issue, again, we could use the same limit as >>>>>>>>>>>>> we have for node name. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> > It is not safe to leave it set to "1" as that results in >>>>>>>>>>>>>>> inconsistent >>>>>>>>>>>>>>> > processing of transaction recovery. >>>>>>>>>>>>>>> > IIUC we already set it to the node name for both EAP and >>>>>>>>>>>>>>> JDG >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> https://github.com/jboss-openshift/cct_module/blob/master/os-eap70-openshift/added/standalone-openshift.xml#L411 >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> https://github.com/jboss-openshift/cct_module/blob/master/os-jdg7-conffiles/added/clustered-openshift.xml#L282 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> > which in turn defaults to the pod name ? so which profiles >>>>>>>>>>>>>>> are we >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> > talking about here? >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Granted, we set it by default in CCT Modules. However in >>>>>>>>>>>>>>> Infinispan we just >>>>>>>>>>>>>>> grab provided transaction subsystem when rendering full >>>>>>>>>>>>>>> configuration from >>>>>>>>>>>>>>> featurepacks: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/infinispan/infinispan/blob/master/server/integration/feature-pack/src/main/resources/configuration/standalone/subsystems-cloud.xml#L19 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The default configuration XML doesn't contain the >>>>>>>>>>>>>>> `node-identifier` >>>>>>>>>>>>>>> attribute. I can add it manually in the cloud.xml but I >>>>>>>>>>>>>>> believe the right >>>>>>>>>>>>>>> approach is to modify the transaction subsystem. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > Rado >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > > Thanks, >>>>>>>>>>>>>>> > > Seb >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > [1] usually set to node-identifier="${jboss.node.name}" >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero >>>>>>>>>>>>>> infinispan.org> >>>>>>>>>>>>>>> > > wrote: >>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec >>>>>>>>>>>>>> at redhat.com> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>> > >> > Thanks for looking into it Sanne. Of course, we >>>>>>>>>>>>>>> should add it (it can >>>>>>>>>>>>>>> > be >>>>>>>>>>>>>>> > >> > set >>>>>>>>>>>>>>> > >> > to the same name as hostname since those are unique >>>>>>>>>>>>>>> in Kubernetes). >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 >>>>>>>>>>>>>>> for it. >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > Thanks again! >>>>>>>>>>>>>>> > >> > Seb >>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>> > >> Thanks Sebastian! >>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero >>>>>>>>>>>>>> at infinispan.org> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >> > wrote: >>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>> > >> >> Hi all, >>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>> > >> >> I've started to use the Infinispan Openshift >>>>>>>>>>>>>>> Template and was >>>>>>>>>>>>>>> > browsing >>>>>>>>>>>>>>> > >> >> through the errors and warnings this produces. >>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>> > >> >> In particular I noticed "WFLYTX0013: Node identifier >>>>>>>>>>>>>>> property is set >>>>>>>>>>>>>>> > >> >> to the default value. Please make sure it is >>>>>>>>>>>>>>> unique." being produced >>>>>>>>>>>>>>> > >> >> by the transaction system. >>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>> > >> >> The node id is usually not needed for developer's >>>>>>>>>>>>>>> convenience and >>>>>>>>>>>>>>> > >> >> assuming there's a single node in "dev mode", yet >>>>>>>>>>>>>>> clearly the >>>>>>>>>>>>>>> > >> >> Infinispan template is meant to work with multiple >>>>>>>>>>>>>>> nodes running so >>>>>>>>>>>>>>> > >> >> this warning seems concerning. >>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>> > >> >> I'm not sure what the impact is on the transaction >>>>>>>>>>>>>>> manager so I asked >>>>>>>>>>>>>>> > >> >> on the Narayana forums; Tom pointed me to some >>>>>>>>>>>>>>> thourough design >>>>>>>>>>>>>>> > >> >> documents and also suggested the EAP image does set >>>>>>>>>>>>>>> the node >>>>>>>>>>>>>>> > >> >> identifier: >>>>>>>>>>>>>>> > >> >> - https://developer.jboss.org/message/981702#981702 >>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>> > >> >> WDYT? we probably want the Infinispan template to >>>>>>>>>>>>>>> set this as well, >>>>>>>>>>>>>>> > or >>>>>>>>>>>>>>> > >> >> silence the warning? >>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>> > >> >> Thanks, >>>>>>>>>>>>>>> > >> >> Sanne >>>>>>>>>>>>>>> > >> >> _______________________________________________ >>>>>>>>>>>>>>> > >> >> infinispan-dev mailing list >>>>>>>>>>>>>>> >>>>>>>>>>>>>> > >> >> infinispan-dev at lists.jboss.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > _______________________________________________ >>>>>>>>>>>>>>> > >> > infinispan-dev mailing list >>>>>>>>>>>>>>> >>>>>>>>>>>>>> > >> > infinispan-dev at lists.jboss.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>>>>>>>>>>>> > >> _______________________________________________ >>>>>>>>>>>>>>> > >> infinispan-dev mailing list >>>>>>>>>>>>>>> > >> infinispan-dev at lists.jboss.org >>>>>>>>>>>>>>> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -------------- next part -------------- >>>>>>>>>>>>>>> An HTML attachment was scrubbed... >>>>>>>>>>>>>>> URL: >>>>>>>>>>>>>>> http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180416/65962cf1/attachment-0001.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> wildfly-dev mailing list >>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Brian Stansberry >>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>> Red Hat >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Brian Stansberry >>>>>> Manager, Senior Principal Software Engineer >>>>>> Red Hat >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Brian Stansberry >>>> Manager, Senior Principal Software Engineer >>>> Red Hat >>>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180710/d622fe38/attachment-0001.html From tom.jenkinson at redhat.com Tue Jul 10 10:40:01 2018 From: tom.jenkinson at redhat.com (Tom Jenkinson) Date: Tue, 10 Jul 2018 15:40:01 +0100 Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan Openshift Template In-Reply-To: References: Message-ID: Hi Sebastian, I am not sure if you raised an issue for this but I have just found one from Brad that was similar so I am using that one: https://issues.jboss.org/browse/WFLY-10541 Thanks, Tom On 10 July 2018 at 14:32, Sebastian Laskawiec wrote: > Hey Tom! > > Could you please tell me what is the status of this? It seems one of the > Keycloak users got hit by this problem: http://lists.jboss. > org/pipermail/keycloak-dev/2018-July/010985.html > > Thanks, > Sebastian > > On Thu, May 10, 2018 at 11:10 AM Tom Jenkinson > wrote: > >> Sure - thanks! >> >> On 10 May 2018 at 02:56, Sebastian Laskawiec wrote: >> >>> I'm sorry for delay... I got sucked by the Summit prep activities. >>> >>> Yes, to all, what you said! Shall I create a JIRA for you? >>> >>> >>> >>> On Wed, May 9, 2018 at 9:39 AM Tom Jenkinson >>> wrote: >>> >>>> Thanks Brian. Does it work for you Sebastian? >>>> >>>> On 8 May 2018 at 23:05, Brian Stansberry >>>> wrote: >>>> >>>>> Ah, ok. I was thinking of scripting in the broad sense the various >>>>> stuff that goes into creating images. >>>>> >>>>> In any case, I don't see any downside to having node-identifier="${ >>>>> jboss.tx.node.id:1}" in the standard WF config files. >>>>> >>>>> >>>>> >>>>> On Tue, May 8, 2018 at 3:07 PM, Tom Jenkinson < >>>>> tom.jenkinson at redhat.com> wrote: >>>>> >>>>>> I think they want to avoid changing the standalone.xml file and just >>>>>> want to control it from their startup script. >>>>>> >>>>>> On 8 May 2018 at 18:45, Brian Stansberry >>>>> > wrote: >>>>>> >>>>>>> I might have missed something along the way, but if they are going >>>>>>> to do scripting wouldn't they just set the attribute to ${ >>>>>>> jboss.node.name} and count on the fact that this is unique per pod? >>>>>>> >>>>>>> On Tue, May 8, 2018 at 3:28 AM, Tom Jenkinson < >>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>> >>>>>>>> Thanks for confirming Brian. >>>>>>>> >>>>>>>> Perhaps we could set it to: >>>>>>>> node-identifier="${jboss.tx.node.id:1}" >>>>>>>> (a bit like https://github.com/jboss-developer/jboss-eap- >>>>>>>> quickstarts/tree/7.1/jts) >>>>>>>> >>>>>>>> Sebastian could set -Djboss.tx.node.id during startup in a script? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 7 May 2018 at 22:08, Brian Stansberry < >>>>>>>> brian.stansberry at redhat.com> wrote: >>>>>>>> >>>>>>>>> If it's not already set, WildFly sets the system property >>>>>>>>> jboss.node.name at the very beginning of server boot, so ${ >>>>>>>>> jboss.node.name*:1*} would not resolve to 1. >>>>>>>>> >>>>>>>>> On Sun, May 6, 2018 at 6:10 PM, Sebastian Laskawiec < >>>>>>>>> slaskawi at redhat.com> wrote: >>>>>>>>> >>>>>>>>>> Ok, so how about doing the same thing you suggested, but just >>>>>>>>>> more explicitly - adding node-identifier="${jboss.node.name*:1*}". >>>>>>>>>> This way the bare metal deployment should be happy (since the default is >>>>>>>>>> still 1) and we wouldn't need to override it in Infinispan. >>>>>>>>>> >>>>>>>>>> On Tue, May 1, 2018 at 10:09 AM Tom Jenkinson < >>>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>>> >>>>>>>>>>> I am not sure - the default should be "1" for the bare metal >>>>>>>>>>> case so the warning is reliably triggered but the default can be the pod >>>>>>>>>>> name for OpenShift templates that only allow a single instance of the >>>>>>>>>>> application server - does that help? >>>>>>>>>>> >>>>>>>>>>> The file you looked to want to edit is shared by bare metal and >>>>>>>>>>> other deployment environments so it would be confusing to set the default >>>>>>>>>>> to jboss.node.name there IMO. >>>>>>>>>>> >>>>>>>>>>> On 1 May 2018 at 03:39, Sebastian Laskawiec >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> Fair enough Tom. Thanks for explanation. >>>>>>>>>>>> >>>>>>>>>>>> One more request - would you guys be OK with me adding >>>>>>>>>>>> a node-identifier="${jboss.node.name}" to the transaction >>>>>>>>>>>> subsystem template [1]? This way we wouldn't need to copy it into >>>>>>>>>>>> Infinispan (since we need to set it). >>>>>>>>>>>> >>>>>>>>>>>> [1] https://github.com/wildfly/wildfly/blob/master/ >>>>>>>>>>>> transactions/src/main/resources/subsystem-templates/ >>>>>>>>>>>> transactions.xml#L6 >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson < >>>>>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec < >>>>>>>>>>>>> slaskawi at redhat.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hey Tom, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Comments inlined. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Sebastian >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson < >>>>>>>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 16 April 2018 at 09:31, <> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Adding +WildFly Dev to >>>>>>>>>>>>>>>> the loop >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks for the explanation Rado. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> TL;DR: A while ago Sanne pointed out that we do not set >>>>>>>>>>>>>>>> `node-identifier` >>>>>>>>>>>>>>>> in transaction subsystem by default. The default value for >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> `node-identifier` attribute it `1`. Not setting this >>>>>>>>>>>>>>>> attribute might cause >>>>>>>>>>>>>>>> problems in transaction recovery. Perhaps we could follow >>>>>>>>>>>>>>>> Rado's idea and >>>>>>>>>>>>>>>> set it to node name by default? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Indeed - it would cause serious data integrity problems if a >>>>>>>>>>>>>>> non-unique node-identifier is used. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Some more comments inlined. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Sebastian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar >>>>>>>>>>>>>>> redhat.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > Hi Sebastian, >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec >>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>> > > Hey Rado, Paul, >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > I started looking into this issue and it turned out >>>>>>>>>>>>>>>> that WF subsystem >>>>>>>>>>>>>>>> > > template doesn't provide `node-identifier` attribute >>>>>>>>>>>>>>>> [1]. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > I assume you mean that the default WildFly server >>>>>>>>>>>>>>>> profiles do not >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > explicitly define the attribute. Right ? thus the value >>>>>>>>>>>>>>>> defaults in >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > the model to "1" >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > https://github.com/wildfly/wildfly/blob/master/ >>>>>>>>>>>>>>>> transactions/src/main/java/org/jboss/as/txn/subsystem/ >>>>>>>>>>>>>>>> TransactionSubsystemRootResourceDefinition.java#L97 >>>>>>>>>>>>>>>> > which sole intention seems to be to log a warning on boot >>>>>>>>>>>>>>>> if the value >>>>>>>>>>>>>>>> > is unchanged. >>>>>>>>>>>>>>>> > Why they decided on a constant that will be inherently >>>>>>>>>>>>>>>> not unique as >>>>>>>>>>>>>>>> > opposed to defaulting to the node name (which we already >>>>>>>>>>>>>>>> require to be >>>>>>>>>>>>>>>> > unique) as clustering node name or undertow instance-id >>>>>>>>>>>>>>>> does, is >>>>>>>>>>>>>>>> > unclear to me. >>>>>>>>>>>>>>>> > Some context is on https://issues.jboss.org/ >>>>>>>>>>>>>>>> browse/WFLY-1119. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In OpenShift environment we could set it to `hostname`. >>>>>>>>>>>>>>>> This is guaranteed >>>>>>>>>>>>>>>> to be unique in whole OpenShift cluster. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We do this too in EAP images. >>>>>>>>>>>>>>> To Rado's point, the default is "1" so we can print the >>>>>>>>>>>>>>> warning to alert people they are misconfigured - it seems to be working :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is the point. From my understanding, if we set it to >>>>>>>>>>>>>> node name (instead of "1"), we could make it always work correctly. We >>>>>>>>>>>>>> could even remove the code that emits the warning (since the node name >>>>>>>>>>>>>> needs to be unique). >>>>>>>>>>>>>> >>>>>>>>>>>>>> To sum it up - if we decided to proceed this way, there would >>>>>>>>>>>>>> be no requirement of setting the node-identifier at all. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> For OpenShift you are right there is no requirement for >>>>>>>>>>>>> someone to change the node-identifier from the podname and so that is why >>>>>>>>>>>>> EAP images do that. >>>>>>>>>>>>> >>>>>>>>>>>>> For bare-metal it is different as there can be two servers on >>>>>>>>>>>>> the same machine so they were configured to use the hostname as they >>>>>>>>>>>>> node-identifier then if they were also connected to the same resource >>>>>>>>>>>>> managers or the same object store they would interfere with each other. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > > I'm not sure if you guys are the right people to ask, >>>>>>>>>>>>>>>> but is it safe to >>>>>>>>>>>>>>>> > > leave it set to default? Or shall I override our >>>>>>>>>>>>>>>> Infinispan templates and >>>>>>>>>>>>>>>> > > add this parameter (as I mentioned before, in OpenShift >>>>>>>>>>>>>>>> this I wanted to >>>>>>>>>>>>>>>> > set >>>>>>>>>>>>>>>> > > it as Pod name trimmed to the last 23 chars since this >>>>>>>>>>>>>>>> is the limit). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Putting a response to this in line - I am not certain who >>>>>>>>>>>>>>> originally proposed this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You must use a globally unique node-identifier. If you are >>>>>>>>>>>>>>> certain the last 23 characters guarantee that it would be valid - if there >>>>>>>>>>>>>>> is a chance they are not unique it is not valid to trim. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> If that's not an issue, again, we could use the same limit as >>>>>>>>>>>>>> we have for node name. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > It is not safe to leave it set to "1" as that results in >>>>>>>>>>>>>>>> inconsistent >>>>>>>>>>>>>>>> > processing of transaction recovery. >>>>>>>>>>>>>>>> > IIUC we already set it to the node name for both EAP and >>>>>>>>>>>>>>>> JDG >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/ >>>>>>>>>>>>>>>> master/os-eap70-openshift/added/standalone-openshift. >>>>>>>>>>>>>>>> xml#L411 >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/ >>>>>>>>>>>>>>>> master/os-jdg7-conffiles/added/clustered-openshift.xml#L282 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > which in turn defaults to the pod name ? so which profiles >>>>>>>>>>>>>>>> are we >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > talking about here? >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Granted, we set it by default in CCT Modules. However in >>>>>>>>>>>>>>>> Infinispan we just >>>>>>>>>>>>>>>> grab provided transaction subsystem when rendering full >>>>>>>>>>>>>>>> configuration from >>>>>>>>>>>>>>>> featurepacks: >>>>>>>>>>>>>>>> https://github.com/infinispan/ >>>>>>>>>>>>>>>> infinispan/blob/master/server/integration/feature-pack/src/ >>>>>>>>>>>>>>>> main/resources/configuration/standalone/subsystems-cloud. >>>>>>>>>>>>>>>> xml#L19 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The default configuration XML doesn't contain the >>>>>>>>>>>>>>>> `node-identifier` >>>>>>>>>>>>>>>> attribute. I can add it manually in the cloud.xml but I >>>>>>>>>>>>>>>> believe the right >>>>>>>>>>>>>>>> approach is to modify the transaction subsystem. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > Rado >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > > Thanks, >>>>>>>>>>>>>>>> > > Seb >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > [1] usually set to node-identifier="${jboss.node.name}" >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero >>>>>>>>>>>>>>> at infinispan.org> >>>>>>>>>>>>>>>> > > wrote: >>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>> > >> > Thanks for looking into it Sanne. Of course, we >>>>>>>>>>>>>>>> should add it (it can >>>>>>>>>>>>>>>> > be >>>>>>>>>>>>>>>> > >> > set >>>>>>>>>>>>>>>> > >> > to the same name as hostname since those are unique >>>>>>>>>>>>>>>> in Kubernetes). >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 >>>>>>>>>>>>>>>> for it. >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> > >> > Thanks again! >>>>>>>>>>>>>>>> > >> > Seb >>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>> > >> Thanks Sebastian! >>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero >>>>>>>>>>>>>>> at infinispan.org> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >> > wrote: >>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>> > >> >> Hi all, >>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>> > >> >> I've started to use the Infinispan Openshift >>>>>>>>>>>>>>>> Template and was >>>>>>>>>>>>>>>> > browsing >>>>>>>>>>>>>>>> > >> >> through the errors and warnings this produces. >>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>> > >> >> In particular I noticed "WFLYTX0013: Node >>>>>>>>>>>>>>>> identifier property is set >>>>>>>>>>>>>>>> > >> >> to the default value. Please make sure it is >>>>>>>>>>>>>>>> unique." being produced >>>>>>>>>>>>>>>> > >> >> by the transaction system. >>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>> > >> >> The node id is usually not needed for developer's >>>>>>>>>>>>>>>> convenience and >>>>>>>>>>>>>>>> > >> >> assuming there's a single node in "dev mode", yet >>>>>>>>>>>>>>>> clearly the >>>>>>>>>>>>>>>> > >> >> Infinispan template is meant to work with multiple >>>>>>>>>>>>>>>> nodes running so >>>>>>>>>>>>>>>> > >> >> this warning seems concerning. >>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>> > >> >> I'm not sure what the impact is on the transaction >>>>>>>>>>>>>>>> manager so I asked >>>>>>>>>>>>>>>> > >> >> on the Narayana forums; Tom pointed me to some >>>>>>>>>>>>>>>> thourough design >>>>>>>>>>>>>>>> > >> >> documents and also suggested the EAP image does set >>>>>>>>>>>>>>>> the node >>>>>>>>>>>>>>>> > >> >> identifier: >>>>>>>>>>>>>>>> > >> >> - https://developer.jboss.org/ >>>>>>>>>>>>>>>> message/981702#981702 >>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>> > >> >> WDYT? we probably want the Infinispan template to >>>>>>>>>>>>>>>> set this as well, >>>>>>>>>>>>>>>> > or >>>>>>>>>>>>>>>> > >> >> silence the warning? >>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>> > >> >> Thanks, >>>>>>>>>>>>>>>> > >> >> Sanne >>>>>>>>>>>>>>>> > >> >> _______________________________________________ >>>>>>>>>>>>>>>> > >> >> infinispan-dev mailing list >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >> >> infinispan-dev at lists.jboss.org >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >> >> https://lists.jboss.org/ >>>>>>>>>>>>>>>> mailman/listinfo/infinispan-dev >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> > >> > _______________________________________________ >>>>>>>>>>>>>>>> > >> > infinispan-dev mailing list >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >> > infinispan-dev at lists.jboss.org >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >> > https://lists.jboss.org/mailman/listinfo/infinispan- >>>>>>>>>>>>>>>> dev >>>>>>>>>>>>>>>> > >> _______________________________________________ >>>>>>>>>>>>>>>> > >> infinispan-dev mailing list >>>>>>>>>>>>>>>> > >> infinispan-dev at lists.jboss.org >>>>>>>>>>>>>>>> > >> https://lists.jboss.org/mailman/listinfo/infinispan- >>>>>>>>>>>>>>>> dev >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> -------------- next part -------------- >>>>>>>>>>>>>>>> An HTML attachment was scrubbed... >>>>>>>>>>>>>>>> URL: http://lists.jboss.org/pipermail/wildfly-dev/ >>>>>>>>>>>>>>>> attachments/20180416/65962cf1/attachment-0001.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> wildfly-dev mailing list >>>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Brian Stansberry >>>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>>> Red Hat >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Brian Stansberry >>>>>>> Manager, Senior Principal Software Engineer >>>>>>> Red Hat >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Manager, Senior Principal Software Engineer >>>>> Red Hat >>>>> >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180710/b09ef36d/attachment-0001.html From tom.jenkinson at redhat.com Tue Jul 10 11:56:31 2018 From: tom.jenkinson at redhat.com (Tom Jenkinson) Date: Tue, 10 Jul 2018 16:56:31 +0100 Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan Openshift Template In-Reply-To: References: Message-ID: I raised a PR for this now. On 10 July 2018 at 15:40, Tom Jenkinson wrote: > Hi Sebastian, > > I am not sure if you raised an issue for this but I have just found one > from Brad that was similar so I am using that one: > https://issues.jboss.org/browse/WFLY-10541 > > Thanks, > Tom > > On 10 July 2018 at 14:32, Sebastian Laskawiec wrote: > >> Hey Tom! >> >> Could you please tell me what is the status of this? It seems one of the >> Keycloak users got hit by this problem: http://lists.jboss.or >> g/pipermail/keycloak-dev/2018-July/010985.html >> >> Thanks, >> Sebastian >> >> On Thu, May 10, 2018 at 11:10 AM Tom Jenkinson >> wrote: >> >>> Sure - thanks! >>> >>> On 10 May 2018 at 02:56, Sebastian Laskawiec >>> wrote: >>> >>>> I'm sorry for delay... I got sucked by the Summit prep activities. >>>> >>>> Yes, to all, what you said! Shall I create a JIRA for you? >>>> >>>> >>>> >>>> On Wed, May 9, 2018 at 9:39 AM Tom Jenkinson >>>> wrote: >>>> >>>>> Thanks Brian. Does it work for you Sebastian? >>>>> >>>>> On 8 May 2018 at 23:05, Brian Stansberry >>>>> wrote: >>>>> >>>>>> Ah, ok. I was thinking of scripting in the broad sense the various >>>>>> stuff that goes into creating images. >>>>>> >>>>>> In any case, I don't see any downside to having node-identifier="${ >>>>>> jboss.tx.node.id:1}" in the standard WF config files. >>>>>> >>>>>> >>>>>> >>>>>> On Tue, May 8, 2018 at 3:07 PM, Tom Jenkinson < >>>>>> tom.jenkinson at redhat.com> wrote: >>>>>> >>>>>>> I think they want to avoid changing the standalone.xml file and just >>>>>>> want to control it from their startup script. >>>>>>> >>>>>>> On 8 May 2018 at 18:45, Brian Stansberry < >>>>>>> brian.stansberry at redhat.com> wrote: >>>>>>> >>>>>>>> I might have missed something along the way, but if they are going >>>>>>>> to do scripting wouldn't they just set the attribute to ${ >>>>>>>> jboss.node.name} and count on the fact that this is unique per pod? >>>>>>>> >>>>>>>> On Tue, May 8, 2018 at 3:28 AM, Tom Jenkinson < >>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>> >>>>>>>>> Thanks for confirming Brian. >>>>>>>>> >>>>>>>>> Perhaps we could set it to: >>>>>>>>> node-identifier="${jboss.tx.node.id:1}" >>>>>>>>> (a bit like https://github.com/jboss- >>>>>>>>> developer/jboss-eap-quickstarts/tree/7.1/jts) >>>>>>>>> >>>>>>>>> Sebastian could set -Djboss.tx.node.id during startup in a script? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7 May 2018 at 22:08, Brian Stansberry < >>>>>>>>> brian.stansberry at redhat.com> wrote: >>>>>>>>> >>>>>>>>>> If it's not already set, WildFly sets the system property >>>>>>>>>> jboss.node.name at the very beginning of server boot, so ${ >>>>>>>>>> jboss.node.name*:1*} would not resolve to 1. >>>>>>>>>> >>>>>>>>>> On Sun, May 6, 2018 at 6:10 PM, Sebastian Laskawiec < >>>>>>>>>> slaskawi at redhat.com> wrote: >>>>>>>>>> >>>>>>>>>>> Ok, so how about doing the same thing you suggested, but just >>>>>>>>>>> more explicitly - adding node-identifier="${jboss.node.name*:1*}". >>>>>>>>>>> This way the bare metal deployment should be happy (since the default is >>>>>>>>>>> still 1) and we wouldn't need to override it in Infinispan. >>>>>>>>>>> >>>>>>>>>>> On Tue, May 1, 2018 at 10:09 AM Tom Jenkinson < >>>>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> I am not sure - the default should be "1" for the bare metal >>>>>>>>>>>> case so the warning is reliably triggered but the default can be the pod >>>>>>>>>>>> name for OpenShift templates that only allow a single instance of the >>>>>>>>>>>> application server - does that help? >>>>>>>>>>>> >>>>>>>>>>>> The file you looked to want to edit is shared by bare metal and >>>>>>>>>>>> other deployment environments so it would be confusing to set the default >>>>>>>>>>>> to jboss.node.name there IMO. >>>>>>>>>>>> >>>>>>>>>>>> On 1 May 2018 at 03:39, Sebastian Laskawiec < >>>>>>>>>>>> slaskawi at redhat.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Fair enough Tom. Thanks for explanation. >>>>>>>>>>>>> >>>>>>>>>>>>> One more request - would you guys be OK with me adding >>>>>>>>>>>>> a node-identifier="${jboss.node.name}" to the transaction >>>>>>>>>>>>> subsystem template [1]? This way we wouldn't need to copy it into >>>>>>>>>>>>> Infinispan (since we need to set it). >>>>>>>>>>>>> >>>>>>>>>>>>> [1] https://github.com/wildfly/wildfly/blob/master/transacti >>>>>>>>>>>>> ons/src/main/resources/subsystem-templates/transactions.xml#L6 >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson < >>>>>>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec < >>>>>>>>>>>>>> slaskawi at redhat.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hey Tom, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Comments inlined. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Sebastian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson < >>>>>>>>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 16 April 2018 at 09:31, <> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Adding +WildFly Dev to >>>>>>>>>>>>>>>>> the loop >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks for the explanation Rado. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> TL;DR: A while ago Sanne pointed out that we do not set >>>>>>>>>>>>>>>>> `node-identifier` >>>>>>>>>>>>>>>>> in transaction subsystem by default. The default value for >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> `node-identifier` attribute it `1`. Not setting this >>>>>>>>>>>>>>>>> attribute might cause >>>>>>>>>>>>>>>>> problems in transaction recovery. Perhaps we could follow >>>>>>>>>>>>>>>>> Rado's idea and >>>>>>>>>>>>>>>>> set it to node name by default? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Indeed - it would cause serious data integrity problems if >>>>>>>>>>>>>>>> a non-unique node-identifier is used. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Some more comments inlined. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Sebastian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar >>>>>>>>>>>>>>>> redhat.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > Hi Sebastian, >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec >>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>> > > Hey Rado, Paul, >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > I started looking into this issue and it turned out >>>>>>>>>>>>>>>>> that WF subsystem >>>>>>>>>>>>>>>>> > > template doesn't provide `node-identifier` attribute >>>>>>>>>>>>>>>>> [1]. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > I assume you mean that the default WildFly server >>>>>>>>>>>>>>>>> profiles do not >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > explicitly define the attribute. Right ? thus the value >>>>>>>>>>>>>>>>> defaults in >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > the model to "1" >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > https://github.com/wildfly/wil >>>>>>>>>>>>>>>>> dfly/blob/master/transactions/src/main/java/org/jboss/as/ >>>>>>>>>>>>>>>>> txn/subsystem/TransactionSubsystemRootResourceDefinition. >>>>>>>>>>>>>>>>> java#L97 >>>>>>>>>>>>>>>>> > which sole intention seems to be to log a warning on >>>>>>>>>>>>>>>>> boot if the value >>>>>>>>>>>>>>>>> > is unchanged. >>>>>>>>>>>>>>>>> > Why they decided on a constant that will be inherently >>>>>>>>>>>>>>>>> not unique as >>>>>>>>>>>>>>>>> > opposed to defaulting to the node name (which we already >>>>>>>>>>>>>>>>> require to be >>>>>>>>>>>>>>>>> > unique) as clustering node name or undertow instance-id >>>>>>>>>>>>>>>>> does, is >>>>>>>>>>>>>>>>> > unclear to me. >>>>>>>>>>>>>>>>> > Some context is on https://issues.jboss.org/brows >>>>>>>>>>>>>>>>> e/WFLY-1119. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In OpenShift environment we could set it to `hostname`. >>>>>>>>>>>>>>>>> This is guaranteed >>>>>>>>>>>>>>>>> to be unique in whole OpenShift cluster. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We do this too in EAP images. >>>>>>>>>>>>>>>> To Rado's point, the default is "1" so we can print the >>>>>>>>>>>>>>>> warning to alert people they are misconfigured - it seems to be working :) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is the point. From my understanding, if we set it to >>>>>>>>>>>>>>> node name (instead of "1"), we could make it always work correctly. We >>>>>>>>>>>>>>> could even remove the code that emits the warning (since the node name >>>>>>>>>>>>>>> needs to be unique). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> To sum it up - if we decided to proceed this way, there >>>>>>>>>>>>>>> would be no requirement of setting the node-identifier at all. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> For OpenShift you are right there is no requirement for >>>>>>>>>>>>>> someone to change the node-identifier from the podname and so that is why >>>>>>>>>>>>>> EAP images do that. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For bare-metal it is different as there can be two servers on >>>>>>>>>>>>>> the same machine so they were configured to use the hostname as they >>>>>>>>>>>>>> node-identifier then if they were also connected to the same resource >>>>>>>>>>>>>> managers or the same object store they would interfere with each other. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > > I'm not sure if you guys are the right people to ask, >>>>>>>>>>>>>>>>> but is it safe to >>>>>>>>>>>>>>>>> > > leave it set to default? Or shall I override our >>>>>>>>>>>>>>>>> Infinispan templates and >>>>>>>>>>>>>>>>> > > add this parameter (as I mentioned before, in >>>>>>>>>>>>>>>>> OpenShift this I wanted to >>>>>>>>>>>>>>>>> > set >>>>>>>>>>>>>>>>> > > it as Pod name trimmed to the last 23 chars since this >>>>>>>>>>>>>>>>> is the limit). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Putting a response to this in line - I am not certain who >>>>>>>>>>>>>>>> originally proposed this. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You must use a globally unique node-identifier. If you are >>>>>>>>>>>>>>>> certain the last 23 characters guarantee that it would be valid - if there >>>>>>>>>>>>>>>> is a chance they are not unique it is not valid to trim. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If that's not an issue, again, we could use the same limit >>>>>>>>>>>>>>> as we have for node name. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > It is not safe to leave it set to "1" as that results in >>>>>>>>>>>>>>>>> inconsistent >>>>>>>>>>>>>>>>> > processing of transaction recovery. >>>>>>>>>>>>>>>>> > IIUC we already set it to the node name for both EAP and >>>>>>>>>>>>>>>>> JDG >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > https://github.com/jboss-opens >>>>>>>>>>>>>>>>> hift/cct_module/blob/master/os-eap70-openshift/added/ >>>>>>>>>>>>>>>>> standalone-openshift.xml#L411 >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > https://github.com/jboss-opens >>>>>>>>>>>>>>>>> hift/cct_module/blob/master/os-jdg7-conffiles/added/ >>>>>>>>>>>>>>>>> clustered-openshift.xml#L282 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > which in turn defaults to the pod name ? so which >>>>>>>>>>>>>>>>> profiles are we >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > talking about here? >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Granted, we set it by default in CCT Modules. However in >>>>>>>>>>>>>>>>> Infinispan we just >>>>>>>>>>>>>>>>> grab provided transaction subsystem when rendering full >>>>>>>>>>>>>>>>> configuration from >>>>>>>>>>>>>>>>> featurepacks: >>>>>>>>>>>>>>>>> https://github.com/infinispan/ >>>>>>>>>>>>>>>>> infinispan/blob/master/server/ >>>>>>>>>>>>>>>>> integration/feature-pack/src/m >>>>>>>>>>>>>>>>> ain/resources/configuration/st >>>>>>>>>>>>>>>>> andalone/subsystems-cloud.xml#L19 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The default configuration XML doesn't contain the >>>>>>>>>>>>>>>>> `node-identifier` >>>>>>>>>>>>>>>>> attribute. I can add it manually in the cloud.xml but I >>>>>>>>>>>>>>>>> believe the right >>>>>>>>>>>>>>>>> approach is to modify the transaction subsystem. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > Rado >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > > Thanks, >>>>>>>>>>>>>>>>> > > Seb >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > [1] usually set to node-identifier="${jboss.node.name >>>>>>>>>>>>>>>>> }" >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero >>>>>>>>>>>>>>>> at infinispan.org> >>>>>>>>>>>>>>>>> > > wrote: >>>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>> > >> > Thanks for looking into it Sanne. Of course, we >>>>>>>>>>>>>>>>> should add it (it can >>>>>>>>>>>>>>>>> > be >>>>>>>>>>>>>>>>> > >> > set >>>>>>>>>>>>>>>>> > >> > to the same name as hostname since those are unique >>>>>>>>>>>>>>>>> in Kubernetes). >>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 >>>>>>>>>>>>>>>>> for it. >>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>> > >> > Thanks again! >>>>>>>>>>>>>>>>> > >> > Seb >>>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>>> > >> Thanks Sebastian! >>>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >> > wrote: >>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>> > >> >> Hi all, >>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>> > >> >> I've started to use the Infinispan Openshift >>>>>>>>>>>>>>>>> Template and was >>>>>>>>>>>>>>>>> > browsing >>>>>>>>>>>>>>>>> > >> >> through the errors and warnings this produces. >>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>> > >> >> In particular I noticed "WFLYTX0013: Node >>>>>>>>>>>>>>>>> identifier property is set >>>>>>>>>>>>>>>>> > >> >> to the default value. Please make sure it is >>>>>>>>>>>>>>>>> unique." being produced >>>>>>>>>>>>>>>>> > >> >> by the transaction system. >>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>> > >> >> The node id is usually not needed for developer's >>>>>>>>>>>>>>>>> convenience and >>>>>>>>>>>>>>>>> > >> >> assuming there's a single node in "dev mode", yet >>>>>>>>>>>>>>>>> clearly the >>>>>>>>>>>>>>>>> > >> >> Infinispan template is meant to work with multiple >>>>>>>>>>>>>>>>> nodes running so >>>>>>>>>>>>>>>>> > >> >> this warning seems concerning. >>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>> > >> >> I'm not sure what the impact is on the transaction >>>>>>>>>>>>>>>>> manager so I asked >>>>>>>>>>>>>>>>> > >> >> on the Narayana forums; Tom pointed me to some >>>>>>>>>>>>>>>>> thourough design >>>>>>>>>>>>>>>>> > >> >> documents and also suggested the EAP image does >>>>>>>>>>>>>>>>> set the node >>>>>>>>>>>>>>>>> > >> >> identifier: >>>>>>>>>>>>>>>>> > >> >> - https://developer.jboss.org/me >>>>>>>>>>>>>>>>> ssage/981702#981702 >>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>> > >> >> WDYT? we probably want the Infinispan template to >>>>>>>>>>>>>>>>> set this as well, >>>>>>>>>>>>>>>>> > or >>>>>>>>>>>>>>>>> > >> >> silence the warning? >>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>> > >> >> Thanks, >>>>>>>>>>>>>>>>> > >> >> Sanne >>>>>>>>>>>>>>>>> > >> >> _______________________________________________ >>>>>>>>>>>>>>>>> > >> >> infinispan-dev mailing list >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >> >> infinispan-dev at lists.jboss.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >> >> https://lists.jboss.org/mailma >>>>>>>>>>>>>>>>> n/listinfo/infinispan-dev >>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>> > >> > _______________________________________________ >>>>>>>>>>>>>>>>> > >> > infinispan-dev mailing list >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >> > infinispan-dev at lists.jboss.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >> > https://lists.jboss.org/mailma >>>>>>>>>>>>>>>>> n/listinfo/infinispan-dev >>>>>>>>>>>>>>>>> > >> _______________________________________________ >>>>>>>>>>>>>>>>> > >> infinispan-dev mailing list >>>>>>>>>>>>>>>>> > >> infinispan-dev at lists.jboss.org >>>>>>>>>>>>>>>>> > >> https://lists.jboss.org/mailma >>>>>>>>>>>>>>>>> n/listinfo/infinispan-dev >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -------------- next part -------------- >>>>>>>>>>>>>>>>> An HTML attachment was scrubbed... >>>>>>>>>>>>>>>>> URL: http://lists.jboss.org/piperma >>>>>>>>>>>>>>>>> il/wildfly-dev/attachments/20180416/65962cf1/attachment- >>>>>>>>>>>>>>>>> 0001.html >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> wildfly-dev mailing list >>>>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Brian Stansberry >>>>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>>>> Red Hat >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Brian Stansberry >>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>> Red Hat >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Brian Stansberry >>>>>> Manager, Senior Principal Software Engineer >>>>>> Red Hat >>>>>> >>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180710/d0791cc7/attachment-0001.html From sebastian.laskawiec at gmail.com Tue Jul 10 14:47:36 2018 From: sebastian.laskawiec at gmail.com (=?UTF-8?Q?Sebastian_=C5=81askawiec?=) Date: Tue, 10 Jul 2018 20:47:36 +0200 Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan Openshift Template In-Reply-To: References: Message-ID: Good stuff. Thank you Tom! On Tue, 10 Jul 2018 at 18:11 Tom Jenkinson wrote: > I raised a PR for this now. > > On 10 July 2018 at 15:40, Tom Jenkinson wrote: > >> Hi Sebastian, >> >> I am not sure if you raised an issue for this but I have just found one >> from Brad that was similar so I am using that one: >> https://issues.jboss.org/browse/WFLY-10541 >> >> Thanks, >> Tom >> >> On 10 July 2018 at 14:32, Sebastian Laskawiec >> wrote: >> >>> Hey Tom! >>> >>> Could you please tell me what is the status of this? It seems one of the >>> Keycloak users got hit by this problem: >>> http://lists.jboss.org/pipermail/keycloak-dev/2018-July/010985.html >>> >>> Thanks, >>> Sebastian >>> >>> On Thu, May 10, 2018 at 11:10 AM Tom Jenkinson >>> wrote: >>> >>>> Sure - thanks! >>>> >>>> On 10 May 2018 at 02:56, Sebastian Laskawiec >>>> wrote: >>>> >>>>> I'm sorry for delay... I got sucked by the Summit prep activities. >>>>> >>>>> Yes, to all, what you said! Shall I create a JIRA for you? >>>>> >>>>> >>>>> >>>>> On Wed, May 9, 2018 at 9:39 AM Tom Jenkinson >>>>> wrote: >>>>> >>>>>> Thanks Brian. Does it work for you Sebastian? >>>>>> >>>>>> On 8 May 2018 at 23:05, Brian Stansberry >>>>> > wrote: >>>>>> >>>>>>> Ah, ok. I was thinking of scripting in the broad sense the various >>>>>>> stuff that goes into creating images. >>>>>>> >>>>>>> In any case, I don't see any downside to having node-identifier="${ >>>>>>> jboss.tx.node.id:1}" in the standard WF config files. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, May 8, 2018 at 3:07 PM, Tom Jenkinson < >>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>> >>>>>>>> I think they want to avoid changing the standalone.xml file and >>>>>>>> just want to control it from their startup script. >>>>>>>> >>>>>>>> On 8 May 2018 at 18:45, Brian Stansberry < >>>>>>>> brian.stansberry at redhat.com> wrote: >>>>>>>> >>>>>>>>> I might have missed something along the way, but if they are going >>>>>>>>> to do scripting wouldn't they just set the attribute to ${ >>>>>>>>> jboss.node.name} and count on the fact that this is unique per >>>>>>>>> pod? >>>>>>>>> >>>>>>>>> On Tue, May 8, 2018 at 3:28 AM, Tom Jenkinson < >>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>> >>>>>>>>>> Thanks for confirming Brian. >>>>>>>>>> >>>>>>>>>> Perhaps we could set it to: >>>>>>>>>> node-identifier="${jboss.tx.node.id:1}" >>>>>>>>>> (a bit like >>>>>>>>>> https://github.com/jboss-developer/jboss-eap-quickstarts/tree/7.1/jts >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> Sebastian could set -Djboss.tx.node.id during startup in a >>>>>>>>>> script? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7 May 2018 at 22:08, Brian Stansberry < >>>>>>>>>> brian.stansberry at redhat.com> wrote: >>>>>>>>>> >>>>>>>>>>> If it's not already set, WildFly sets the system property >>>>>>>>>>> jboss.node.name at the very beginning of server boot, so ${ >>>>>>>>>>> jboss.node.name*:1*} would not resolve to 1. >>>>>>>>>>> >>>>>>>>>>> On Sun, May 6, 2018 at 6:10 PM, Sebastian Laskawiec < >>>>>>>>>>> slaskawi at redhat.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Ok, so how about doing the same thing you suggested, but just >>>>>>>>>>>> more explicitly - adding node-identifier="${jboss.node.name*:1*}". >>>>>>>>>>>> This way the bare metal deployment should be happy (since the default is >>>>>>>>>>>> still 1) and we wouldn't need to override it in Infinispan. >>>>>>>>>>>> >>>>>>>>>>>> On Tue, May 1, 2018 at 10:09 AM Tom Jenkinson < >>>>>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I am not sure - the default should be "1" for the bare metal >>>>>>>>>>>>> case so the warning is reliably triggered but the default can be the pod >>>>>>>>>>>>> name for OpenShift templates that only allow a single instance of the >>>>>>>>>>>>> application server - does that help? >>>>>>>>>>>>> >>>>>>>>>>>>> The file you looked to want to edit is shared by bare metal >>>>>>>>>>>>> and other deployment environments so it would be confusing to set the >>>>>>>>>>>>> default to jboss.node.name there IMO. >>>>>>>>>>>>> >>>>>>>>>>>>> On 1 May 2018 at 03:39, Sebastian Laskawiec < >>>>>>>>>>>>> slaskawi at redhat.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Fair enough Tom. Thanks for explanation. >>>>>>>>>>>>>> >>>>>>>>>>>>>> One more request - would you guys be OK with me adding >>>>>>>>>>>>>> a node-identifier="${jboss.node.name}" to the transaction >>>>>>>>>>>>>> subsystem template [1]? This way we wouldn't need to copy it into >>>>>>>>>>>>>> Infinispan (since we need to set it). >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] >>>>>>>>>>>>>> https://github.com/wildfly/wildfly/blob/master/transactions/src/main/resources/subsystem-templates/transactions.xml#L6 >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson < >>>>>>>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec < >>>>>>>>>>>>>>> slaskawi at redhat.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hey Tom, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Comments inlined. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Sebastian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson < >>>>>>>>>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 16 April 2018 at 09:31, <> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Adding +WildFly Dev to >>>>>>>>>>>>>>>>>> the loop >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks for the explanation Rado. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> TL;DR: A while ago Sanne pointed out that we do not set >>>>>>>>>>>>>>>>>> `node-identifier` >>>>>>>>>>>>>>>>>> in transaction subsystem by default. The default value >>>>>>>>>>>>>>>>>> for the >>>>>>>>>>>>>>>>>> `node-identifier` attribute it `1`. Not setting this >>>>>>>>>>>>>>>>>> attribute might cause >>>>>>>>>>>>>>>>>> problems in transaction recovery. Perhaps we could follow >>>>>>>>>>>>>>>>>> Rado's idea and >>>>>>>>>>>>>>>>>> set it to node name by default? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Indeed - it would cause serious data integrity problems if >>>>>>>>>>>>>>>>> a non-unique node-identifier is used. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Some more comments inlined. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Sebastian >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar >>>>>>>>>>>>>>>>> redhat.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > Hi Sebastian, >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec >>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>> > > Hey Rado, Paul, >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> > > I started looking into this issue and it turned out >>>>>>>>>>>>>>>>>> that WF subsystem >>>>>>>>>>>>>>>>>> > > template doesn't provide `node-identifier` attribute >>>>>>>>>>>>>>>>>> [1]. >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > I assume you mean that the default WildFly server >>>>>>>>>>>>>>>>>> profiles do not >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > explicitly define the attribute. Right ? thus the value >>>>>>>>>>>>>>>>>> defaults in >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > the model to "1" >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/subsystem/TransactionSubsystemRootResourceDefinition.java#L97 >>>>>>>>>>>>>>>>>> > which sole intention seems to be to log a warning on >>>>>>>>>>>>>>>>>> boot if the value >>>>>>>>>>>>>>>>>> > is unchanged. >>>>>>>>>>>>>>>>>> > Why they decided on a constant that will be inherently >>>>>>>>>>>>>>>>>> not unique as >>>>>>>>>>>>>>>>>> > opposed to defaulting to the node name (which we >>>>>>>>>>>>>>>>>> already require to be >>>>>>>>>>>>>>>>>> > unique) as clustering node name or undertow instance-id >>>>>>>>>>>>>>>>>> does, is >>>>>>>>>>>>>>>>>> > unclear to me. >>>>>>>>>>>>>>>>>> > Some context is on >>>>>>>>>>>>>>>>>> https://issues.jboss.org/browse/WFLY-1119. >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In OpenShift environment we could set it to `hostname`. >>>>>>>>>>>>>>>>>> This is guaranteed >>>>>>>>>>>>>>>>>> to be unique in whole OpenShift cluster. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We do this too in EAP images. >>>>>>>>>>>>>>>>> To Rado's point, the default is "1" so we can print the >>>>>>>>>>>>>>>>> warning to alert people they are misconfigured - it seems to be working :) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is the point. From my understanding, if we set it to >>>>>>>>>>>>>>>> node name (instead of "1"), we could make it always work correctly. We >>>>>>>>>>>>>>>> could even remove the code that emits the warning (since the node name >>>>>>>>>>>>>>>> needs to be unique). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> To sum it up - if we decided to proceed this way, there >>>>>>>>>>>>>>>> would be no requirement of setting the node-identifier at all. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For OpenShift you are right there is no requirement for >>>>>>>>>>>>>>> someone to change the node-identifier from the podname and so that is why >>>>>>>>>>>>>>> EAP images do that. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For bare-metal it is different as there can be two servers >>>>>>>>>>>>>>> on the same machine so they were configured to use the hostname as they >>>>>>>>>>>>>>> node-identifier then if they were also connected to the same resource >>>>>>>>>>>>>>> managers or the same object store they would interfere with each other. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > > I'm not sure if you guys are the right people to ask, >>>>>>>>>>>>>>>>>> but is it safe to >>>>>>>>>>>>>>>>>> > > leave it set to default? Or shall I override our >>>>>>>>>>>>>>>>>> Infinispan templates and >>>>>>>>>>>>>>>>>> > > add this parameter (as I mentioned before, in >>>>>>>>>>>>>>>>>> OpenShift this I wanted to >>>>>>>>>>>>>>>>>> > set >>>>>>>>>>>>>>>>>> > > it as Pod name trimmed to the last 23 chars since >>>>>>>>>>>>>>>>>> this is the limit). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Putting a response to this in line - I am not certain who >>>>>>>>>>>>>>>>> originally proposed this. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> You must use a globally unique node-identifier. If you are >>>>>>>>>>>>>>>>> certain the last 23 characters guarantee that it would be valid - if there >>>>>>>>>>>>>>>>> is a chance they are not unique it is not valid to trim. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If that's not an issue, again, we could use the same limit >>>>>>>>>>>>>>>> as we have for node name. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > It is not safe to leave it set to "1" as that results >>>>>>>>>>>>>>>>>> in inconsistent >>>>>>>>>>>>>>>>>> > processing of transaction recovery. >>>>>>>>>>>>>>>>>> > IIUC we already set it to the node name for both EAP >>>>>>>>>>>>>>>>>> and JDG >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> https://github.com/jboss-openshift/cct_module/blob/master/os-eap70-openshift/added/standalone-openshift.xml#L411 >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> https://github.com/jboss-openshift/cct_module/blob/master/os-jdg7-conffiles/added/clustered-openshift.xml#L282 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > which in turn defaults to the pod name ? so which >>>>>>>>>>>>>>>>>> profiles are we >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > talking about here? >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Granted, we set it by default in CCT Modules. However in >>>>>>>>>>>>>>>>>> Infinispan we just >>>>>>>>>>>>>>>>>> grab provided transaction subsystem when rendering full >>>>>>>>>>>>>>>>>> configuration from >>>>>>>>>>>>>>>>>> featurepacks: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> https://github.com/infinispan/infinispan/blob/master/server/integration/feature-pack/src/main/resources/configuration/standalone/subsystems-cloud.xml#L19 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The default configuration XML doesn't contain the >>>>>>>>>>>>>>>>>> `node-identifier` >>>>>>>>>>>>>>>>>> attribute. I can add it manually in the cloud.xml but I >>>>>>>>>>>>>>>>>> believe the right >>>>>>>>>>>>>>>>>> approach is to modify the transaction subsystem. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > Rado >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > > Thanks, >>>>>>>>>>>>>>>>>> > > Seb >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> > > [1] usually set to node-identifier="${jboss.node.name >>>>>>>>>>>>>>>>>> }" >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero >>>>>>>>>>>>>>>>> at infinispan.org> >>>>>>>>>>>>>>>>>> > > wrote: >>>>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>> > >> > Thanks for looking into it Sanne. Of course, we >>>>>>>>>>>>>>>>>> should add it (it can >>>>>>>>>>>>>>>>>> > be >>>>>>>>>>>>>>>>>> > >> > set >>>>>>>>>>>>>>>>>> > >> > to the same name as hostname since those are >>>>>>>>>>>>>>>>>> unique in Kubernetes). >>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 >>>>>>>>>>>>>>>>>> for it. >>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>> > >> > Thanks again! >>>>>>>>>>>>>>>>>> > >> > Seb >>>>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>>>> > >> Thanks Sebastian! >>>>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >> > wrote: >>>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>>> > >> >> Hi all, >>>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>>> > >> >> I've started to use the Infinispan Openshift >>>>>>>>>>>>>>>>>> Template and was >>>>>>>>>>>>>>>>>> > browsing >>>>>>>>>>>>>>>>>> > >> >> through the errors and warnings this produces. >>>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>>> > >> >> In particular I noticed "WFLYTX0013: Node >>>>>>>>>>>>>>>>>> identifier property is set >>>>>>>>>>>>>>>>>> > >> >> to the default value. Please make sure it is >>>>>>>>>>>>>>>>>> unique." being produced >>>>>>>>>>>>>>>>>> > >> >> by the transaction system. >>>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>>> > >> >> The node id is usually not needed for developer's >>>>>>>>>>>>>>>>>> convenience and >>>>>>>>>>>>>>>>>> > >> >> assuming there's a single node in "dev mode", yet >>>>>>>>>>>>>>>>>> clearly the >>>>>>>>>>>>>>>>>> > >> >> Infinispan template is meant to work with >>>>>>>>>>>>>>>>>> multiple nodes running so >>>>>>>>>>>>>>>>>> > >> >> this warning seems concerning. >>>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>>> > >> >> I'm not sure what the impact is on the >>>>>>>>>>>>>>>>>> transaction manager so I asked >>>>>>>>>>>>>>>>>> > >> >> on the Narayana forums; Tom pointed me to some >>>>>>>>>>>>>>>>>> thourough design >>>>>>>>>>>>>>>>>> > >> >> documents and also suggested the EAP image does >>>>>>>>>>>>>>>>>> set the node >>>>>>>>>>>>>>>>>> > >> >> identifier: >>>>>>>>>>>>>>>>>> > >> >> - >>>>>>>>>>>>>>>>>> https://developer.jboss.org/message/981702#981702 >>>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>>> > >> >> WDYT? we probably want the Infinispan template to >>>>>>>>>>>>>>>>>> set this as well, >>>>>>>>>>>>>>>>>> > or >>>>>>>>>>>>>>>>>> > >> >> silence the warning? >>>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>>> > >> >> Thanks, >>>>>>>>>>>>>>>>>> > >> >> Sanne >>>>>>>>>>>>>>>>>> > >> >> _______________________________________________ >>>>>>>>>>>>>>>>>> > >> >> infinispan-dev mailing list >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >> >> infinispan-dev at lists.jboss.org >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>> > >> > _______________________________________________ >>>>>>>>>>>>>>>>>> > >> > infinispan-dev mailing list >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > >> > infinispan-dev at lists.jboss.org >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>>>>>>>>>>>>>>> > >> _______________________________________________ >>>>>>>>>>>>>>>>>> > >> infinispan-dev mailing list >>>>>>>>>>>>>>>>>> > >> infinispan-dev at lists.jboss.org >>>>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> -------------- next part -------------- >>>>>>>>>>>>>>>>>> An HTML attachment was scrubbed... >>>>>>>>>>>>>>>>>> URL: >>>>>>>>>>>>>>>>>> http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180416/65962cf1/attachment-0001.html >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> wildfly-dev mailing list >>>>>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Brian Stansberry >>>>>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>>>>> Red Hat >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Brian Stansberry >>>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>>> Red Hat >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Brian Stansberry >>>>>>> Manager, Senior Principal Software Engineer >>>>>>> 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/20180710/c453a362/attachment-0001.html From tom.jenkinson at redhat.com Wed Jul 11 04:12:36 2018 From: tom.jenkinson at redhat.com (Tom Jenkinson) Date: Wed, 11 Jul 2018 09:12:36 +0100 Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan Openshift Template In-Reply-To: References: Message-ID: No problem! On 10 July 2018 at 19:47, Sebastian ?askawiec wrote: > Good stuff. Thank you Tom! > > On Tue, 10 Jul 2018 at 18:11 Tom Jenkinson > wrote: > >> I raised a PR for this now. >> >> On 10 July 2018 at 15:40, Tom Jenkinson wrote: >> >>> Hi Sebastian, >>> >>> I am not sure if you raised an issue for this but I have just found one >>> from Brad that was similar so I am using that one: >>> https://issues.jboss.org/browse/WFLY-10541 >>> >>> Thanks, >>> Tom >>> >>> On 10 July 2018 at 14:32, Sebastian Laskawiec >>> wrote: >>> >>>> Hey Tom! >>>> >>>> Could you please tell me what is the status of this? It seems one of >>>> the Keycloak users got hit by this problem: http://lists.jboss. >>>> org/pipermail/keycloak-dev/2018-July/010985.html >>>> >>>> Thanks, >>>> Sebastian >>>> >>>> On Thu, May 10, 2018 at 11:10 AM Tom Jenkinson < >>>> tom.jenkinson at redhat.com> wrote: >>>> >>>>> Sure - thanks! >>>>> >>>>> On 10 May 2018 at 02:56, Sebastian Laskawiec >>>>> wrote: >>>>> >>>>>> I'm sorry for delay... I got sucked by the Summit prep activities. >>>>>> >>>>>> Yes, to all, what you said! Shall I create a JIRA for you? >>>>>> >>>>>> >>>>>> >>>>>> On Wed, May 9, 2018 at 9:39 AM Tom Jenkinson < >>>>>> tom.jenkinson at redhat.com> wrote: >>>>>> >>>>>>> Thanks Brian. Does it work for you Sebastian? >>>>>>> >>>>>>> On 8 May 2018 at 23:05, Brian Stansberry < >>>>>>> brian.stansberry at redhat.com> wrote: >>>>>>> >>>>>>>> Ah, ok. I was thinking of scripting in the broad sense the various >>>>>>>> stuff that goes into creating images. >>>>>>>> >>>>>>>> In any case, I don't see any downside to having node-identifier="${ >>>>>>>> jboss.tx.node.id:1}" in the standard WF config files. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, May 8, 2018 at 3:07 PM, Tom Jenkinson < >>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>> >>>>>>>>> I think they want to avoid changing the standalone.xml file and >>>>>>>>> just want to control it from their startup script. >>>>>>>>> >>>>>>>>> On 8 May 2018 at 18:45, Brian Stansberry < >>>>>>>>> brian.stansberry at redhat.com> wrote: >>>>>>>>> >>>>>>>>>> I might have missed something along the way, but if they are >>>>>>>>>> going to do scripting wouldn't they just set the attribute to ${ >>>>>>>>>> jboss.node.name} and count on the fact that this is unique per >>>>>>>>>> pod? >>>>>>>>>> >>>>>>>>>> On Tue, May 8, 2018 at 3:28 AM, Tom Jenkinson < >>>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>>> >>>>>>>>>>> Thanks for confirming Brian. >>>>>>>>>>> >>>>>>>>>>> Perhaps we could set it to: >>>>>>>>>>> node-identifier="${jboss.tx.node.id:1}" >>>>>>>>>>> (a bit like https://github.com/jboss-developer/jboss-eap- >>>>>>>>>>> quickstarts/tree/7.1/jts) >>>>>>>>>>> >>>>>>>>>>> Sebastian could set -Djboss.tx.node.id during startup in a >>>>>>>>>>> script? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 7 May 2018 at 22:08, Brian Stansberry < >>>>>>>>>>> brian.stansberry at redhat.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> If it's not already set, WildFly sets the system property >>>>>>>>>>>> jboss.node.name at the very beginning of server boot, so ${ >>>>>>>>>>>> jboss.node.name*:1*} would not resolve to 1. >>>>>>>>>>>> >>>>>>>>>>>> On Sun, May 6, 2018 at 6:10 PM, Sebastian Laskawiec < >>>>>>>>>>>> slaskawi at redhat.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Ok, so how about doing the same thing you suggested, but just >>>>>>>>>>>>> more explicitly - adding node-identifier="${jboss.node.name >>>>>>>>>>>>> *:1*}". This way the bare metal deployment should be happy >>>>>>>>>>>>> (since the default is still 1) and we wouldn't need to override it in >>>>>>>>>>>>> Infinispan. >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, May 1, 2018 at 10:09 AM Tom Jenkinson < >>>>>>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I am not sure - the default should be "1" for the bare metal >>>>>>>>>>>>>> case so the warning is reliably triggered but the default can be the pod >>>>>>>>>>>>>> name for OpenShift templates that only allow a single instance of the >>>>>>>>>>>>>> application server - does that help? >>>>>>>>>>>>>> >>>>>>>>>>>>>> The file you looked to want to edit is shared by bare metal >>>>>>>>>>>>>> and other deployment environments so it would be confusing to set the >>>>>>>>>>>>>> default to jboss.node.name there IMO. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 1 May 2018 at 03:39, Sebastian Laskawiec < >>>>>>>>>>>>>> slaskawi at redhat.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fair enough Tom. Thanks for explanation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> One more request - would you guys be OK with me adding >>>>>>>>>>>>>>> a node-identifier="${jboss.node.name}" to the transaction >>>>>>>>>>>>>>> subsystem template [1]? This way we wouldn't need to copy it into >>>>>>>>>>>>>>> Infinispan (since we need to set it). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] https://github.com/wildfly/wildfly/blob/master/ >>>>>>>>>>>>>>> transactions/src/main/resources/subsystem-templates/ >>>>>>>>>>>>>>> transactions.xml#L6 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson < >>>>>>>>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec < >>>>>>>>>>>>>>>> slaskawi at redhat.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hey Tom, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Comments inlined. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Sebastian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson < >>>>>>>>>>>>>>>>> tom.jenkinson at redhat.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 16 April 2018 at 09:31, <> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Adding +WildFly Dev to >>>>>>>>>>>>>>>>>>> the loop >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks for the explanation Rado. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> TL;DR: A while ago Sanne pointed out that we do not set >>>>>>>>>>>>>>>>>>> `node-identifier` >>>>>>>>>>>>>>>>>>> in transaction subsystem by default. The default value >>>>>>>>>>>>>>>>>>> for the >>>>>>>>>>>>>>>>>>> `node-identifier` attribute it `1`. Not setting this >>>>>>>>>>>>>>>>>>> attribute might cause >>>>>>>>>>>>>>>>>>> problems in transaction recovery. Perhaps we could >>>>>>>>>>>>>>>>>>> follow Rado's idea and >>>>>>>>>>>>>>>>>>> set it to node name by default? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Indeed - it would cause serious data integrity problems >>>>>>>>>>>>>>>>>> if a non-unique node-identifier is used. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Some more comments inlined. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Sebastian >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar >>>>>>>>>>>>>>>>>> at redhat.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > Hi Sebastian, >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec >>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>> > > Hey Rado, Paul, >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> > > I started looking into this issue and it turned out >>>>>>>>>>>>>>>>>>> that WF subsystem >>>>>>>>>>>>>>>>>>> > > template doesn't provide `node-identifier` attribute >>>>>>>>>>>>>>>>>>> [1]. >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > I assume you mean that the default WildFly server >>>>>>>>>>>>>>>>>>> profiles do not >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > explicitly define the attribute. Right ? thus the value >>>>>>>>>>>>>>>>>>> defaults in >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > the model to "1" >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > https://github.com/wildfly/wildfly/blob/master/ >>>>>>>>>>>>>>>>>>> transactions/src/main/java/org/jboss/as/txn/subsystem/ >>>>>>>>>>>>>>>>>>> TransactionSubsystemRootResourceDefinition.java#L97 >>>>>>>>>>>>>>>>>>> > which sole intention seems to be to log a warning on >>>>>>>>>>>>>>>>>>> boot if the value >>>>>>>>>>>>>>>>>>> > is unchanged. >>>>>>>>>>>>>>>>>>> > Why they decided on a constant that will be inherently >>>>>>>>>>>>>>>>>>> not unique as >>>>>>>>>>>>>>>>>>> > opposed to defaulting to the node name (which we >>>>>>>>>>>>>>>>>>> already require to be >>>>>>>>>>>>>>>>>>> > unique) as clustering node name or undertow >>>>>>>>>>>>>>>>>>> instance-id does, is >>>>>>>>>>>>>>>>>>> > unclear to me. >>>>>>>>>>>>>>>>>>> > Some context is on https://issues.jboss.org/ >>>>>>>>>>>>>>>>>>> browse/WFLY-1119. >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> In OpenShift environment we could set it to `hostname`. >>>>>>>>>>>>>>>>>>> This is guaranteed >>>>>>>>>>>>>>>>>>> to be unique in whole OpenShift cluster. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> We do this too in EAP images. >>>>>>>>>>>>>>>>>> To Rado's point, the default is "1" so we can print the >>>>>>>>>>>>>>>>>> warning to alert people they are misconfigured - it seems to be working :) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This is the point. From my understanding, if we set it to >>>>>>>>>>>>>>>>> node name (instead of "1"), we could make it always work correctly. We >>>>>>>>>>>>>>>>> could even remove the code that emits the warning (since the node name >>>>>>>>>>>>>>>>> needs to be unique). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> To sum it up - if we decided to proceed this way, there >>>>>>>>>>>>>>>>> would be no requirement of setting the node-identifier at all. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For OpenShift you are right there is no requirement for >>>>>>>>>>>>>>>> someone to change the node-identifier from the podname and so that is why >>>>>>>>>>>>>>>> EAP images do that. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For bare-metal it is different as there can be two servers >>>>>>>>>>>>>>>> on the same machine so they were configured to use the hostname as they >>>>>>>>>>>>>>>> node-identifier then if they were also connected to the same resource >>>>>>>>>>>>>>>> managers or the same object store they would interfere with each other. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > > I'm not sure if you guys are the right people to >>>>>>>>>>>>>>>>>>> ask, but is it safe to >>>>>>>>>>>>>>>>>>> > > leave it set to default? Or shall I override our >>>>>>>>>>>>>>>>>>> Infinispan templates and >>>>>>>>>>>>>>>>>>> > > add this parameter (as I mentioned before, in >>>>>>>>>>>>>>>>>>> OpenShift this I wanted to >>>>>>>>>>>>>>>>>>> > set >>>>>>>>>>>>>>>>>>> > > it as Pod name trimmed to the last 23 chars since >>>>>>>>>>>>>>>>>>> this is the limit). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Putting a response to this in line - I am not certain who >>>>>>>>>>>>>>>>>> originally proposed this. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> You must use a globally unique node-identifier. If you >>>>>>>>>>>>>>>>>> are certain the last 23 characters guarantee that it would be valid - if >>>>>>>>>>>>>>>>>> there is a chance they are not unique it is not valid to trim. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If that's not an issue, again, we could use the same limit >>>>>>>>>>>>>>>>> as we have for node name. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > It is not safe to leave it set to "1" as that results >>>>>>>>>>>>>>>>>>> in inconsistent >>>>>>>>>>>>>>>>>>> > processing of transaction recovery. >>>>>>>>>>>>>>>>>>> > IIUC we already set it to the node name for both EAP >>>>>>>>>>>>>>>>>>> and JDG >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/ >>>>>>>>>>>>>>>>>>> master/os-eap70-openshift/added/standalone-openshift. >>>>>>>>>>>>>>>>>>> xml#L411 >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/ >>>>>>>>>>>>>>>>>>> master/os-jdg7-conffiles/added/clustered-openshift.xml# >>>>>>>>>>>>>>>>>>> L282 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > which in turn defaults to the pod name ? so which >>>>>>>>>>>>>>>>>>> profiles are we >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > talking about here? >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Granted, we set it by default in CCT Modules. However in >>>>>>>>>>>>>>>>>>> Infinispan we just >>>>>>>>>>>>>>>>>>> grab provided transaction subsystem when rendering full >>>>>>>>>>>>>>>>>>> configuration from >>>>>>>>>>>>>>>>>>> featurepacks: >>>>>>>>>>>>>>>>>>> https://github.com/infinispan/ >>>>>>>>>>>>>>>>>>> infinispan/blob/master/server/ >>>>>>>>>>>>>>>>>>> integration/feature-pack/src/ >>>>>>>>>>>>>>>>>>> main/resources/configuration/ >>>>>>>>>>>>>>>>>>> standalone/subsystems-cloud.xml#L19 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The default configuration XML doesn't contain the >>>>>>>>>>>>>>>>>>> `node-identifier` >>>>>>>>>>>>>>>>>>> attribute. I can add it manually in the cloud.xml but I >>>>>>>>>>>>>>>>>>> believe the right >>>>>>>>>>>>>>>>>>> approach is to modify the transaction subsystem. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > Rado >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > > Thanks, >>>>>>>>>>>>>>>>>>> > > Seb >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> > > [1] usually set to node-identifier="${jboss.node. >>>>>>>>>>>>>>>>>>> name}" >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > > wrote: >>>>>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>>>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>> > >> > Thanks for looking into it Sanne. Of course, we >>>>>>>>>>>>>>>>>>> should add it (it can >>>>>>>>>>>>>>>>>>> > be >>>>>>>>>>>>>>>>>>> > >> > set >>>>>>>>>>>>>>>>>>> > >> > to the same name as hostname since those are >>>>>>>>>>>>>>>>>>> unique in Kubernetes). >>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 >>>>>>>>>>>>>>>>>>> for it. >>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>> > >> > Thanks again! >>>>>>>>>>>>>>>>>>> > >> > Seb >>>>>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>>>>> > >> Thanks Sebastian! >>>>>>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >> > wrote: >>>>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>>>> > >> >> Hi all, >>>>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>>>> > >> >> I've started to use the Infinispan Openshift >>>>>>>>>>>>>>>>>>> Template and was >>>>>>>>>>>>>>>>>>> > browsing >>>>>>>>>>>>>>>>>>> > >> >> through the errors and warnings this produces. >>>>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>>>> > >> >> In particular I noticed "WFLYTX0013: Node >>>>>>>>>>>>>>>>>>> identifier property is set >>>>>>>>>>>>>>>>>>> > >> >> to the default value. Please make sure it is >>>>>>>>>>>>>>>>>>> unique." being produced >>>>>>>>>>>>>>>>>>> > >> >> by the transaction system. >>>>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>>>> > >> >> The node id is usually not needed for >>>>>>>>>>>>>>>>>>> developer's convenience and >>>>>>>>>>>>>>>>>>> > >> >> assuming there's a single node in "dev mode", >>>>>>>>>>>>>>>>>>> yet clearly the >>>>>>>>>>>>>>>>>>> > >> >> Infinispan template is meant to work with >>>>>>>>>>>>>>>>>>> multiple nodes running so >>>>>>>>>>>>>>>>>>> > >> >> this warning seems concerning. >>>>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>>>> > >> >> I'm not sure what the impact is on the >>>>>>>>>>>>>>>>>>> transaction manager so I asked >>>>>>>>>>>>>>>>>>> > >> >> on the Narayana forums; Tom pointed me to some >>>>>>>>>>>>>>>>>>> thourough design >>>>>>>>>>>>>>>>>>> > >> >> documents and also suggested the EAP image does >>>>>>>>>>>>>>>>>>> set the node >>>>>>>>>>>>>>>>>>> > >> >> identifier: >>>>>>>>>>>>>>>>>>> > >> >> - https://developer.jboss.org/ >>>>>>>>>>>>>>>>>>> message/981702#981702 >>>>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>>>> > >> >> WDYT? we probably want the Infinispan template >>>>>>>>>>>>>>>>>>> to set this as well, >>>>>>>>>>>>>>>>>>> > or >>>>>>>>>>>>>>>>>>> > >> >> silence the warning? >>>>>>>>>>>>>>>>>>> > >> >> >>>>>>>>>>>>>>>>>>> > >> >> Thanks, >>>>>>>>>>>>>>>>>>> > >> >> Sanne >>>>>>>>>>>>>>>>>>> > >> >> _______________________________________________ >>>>>>>>>>>>>>>>>>> > >> >> infinispan-dev mailing list >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >> >> infinispan-dev at lists.jboss.org >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >> >> https://lists.jboss.org/ >>>>>>>>>>>>>>>>>>> mailman/listinfo/infinispan-dev >>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>> > >> > _______________________________________________ >>>>>>>>>>>>>>>>>>> > >> > infinispan-dev mailing list >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > >> > infinispan-dev at lists.jboss.org >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > >> > https://lists.jboss.org/ >>>>>>>>>>>>>>>>>>> mailman/listinfo/infinispan-dev >>>>>>>>>>>>>>>>>>> > >> _______________________________________________ >>>>>>>>>>>>>>>>>>> > >> infinispan-dev mailing list >>>>>>>>>>>>>>>>>>> > >> infinispan-dev at lists.jboss.org >>>>>>>>>>>>>>>>>>> > >> https://lists.jboss.org/ >>>>>>>>>>>>>>>>>>> mailman/listinfo/infinispan-dev >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> -------------- next part -------------- >>>>>>>>>>>>>>>>>>> An HTML attachment was scrubbed... >>>>>>>>>>>>>>>>>>> URL: http://lists.jboss.org/pipermail/wildfly-dev/ >>>>>>>>>>>>>>>>>>> attachments/20180416/65962cf1/attachment-0001.html >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> wildfly-dev mailing list >>>>>>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Brian Stansberry >>>>>>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>>>>>> Red Hat >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Brian Stansberry >>>>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>>>> Red Hat >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Brian Stansberry >>>>>>>> Manager, Senior Principal Software Engineer >>>>>>>> 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/20180711/327af810/attachment-0001.html From elayaraja.s at gmail.com Wed Jul 11 09:09:30 2018 From: elayaraja.s at gmail.com (wildflyuser) Date: Wed, 11 Jul 2018 06:09:30 -0700 (MST) Subject: [wildfly-dev] wildfly-9.0.2.Final : Sequence of loading *.war file Message-ID: <1531314570646-0.post@n5.nabble.com> My ear file "myapp.ear" contains 3 war file, web1.war, web2.war, web3.war (Menu has been defined) Some time i was not able to see the menu was not loading in my application. if i restart its working. do we required to define the sequence of loading *.war file ? Coudl you please give some idea on this issue. In jboss-deployment-structure.xml, below is my entry -- Sent from: http://wildfly-development.1055759.n5.nabble.com/ From elayaraja.s at gmail.com Fri Jul 13 21:09:27 2018 From: elayaraja.s at gmail.com (wildflyuser) Date: Fri, 13 Jul 2018 18:09:27 -0700 (MST) Subject: [wildfly-dev] wildfly-9.0.2.Final : Resetting heartbeat timestamps because of huge system clock jump! Message-ID: <1531530567882-0.post@n5.nabble.com> Not able to start wildfly-9.0.2.Final, looks like configuration issue. Please help us. 22:07:12,403 INFO [com.hazelcast.cluster.impl.ClusterHeartbeatManager] (cached1) [10.111.1.100]:5701 [dev] [3.6.1] System clock apparently jumped from 2018-07-13T22:03:20.066 to 2018-07-13T22:07:12.214 since last heartbeat (+227148 ms) 22:07:12,517 WARNING [com.hazelcast.cluster.impl.ClusterHeartbeatManager] (cached1) [10.111.1.100]:5701 [dev] [3.6.1] Resetting master confirmation timestamps because of huge system clock jump! Clock-Jump: 227148 ms, Master-Confirmation-Timeout: 350000 ms 22:07:12,566 WARNING [com.hazelcast.cluster.impl.ClusterHeartbeatManager] (cached1) [10.111.1.100]:5701 [dev] [3.6.1] Resetting heartbeat timestamps because of huge system clock jump! Clock-Jump: 227148 ms, Heartbeat-Timeout: 300000 ms -- Sent from: http://wildfly-development.1055759.n5.nabble.com/ From brian.stansberry at redhat.com Mon Jul 16 11:23:49 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 16 Jul 2018 10:23:49 -0500 Subject: [wildfly-dev] wildfly-9.0.2.Final : Resetting heartbeat timestamps because of huge system clock jump! In-Reply-To: <1531530567882-0.post@n5.nabble.com> References: <1531530567882-0.post@n5.nabble.com> Message-ID: Please use the forums for help. This list is for discussion of the development of WildFly itself. On Fri, Jul 13, 2018 at 8:09 PM, wildflyuser wrote: > Not able to start wildfly-9.0.2.Final, looks like configuration issue. > Please > help us. > > 22:07:12,403 INFO [com.hazelcast.cluster.impl.ClusterHeartbeatManager] > (cached1) [10.111.1.100]:5701 [dev] [3.6.1] System clock apparently jumped > from 2018-07-13T22:03:20.066 to 2018-07-13T22:07:12.214 since last > heartbeat > (+227148 ms) > 22:07:12,517 WARNING [com.hazelcast.cluster.impl.ClusterHeartbeatManager] > (cached1) [10.111.1.100]:5701 [dev] [3.6.1] Resetting master confirmation > timestamps because of huge system clock jump! Clock-Jump: 227148 ms, > Master-Confirmation-Timeout: 350000 ms > 22:07:12,566 WARNING [com.hazelcast.cluster.impl.ClusterHeartbeatManager] > (cached1) [10.111.1.100]:5701 [dev] [3.6.1] Resetting heartbeat timestamps > because of huge system clock jump! Clock-Jump: 227148 ms, > Heartbeat-Timeout: > 300000 ms > > > > > -- > Sent from: http://wildfly-development.1055759.n5.nabble.com/ > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180716/ed4f8a48/attachment.html From rory.odonnell at oracle.com Tue Jul 17 07:17:40 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 17 Jul 2018 12:17:40 +0100 Subject: [wildfly-dev] JDK 11 Early Access build 22 & JDK 12 Early Access b02 are available. Message-ID: Hi Jason/Tomaz, *JDK 11 is in Rampdown Phase one* * *The overall feature set is frozen. No further JEPs will be targeted to this release.* * *Rampdown Phase two is scheduled to start * *26th of July* **JDK 11 EA build 22 , *****under both the GPL and Oracle EA licenses, is now available at **http://jdk.java.net/11**. *** * Schedule, status & features o http://openjdk.java.net/projects/jdk/11/ * Release Notes: o http://jdk.java.net/11/release-notes *FOSS fixes in recent builds.* * JBoss Netty (b17) - JDK-8203937 (b17) * JUnit5 & other Foss Projects (b22) -JDK-8206355 **Notable changes in JDK 11 EA *build 22* * New Collection.toArray(IntFunction) Default Method (JDK-8060192 ) * Make some system properties effectively readonly (JDK-8066709 ) * Obsolete Support for Commercial Features (JDK-8202331 ) * JFR start failure after AppCDS archive created with JFR StartFlightRecording (JDK-8203664 ) * Change to policy for the default set of modules resolved when compiling or running code on the class path (JDK-8197532 ) *JDK 12 Early Access Build 02 is available at **http://jdk.java.net/12/* * OpenJDK builds o These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception . * Changes in this build are listed here *The Quality Report for July 2018 is published **here * * With the new six months release , we now publish the Quality report every three months. * Thanks to all the FOSS Projects for logging bugs against the JDK 11 EA Builds! Rgds,Rory [1] http://openjdk.java.net/projects/jdk/11/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180717/dbcce7cd/attachment.html From ttarrant at redhat.com Tue Jul 17 07:49:22 2018 From: ttarrant at redhat.com (Tristan Tarrant) Date: Tue, 17 Jul 2018 13:49:22 +0200 Subject: [wildfly-dev] wildfly-9.0.2.Final : Resetting heartbeat timestamps because of huge system clock jump! In-Reply-To: References: <1531530567882-0.post@n5.nabble.com> Message-ID: <436caf61-6efd-b471-f2fa-843747e51219@redhat.com> Additionally, WildFly does not include Hazelcast, so this is a problem solely in your deployment. Tristan On 7/16/18 5:23 PM, Brian Stansberry wrote: > Please use the forums for help. > > This list is for discussion of the development of WildFly itself. > > On Fri, Jul 13, 2018 at 8:09 PM, wildflyuser > wrote: > > Not able to start wildfly-9.0.2.Final, looks like configuration > issue. Please > help us. > > 22:07:12,403 INFO? [com.hazelcast.cluster.impl.ClusterHeartbeatManager] > (cached1) [10.111.1.100]:5701 [dev] [3.6.1] System clock apparently > jumped > from 2018-07-13T22:03:20.066 to 2018-07-13T22:07:12.214 since last > heartbeat > (+227148 ms) > 22:07:12,517 WARNING > [com.hazelcast.cluster.impl.ClusterHeartbeatManager] > (cached1) [10.111.1.100]:5701 [dev] [3.6.1] Resetting master > confirmation > timestamps because of huge system clock jump! Clock-Jump: 227148 ms, > Master-Confirmation-Timeout: 350000 ms > 22:07:12,566 WARNING > [com.hazelcast.cluster.impl.ClusterHeartbeatManager] > (cached1) [10.111.1.100]:5701 [dev] [3.6.1] Resetting heartbeat > timestamps > because of huge system clock jump! Clock-Jump: 227148 ms, > Heartbeat-Timeout: > 300000 ms > > > > > -- > Sent from: http://wildfly-development.1055759.n5.nabble.com/ > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From belaran at redhat.com Wed Jul 18 04:22:31 2018 From: belaran at redhat.com (Romain Pelisse) Date: Wed, 18 Jul 2018 10:22:31 +0200 Subject: [wildfly-dev] Healtchecking the Console using unit test Message-ID: Hi all, Is there a unit inside HAL code base I could use to automate checking that the console is working properly after firing Wildfly? I've try to look for that myself, but i've been a bit confused by the code base I'm must confess. (I've kept it short, but feel free to ask for more context if you need to) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180718/a42e1fc9/attachment-0001.html From hpehl at redhat.com Wed Jul 18 04:34:41 2018 From: hpehl at redhat.com (Harald Pehl) Date: Wed, 18 Jul 2018 10:34:41 +0200 Subject: [wildfly-dev] Healtchecking the Console using unit test In-Reply-To: References: Message-ID: <500EFEC4-7919-4C57-84FB-34B30739E646@redhat.com> You could try to use `curl --head http://localhost:9990/console/index.html` which should return something like HTTP/1.1 200 OK Connection: keep-alive Last-Modified: Fri, 13 Jul 2018 14:27:50 GMT X-Frame-Options: SAMEORIGIN Content-Length: 1288 Content-Type: text/html Accept-Ranges: bytes Date: Wed, 18 Jul 2018 08:33:37 GMT > On 18. Jul 2018, at 10:22, Romain Pelisse wrote: > > Hi all, > > Is there a unit inside HAL code base I could use to automate checking that the console is working properly after firing Wildfly? I've try to look for that myself, but i've been a bit confused by the code base I'm must confess. > > (I've kept it short, but feel free to ask for more context if you need to) > _______________________________________________ > 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/20180718/eff8c197/attachment.html From belaran at redhat.com Wed Jul 18 04:42:26 2018 From: belaran at redhat.com (Romain Pelisse) Date: Wed, 18 Jul 2018 10:42:26 +0200 Subject: [wildfly-dev] Healtchecking the Console using unit test In-Reply-To: <500EFEC4-7919-4C57-84FB-34B30739E646@redhat.com> References: <500EFEC4-7919-4C57-84FB-34B30739E646@redhat.com> Message-ID: Darn, I knew I should have been a bit more verbose! :) I would like something a bit more evolved. I'm no expert in HAL, but I've know webapps to return 200 while being utterly broken. I was hoping to run a small scenario, maybe something as stupid as trying to log in (even a failed attempt, returning the proper code would be nice). Is there no way to run a test from the suite standalone? (I've try the usual mvn -Dtest without success, but I also need to configure the testsuite to run against the proper instance) If you think Curl is the better way to achieve that, I have no issue with it. I assume we can also use it to interact with the ReST API, right? Thanks! On Wed, Jul 18, 2018 at 10:34 AM, Harald Pehl wrote: > You could try to use `curl --head http://localhost:9990/console/ > index.html` which should return something like > > HTTP/1.1 200 OK > Connection: keep-alive > Last-Modified: Fri, 13 Jul 2018 14:27:50 GMT > X-Frame-Options: SAMEORIGIN > Content-Length: 1288 > Content-Type: text/html > Accept-Ranges: bytes > Date: Wed, 18 Jul 2018 08:33:37 GMT > > > On 18. Jul 2018, at 10:22, Romain Pelisse wrote: > > Hi all, > > Is there a unit inside HAL code base I could use to automate checking that > the console is working properly after firing Wildfly? I've try to look for > that myself, but i've been a bit confused by the code base I'm must confess. > > (I've kept it short, but feel free to ask for more context if you need to) > _______________________________________________ > 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/20180718/2e9b9d2b/attachment.html From brian.stansberry at redhat.com Wed Jul 18 12:41:58 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 18 Jul 2018 11:41:58 -0500 Subject: [wildfly-dev] Healtchecking the Console using unit test In-Reply-To: References: <500EFEC4-7919-4C57-84FB-34B30739E646@redhat.com> Message-ID: I'm unclear on the desired architecture. You're asking for something in the HAL codebase itself, right? Not in WildFly. But to test most scenarios, including authentication, you need to have a running WildFly too, even though the HAL code you are testing is not the code that WildFly serves. Is that an accurate summary? On Wed, Jul 18, 2018 at 3:42 AM, Romain Pelisse wrote: > Darn, I knew I should have been a bit more verbose! :) I would like > something a bit more evolved. I'm no expert in HAL, but I've know webapps > to return 200 while being utterly broken. I was hoping to run a small > scenario, maybe something as stupid as trying to log in (even a failed > attempt, returning the proper code would be nice). Is there no way to run a > test from the suite standalone? > > (I've try the usual mvn -Dtest without success, but I also need to > configure the testsuite to run against the proper instance) > > If you think Curl is the better way to achieve that, I have no issue with > it. I assume we can also use it to interact with the ReST API, right? > > Thanks! > > > On Wed, Jul 18, 2018 at 10:34 AM, Harald Pehl wrote: > >> You could try to use `curl --head http://localhost:9990/console/ >> index.html` which should return something like >> >> HTTP/1.1 200 OK >> Connection: keep-alive >> Last-Modified: Fri, 13 Jul 2018 14:27:50 GMT >> X-Frame-Options: SAMEORIGIN >> Content-Length: 1288 >> Content-Type: text/html >> Accept-Ranges: bytes >> Date: Wed, 18 Jul 2018 08:33:37 GMT >> >> >> On 18. Jul 2018, at 10:22, Romain Pelisse wrote: >> >> Hi all, >> >> Is there a unit inside HAL code base I could use to automate checking >> that the console is working properly after firing Wildfly? I've try to look >> for that myself, but i've been a bit confused by the code base I'm must >> confess. >> >> (I've kept it short, but feel free to ask for more context if you need to) >> _______________________________________________ >> 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 Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180718/d0c5b87a/attachment.html From claudio at claudius.com.br Wed Jul 18 14:03:01 2018 From: claudio at claudius.com.br (Claudio Miranda) Date: Wed, 18 Jul 2018 15:03:01 -0300 Subject: [wildfly-dev] Healtchecking the Console using unit test In-Reply-To: References: <500EFEC4-7919-4C57-84FB-34B30739E646@redhat.com> Message-ID: On Wed, Jul 18, 2018 at 5:42 AM, Romain Pelisse wrote: > > If you think Curl is the better way to achieve that, I have no issue with > it. I assume we can also use it to interact with the ReST API, right? You can use curl to call operations or read resources, directly to the management interface. curl --digest -u admin:admin123@ -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"test-connection-in-pool","address":[{"subsystem: "datasources"},{"data-source":"ExampleDS"}]}' curl --digest -u admin:admin123@ -L 'http://localhost:9990/management/deployment/kitchensink.war?operation=resource&include-runtime=true' But if you want to test HAL itself, you can't do that with curl, because HAL relies on several javascript libraries that curl doesn't support (premises, fetch, etc.), there is also the CORS of the curl client host to wildfly management interface. -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From jmesnil at redhat.com Thu Jul 19 08:46:20 2018 From: jmesnil at redhat.com (Jeff Mesnil) Date: Thu, 19 Jul 2018 14:46:20 +0200 Subject: [wildfly-dev] WildFly Core Release Schedule Message-ID: <55021933-EF29-424F-A66A-D51DB655057E@redhat.com> As you know, WildFly has changed its release process to be more predictable and deliver time-boxed stable releases. One of the key component of WildFly is WildFly Core. It provides the ?kernel? of WildFly as well as some extensions and subsystems. The release process of WildFly is also impacting WildFly Core. I have written a wiki page to highlight the release schedule of WildFly Core https://github.com/wildfly/wildfly-core/wiki/WildFly-Core-Release-Schedule **** TL;DR, we release new versions of WildFly Core and integrate them WildFly every 2 weeks (on the 1st and 3rd wednesdays of every month). **** We can keep up on this time-boxed releases as we only merge features that are stable and tested according to the new release process. This should have low impact on ongoing development from contributors but let?s highlight some points: * At most, there will be a 2-week timeframe between a PR being merged in Core and being available in WildFly. If your code requires changes into the 2 projects, please take into account that buffer. * Some team (e.g. Elytron) work on several related PRs in parallel but want to have them deliver in a single WildFly Core release. If that?s the case, please mention this explicitly in the PR when it is submitted so we can flag it accordingly and wait until all related PRs are ready to be merged and delivered in the same Core release * We may have addition tags as we are closer to WildFly releases to deliver Beta, CR releases. We will communicate on this mailing list when we get closer to these dates. We are planning to deliver WildFly 14 in August. This means that: * Friday August 10th - PR for WildFly Core should be ready (all requirements are met, QE checks, community docs, etc.) * Monday August 13th - Feature freeze for WildFly Core 6.0.0 * Wednesday August 15th - Feature freeze for WildFly 14 * we only accept bug fixing after these dates * End of august - Final tag for WildFly 14 jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From thofman at redhat.com Thu Jul 19 10:24:54 2018 From: thofman at redhat.com (Tomas Hofman) Date: Thu, 19 Jul 2018 16:24:54 +0200 Subject: [wildfly-dev] RA subsystem: renaming "pool-name" attribute to "name" Message-ID: <3a09c13d-3833-fdb5-b798-240dc2f341cb@redhat.com> The and elements in resource adapters subsystem have "pool-name" attribute that looks like it isn't used for anything, which is misleading for users. It looks that "pool-name" attribute was intended for functionality that wasn't implemented. The attributes are only present in XML, and do not exist in management model. During resource creation the values are passed into service value objects (ModifiableAdminObject, ModifiableConnDef), but #getPoolName() methods are not called from anywhere. The attributes can't be simply removed because their values are used for resource addressing, e.g. /subsystem=resource-adapters/.../admin-objects=test-a-o:add(...) will produce so some "name" attribute is still needed. Unless you think that this is not worth having new schema version (or the intended functionality that requires "pool-name" attrs is planned to be implemented), I would create new XSD schema version with "pool-name" renamed to "name" and update the parser. I suppose the new XSD version should be 6.0, rather than 5.1, no matter how small the change. Also, AFAIK this change couldn't be backported to released product streams. The issue where this was raised is https://issues.jboss.org/browse/JBEAP-15023 -- Tomas Hofman Software Engineer, JBoss SET Red Hat From brian.stansberry at redhat.com Thu Jul 19 16:38:08 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 19 Jul 2018 15:38:08 -0500 Subject: [wildfly-dev] RA subsystem: renaming "pool-name" attribute to "name" In-Reply-To: <3a09c13d-3833-fdb5-b798-240dc2f341cb@redhat.com> References: <3a09c13d-3833-fdb5-b798-240dc2f341cb@redhat.com> Message-ID: So basically the issue here is that the xml attribute should be called 'name' instead of 'pool-name'? Sounds like a minor Enhancement not a major Bug. If there's much in the way of docs out there that use pool-name then the cost of changing it (wrong docs) may outweigh any benefit. On Thu, Jul 19, 2018 at 9:24 AM, Tomas Hofman wrote: > The and elements in resource > adapters > subsystem have "pool-name" attribute that looks like it isn't used for > anything, which is misleading for users. > > It looks that "pool-name" attribute was intended for functionality that > wasn't > implemented. The attributes are only present in XML, and do not exist in > management model. > > During resource creation the values are passed into service value objects > (ModifiableAdminObject, ModifiableConnDef), but #getPoolName() methods are > not > called from anywhere. > > The attributes can't be simply removed because their values are used for > resource addressing, e.g. > > /subsystem=resource-adapters/.../admin-objects=test-a-o:add(...) > > will produce > > > > so some "name" attribute is still needed. > > Unless you think that this is not worth having new schema version (or the > intended functionality that requires "pool-name" attrs is planned to be > implemented), I would create new XSD schema version with "pool-name" > renamed to > "name" and update the parser. I suppose the new XSD version should be 6.0, > rather than 5.1, no matter how small the change. > > Also, AFAIK this change couldn't be backported to released product streams. > > The issue where this was raised is https://issues.jboss.org/ > browse/JBEAP-15023 > > -- > Tomas Hofman > Software Engineer, JBoss SET > Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180719/f3e43dba/attachment.html From cfang at redhat.com Mon Jul 23 08:01:28 2018 From: cfang at redhat.com (Cheng Fang) Date: Mon, 23 Jul 2018 08:01:28 -0400 Subject: [wildfly-dev] Project JBeret Plans 2018-2019 Message-ID: I created the following draft planning document, including some high-level tasks we are or will be working on, and tentative dates: https://github.com/jberet/jsr352/wiki/JBeret-Roadmap-2018-2019 JBeret is a part of WildFly as the batch processing subsystem, and many JBeret users deploy batch applications to WildFly. So I thought it will be great to get feedback from WildFly community. Comments are welcome and much appreciated. Thank you, Cheng -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180723/2ef8847e/attachment.html From Boyd.Nolan at tylertech.com Wed Jul 25 21:18:00 2018 From: Boyd.Nolan at tylertech.com (Nolan, Boyd) Date: Thu, 26 Jul 2018 01:18:00 +0000 Subject: [wildfly-dev] Registering session activity in Wildfly Message-ID: Hello All, This may not be exactly the right forum / audience to ask this question, and if so please accept my apologies in advance. That being said, I need to understand what actions or events inside of Wildfly / Undertow are recognized as valid activity relating to the session timeout. I'm battling some issues in a web application where a user is doing legitimate actions via ajax that are being processed through wildfly, but they still end up getting their session terminated even though they are legitimately active. Is it a limited class or category of session event that is recognized as activity, which should result in resetting the timer for the session timeout? Does anyone know, or can you point me to the information that explains it? J. Boyd Nolan, P.E. Director of Technical Development Tyler Technologies, Inc. P: 214.593.6733 www.tylertech.com [Tyler Technologies] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180726/f59d1468/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 32768 bytes Desc: image001.png Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180726/f59d1468/attachment-0001.png From stuart.w.douglas at gmail.com Wed Jul 25 21:38:41 2018 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 26 Jul 2018 11:38:41 +1000 Subject: [wildfly-dev] Registering session activity in Wildfly In-Reply-To: References: Message-ID: It will only count as an event if something calls getSession(). If say you just request a static file or some other resource that does not use the session then it will not reset the session timeout. If you want to change this behaviour you could just write a filter that calls getSession(false) on every request. Stuart On Thu, Jul 26, 2018 at 11:22 AM Nolan, Boyd wrote: > Hello All, > > This may not be exactly the right forum / audience to ask this question, > and if so please accept my apologies in advance. That being said, I need to > understand what actions or events inside of Wildfly / Undertow are > recognized as valid activity relating to the session timeout. I?m battling > some issues in a web application where a user is doing legitimate actions > via ajax that are being processed through wildfly, but they still end up > getting their session terminated even though they are legitimately active. > Is it a limited class or category of session event that is recognized as > activity, which should result in resetting the timer for the session > timeout? > > > > Does anyone know, or can you point me to the information that explains it? > > > > > *J. Boyd Nolan, P.E.* > Director of Technical Development > Tyler Technologies, Inc. > > P: 214.593.6733 > > www.tylertech.com > > > > [image: Tyler Technologies] > _______________________________________________ > 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/20180726/81638aa9/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 32768 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180726/81638aa9/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 32768 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180726/81638aa9/attachment-0003.png From Boyd.Nolan at tylertech.com Wed Jul 25 21:49:41 2018 From: Boyd.Nolan at tylertech.com (Nolan, Boyd) Date: Thu, 26 Jul 2018 01:49:41 +0000 Subject: [wildfly-dev] Registering session activity in Wildfly In-Reply-To: References: Message-ID: Ah, perfect. I will give that a go. Thank you very much, Stuart. J. Boyd Nolan, P.E. Director of Technical Development P: 214.593.6733 www.tylertech.com From: Stuart Douglas Sent: Wednesday, July 25, 2018 20:39 To: Nolan, Boyd Cc: Wildfly Dev mailing list Subject: Re: [wildfly-dev] Registering session activity in Wildfly It will only count as an event if something calls getSession(). If say you just request a static file or some other resource that does not use the session then it will not reset the session timeout. If you want to change this behaviour you could just write a filter that calls getSession(false) on every request. Stuart On Thu, Jul 26, 2018 at 11:22 AM Nolan, Boyd > wrote: Hello All, This may not be exactly the right forum / audience to ask this question, and if so please accept my apologies in advance. That being said, I need to understand what actions or events inside of Wildfly / Undertow are recognized as valid activity relating to the session timeout. I?m battling some issues in a web application where a user is doing legitimate actions via ajax that are being processed through wildfly, but they still end up getting their session terminated even though they are legitimately active. Is it a limited class or category of session event that is recognized as activity, which should result in resetting the timer for the session timeout? Does anyone know, or can you point me to the information that explains it? J. Boyd Nolan, P.E. Director of Technical Development Tyler Technologies, Inc. P: 214.593.6733 www.tylertech.com [Tyler Technologies] _______________________________________________ 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/20180726/44e86fb6/attachment.html From Boyd.Nolan at tylertech.com Wed Jul 25 22:05:19 2018 From: Boyd.Nolan at tylertech.com (Nolan, Boyd) Date: Thu, 26 Jul 2018 02:05:19 +0000 Subject: [wildfly-dev] Registering session activity in Wildfly In-Reply-To: References: Message-ID: Stuart, A quick question just to verify?are you talking about the getSession method exposed on the HttpServletRequest object? J. Boyd Nolan, P.E. Director of Technical Development P: 214.593.6733 www.tylertech.com From: Nolan, Boyd Sent: Wednesday, July 25, 2018 20:50 To: 'Stuart Douglas' Cc: Wildfly Dev mailing list Subject: RE: [wildfly-dev] Registering session activity in Wildfly Ah, perfect. I will give that a go. Thank you very much, Stuart. J. Boyd Nolan, P.E. Director of Technical Development P: 214.593.6733 www.tylertech.com From: Stuart Douglas > Sent: Wednesday, July 25, 2018 20:39 To: Nolan, Boyd > Cc: Wildfly Dev mailing list > Subject: Re: [wildfly-dev] Registering session activity in Wildfly It will only count as an event if something calls getSession(). If say you just request a static file or some other resource that does not use the session then it will not reset the session timeout. If you want to change this behaviour you could just write a filter that calls getSession(false) on every request. Stuart On Thu, Jul 26, 2018 at 11:22 AM Nolan, Boyd > wrote: Hello All, This may not be exactly the right forum / audience to ask this question, and if so please accept my apologies in advance. That being said, I need to understand what actions or events inside of Wildfly / Undertow are recognized as valid activity relating to the session timeout. I?m battling some issues in a web application where a user is doing legitimate actions via ajax that are being processed through wildfly, but they still end up getting their session terminated even though they are legitimately active. Is it a limited class or category of session event that is recognized as activity, which should result in resetting the timer for the session timeout? Does anyone know, or can you point me to the information that explains it? J. Boyd Nolan, P.E. Director of Technical Development Tyler Technologies, Inc. P: 214.593.6733 www.tylertech.com [Tyler Technologies] _______________________________________________ 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/20180726/ad334d6a/attachment-0001.html From thofman at redhat.com Mon Jul 30 04:32:07 2018 From: thofman at redhat.com (Tomas Hofman) Date: Mon, 30 Jul 2018 10:32:07 +0200 Subject: [wildfly-dev] RA subsystem: renaming "pool-name" attribute to "name" In-Reply-To: References: <3a09c13d-3833-fdb5-b798-240dc2f341cb@redhat.com> Message-ID: Yes, that's what I believe should be done. Adding also Tomasz and Tom :). I'm yet to asses the impact on documentation, by my feeling from my initial investigation was that I didn't found very many documents dealing with this. Am I correct in thinking that if the new parser is able to parse the old config version, no other migration work is needed? Tomas On 19/07/18 22:38, Brian Stansberry wrote: > So basically the issue here is that the xml attribute should be called 'name' > instead of 'pool-name'? > > Sounds like a minor Enhancement not a major Bug. If there's much in the way of > docs out there that use pool-name then the cost of changing it (wrong docs) may > outweigh any benefit. > > On Thu, Jul 19, 2018 at 9:24 AM, Tomas Hofman > wrote: > > The and elements in resource adapters > subsystem have "pool-name" attribute that looks like it isn't used for > anything, which is misleading for users. > > It looks that "pool-name" attribute was intended for functionality that wasn't > implemented. The attributes are only present in XML, and do not exist in > management model. > > During resource creation the values are passed into service value objects > (ModifiableAdminObject, ModifiableConnDef), but #getPoolName() methods are not > called from anywhere. > > The attributes can't be simply removed because their values are used for > resource addressing, e.g. > > ? ?/subsystem=resource-adapters/.../admin-objects=test-a-o:add(...) > > will produce > > ? ? > > so some "name" attribute is still needed. > > Unless you think that this is not worth having new schema version (or the > intended functionality that requires "pool-name" attrs is planned to be > implemented), I would create new XSD schema version with "pool-name" > renamed to > "name" and update the parser. I suppose the new XSD version should be 6.0, > rather than 5.1, no matter how small the change. > > Also, AFAIK this change couldn't be backported to released product streams. > > The issue where this was raised is > https://issues.jboss.org/browse/JBEAP-15023 > > > -- > Tomas Hofman > Software Engineer, JBoss SET > Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat -- Tomas Hofman Software Engineer, JBoss SET Red Hat From george.labuschagne at megchem.co.za Mon Jul 30 08:14:06 2018 From: george.labuschagne at megchem.co.za (George Labuschagne) Date: Mon, 30 Jul 2018 14:14:06 +0200 Subject: [wildfly-dev] X/Post from User List: After upgrading to JSF 2.3 - WildFly 13 Java EE 8 preview mode, iOS and Mac OSX fails to load HTTPS site getting UT005085 errors. Message-ID: <009601d427fe$cfd13dc0$6f73b940$@megchem.co.za> Good day all I hope this is not frowned upon; if it is, sincerest apologies. I posted to the users list but perhaps there is a better chance getting an answer from the development list? Below is a copy and paste of the user list email chain so far: Good day According to this SO question's comments: https://stackoverflow.com/questions/51484592/site-rendering-broken-on-mobile -after-moving-to-jdk-10-and-jsf-2-3 and this error for Payara: https://github.com/payara/Payara/issues/2625 It seems to be a problem that has to do with HTTP/2 PUSH So why is this only effecting iOS and Mac OSX? And any suggestions on how to resolve this issue? Kind regards, George From: jboss-user-bounces at lists.jboss.org > On Behalf Of George Labuschagne Sent: Monday, 30 July 2018 11:29 To: 'The JBoss User main mailing list' > Subject: Re: [jboss-user] After upgrading to JSF 2.3 - WildFly 13 Java EE 8 preview mode, iOS and Mac OSX fails to load HTTPS site getting UT005085 errors. Good day I was able to get onto the local LAN with my phone and connected to a normal HTTP session from my iPhone. Works 100%, fast, beautifully rendered with no warnings or error in any logs. Kind regards, George From: jboss-user-bounces at lists.jboss.org > On Behalf Of George Labuschagne Sent: Monday, 30 July 2018 11:02 To: jboss-user at lists.jboss.org Subject: [jboss-user] After upgrading to JSF 2.3 - WildFly 13 Java EE 8 preview mode, iOS and Mac OSX fails to load HTTPS site getting UT005085 errors. Good day We are using WildFly 13 in Java EE 8 preview mode with TLS enabled for HTTPS However, since updating the POM file (contents included below) and a few places in the code itself, we are able to run JSF 2.3.5.SP1 with PrimeFaces 6.2.7 and OmniFaces 3.1 on all devices and browser combinations apart from Apple products without any issue. When connecting with a non Apple based device to the site, there are zero warnings or errors in the log file. Connecting using an Apple based device fails to load the site correctly as the log file (relevant snippets included below) shows lots of resources failing to load. The weird thing is that this only happens with iOS (even on iOS 12 beta 3) and latest Mac OSX (don't have older version of Mac OSX to test with). I logged this as a bug on Apple's site but it is my personal opinion based on past experience that the chances of getting a speedy reply from Apple on this is slim. The error log starts with these long one line errors: /* error log snippet line 1 2018-07-30 09:09:18,741 ERROR [io.undertow] (default task-3078) UT005085: Connection io.undertow.server.protocol.http2.Http2ServerConnection at 7e55834 for exchange HttpServerExchange{ GET /edsnext/javax.faces.resource/omnifaces.js.xhtml request {accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], accept-language=[en-us], :authority=[edsnext.megchemsa.com:62543], accept-encoding=[gzip, deflate], :path=[/edsnext/javax.faces.resource/omnifaces.js.xhtml?ln=omnifaces&v=3.1], user-agent=[Mozilla/5.0 (iPhone; CPU iPhone OS 12_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Mobile/15E148 Safari/604.1], :scheme=[https], cookie=[JSESSIONID=U5X9u-A83bccAnpA1XUnEFzmngqI9iDJwuIiU_Qo], :method=[GET], Referer=[https://edsnext.megchemsa.com:62543/edsnext/], upgrade-insecure-requests=[1], Host=[edsnext.megchemsa.com:62543]} response {Expires=[Mon, 30 Jul 2018 09:57:18 GMT], ETag=[W/"5933-1532705069245"], Last-Modified=[Fri, 27 Jul 2018 15:24:29 GMT], Set-Cookie=[JSESSIONID=U5X9u-A83bccAnpA1XUnEFzmngqI9iDJwuIiU_Qo.edsnext; path=/edsnext], Content-Type=[application/javascript], Date=[Mon, 30 Jul 2018 07:09:18 GMT], :status=[200]}} was not closed cleanly, forcibly closing connection /* end of error log snippet line 1 It iterates over all the javax.faces.resources, giving one long error line per resource. Then it ends with long PrimeFaces warnings starting with: /* start of PrimeFaces warnings 2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3091) JSF1064: Unable to find or serve resource, fa/fontawesome-webfont.eot, from library, primefaces. 2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3084) JSF1064: Unable to find or serve resource, fonts/lato-regular-webfont.svg, from library, primefaces-omega. 2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3082) JSF1064: Unable to find or serve resource, fa/fontawesome-webfont.ttf, from library, primefaces. 2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3100) JSF1064: Unable to find or serve resource, fa/fontawesome-webfont.svg, from library, primefaces. 2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3103) JSF1064: Unable to find or serve resource, fonts/lato-bold-webfont.svg, from library, primefaces-omega. 2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3091) : java.nio.channels.ClosedChannelException /* end of PrimeFaces warnings This is followed by a stack trace dump from PrimeFaces But like I said previously, this only happens when browsing via iOS or Mac OSX. CentOS 7.5 with Chrome latest and FireFox Developer Edition latest as well as Windows 10 with all browsers works 100% no warnings or errors. Kind regards, George /* POM File 4.0.0 com.domain app 1.0-SNAPSHOT war ${project.artifactId} EDSNext http://edsnext.headoffice.megchem.co.za UTF-8 UTF-8 1.8 1.8 false JBoss public-jboss http://repository.jboss.org/nexus/content/groups/public-jboss/ java.net-maven2-SNAPSHOT-repository Java.net SNAPSHOT-Repository for Maven https://maven.java.net/content/repositories/snapshots/ default java.net-maven2-repository Java.net Repository for Maven https://maven.java.net/content/repositories/releases/ default oss.sonatype.org https://oss.sonatype.org/content/repositories/snapshots/ bintray-snapshot libs-snapshot http://oss.jfrog.org/artifactory/libs-snapshot false bintray-deluan-maven bintray http://dl.bintray.com/deluan/maven org.wildfly wildfly-spec-api 13.0.0.Final pom provided org.wildfly.bom wildfly-javaee7-with-tools provided pom 13.0.0.Final org.hibernate hibernate-core 5.3.1.Final provided org.hibernate.common hibernate-commons-annotations 5.0.2.Final provided org.hibernate.validator hibernate-validator 6.0.10.Final provided javax.persistence javax.persistence-api 2.2 org.hibernate hibernate-search-orm 5.5.8.Final provided org.jboss.spec.javax.faces jboss-jsf-api_2.3_spec 2.3.5.SP1 provided com.sun.faces jsf-impl 2.3.5.SP1 provided org.jboss.spec.javax.el jboss-el-api_3.0_spec 1.0.11.Final javax.el javax.el-api 3.0.1-b06 net.sf.jasperreports jasperreports 6.6.0 org.apache.httpcomponents httpclient 4.5.6 org.apache.httpcomponents httpcore 4.4.10 org.apache.shiro shiro-core 1.4.0 org.apache.shiro shiro-web 1.4.0 org.apache.shiro shiro-ehcache 1.4.0 org.primefaces primefaces 6.2.7 org.primefaces.extensions primefaces-extensions 6.2.7 org.omnifaces omnifaces 3.1 org.postgresql postgresql 42.2.4 org.apache.logging.log4j log4j-api 2.11.0 org.apache.logging.log4j log4j-core 2.11.0 org.apache.logging.log4j log4j-web 2.11.0 org.apache.logging.log4j log4j-slf4j-impl 2.11.0 com.intellij annotations 12.0 org.apache.commons commons-text 1.4 org.apache.poi poi 3.17 org.apache.poi poi-ooxml 3.17 org.apache.poi poi-scratchpad 3.17 org.apache.commons commons-lang3 3.7 commons-fileupload commons-fileupload 1.3.3 commons-io commons-io 2.6 org.projectlombok lombok 1.18.0 junit junit 4.12 test org.dbunit dbunit 2.5.4 test org.jboss.arquillian.junit arquillian-junit-container 1.4.0.Final test org.jboss.arquillian.extension arquillian-persistence-dbunit 1.0.0.Alpha7 test org.jboss.shrinkwrap.resolver shrinkwrap-resolver-impl-maven-archive 3.1.3 org.jboss.arquillian.graphene graphene-webdriver 2.3.2 pom test com.google.guava guava 25.1-jre test org.jboss.arquillian arquillian-bom 1.4.0.Final pom import org.jboss.arquillian.extension arquillian-drone-bom 2.5.1 pom import ${project.artifactId} org.apache.maven.plugins maven-enforcer-plugin 3.0.0-M2 enforce-maven enforce 3.3.9 /* end of POM file Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and automatically archived by Mimecast SA (Pty) Ltd, an innovator in Software as a Service (SaaS) for business. Mimecast Unified Email Management (UEM) offers email continuity, security, archiving and compliance with all current legislation. To find out more, visit http://www.mimecast.co.za/uem. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180730/279887b1/attachment-0001.html From belaran at redhat.com Mon Jul 30 09:36:48 2018 From: belaran at redhat.com (Romain Pelisse) Date: Mon, 30 Jul 2018 15:36:48 +0200 Subject: [wildfly-dev] File permissions discrepancy between zip and rpms installation (part2) Message-ID: Hi all, a while back, we've discussed the discrepancies in file rights between the zipfile produced for Wildfly and the one build to be embedded into a RPM (see issue JBEAP-12374[1] and WFLY-9574[2]). It turned out that the root reason for those discrepancies was due to the system being used for building - Wildfly being built on MacOS X and the EAP being built on Fedora. This means that, the default privileges attributed to some files, on MacOS X, differed to the one attributed on Fedora. Working on the previously mentioned issues, I have already reduced the number of discrapencies. However, a few remains are described, in detail, on the new issue (JBEAP-12374). For each type of discrepancy, I have a proposal on how we should fix it. The only thing I need now is agreement from a few core developer (or disagreement) so that I can implement (or not) those proposal (or alternatively, asked the RPM team to set those discrepancies to be "expected"). So if you have the time to take a look and say "ay" or "nay", it will be awesome :) [1] https://issues.jboss.org/browse/JBEAP-12374 [2] https://issues.jboss.org/browse/WFLY-9574 [3] https://issues.jboss.org/browse/JBEAP-14922 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180730/ca6f1bdc/attachment.html From brian.stansberry at redhat.com Mon Jul 30 16:45:12 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 30 Jul 2018 15:45:12 -0500 Subject: [wildfly-dev] RA subsystem: renaming "pool-name" attribute to "name" In-Reply-To: References: <3a09c13d-3833-fdb5-b798-240dc2f341cb@redhat.com> Message-ID: On Mon, Jul 30, 2018 at 3:32 AM, Tomas Hofman wrote: > Yes, that's what I believe should be done. > > Adding also Tomasz and Tom :). > > I'm yet to asses the impact on documentation, by my feeling from my > initial investigation was that I didn't found very many documents dealing > with this. > Please check with the Teiid folks, as Teiid heavily uses this subsystem. > > Am I correct in thinking that if the new parser is able to parse the old > config version, no other migration work is needed? > Right, unless Stefano wants the parser for the new schema version to be forgiving and allow the old attribute. > Tomas > > On 19/07/18 22:38, Brian Stansberry wrote: > >> So basically the issue here is that the xml attribute should be called >> 'name' instead of 'pool-name'? >> >> Sounds like a minor Enhancement not a major Bug. If there's much in the >> way of docs out there that use pool-name then the cost of changing it >> (wrong docs) may outweigh any benefit. >> >> On Thu, Jul 19, 2018 at 9:24 AM, Tomas Hofman > > wrote: >> >> The and elements in resource >> adapters >> subsystem have "pool-name" attribute that looks like it isn't used for >> anything, which is misleading for users. >> >> It looks that "pool-name" attribute was intended for functionality >> that wasn't >> implemented. The attributes are only present in XML, and do not exist >> in >> management model. >> >> During resource creation the values are passed into service value >> objects >> (ModifiableAdminObject, ModifiableConnDef), but #getPoolName() >> methods are not >> called from anywhere. >> >> The attributes can't be simply removed because their values are used >> for >> resource addressing, e.g. >> >> /subsystem=resource-adapters/.../admin-objects=test-a-o:add(...) >> >> will produce >> >> >> >> so some "name" attribute is still needed. >> >> Unless you think that this is not worth having new schema version (or >> the >> intended functionality that requires "pool-name" attrs is planned to >> be >> implemented), I would create new XSD schema version with "pool-name" >> renamed to >> "name" and update the parser. I suppose the new XSD version should be >> 6.0, >> rather than 5.1, no matter how small the change. >> >> Also, AFAIK this change couldn't be backported to released product >> streams. >> >> The issue where this was raised is >> https://issues.jboss.org/browse/JBEAP-15023 >> >> >> -- Tomas Hofman >> Software Engineer, JBoss SET >> Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> >> >> -- >> Brian Stansberry >> Manager, Senior Principal Software Engineer >> Red Hat >> > > -- > Tomas Hofman > Software Engineer, JBoss SET > Red Hat > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180730/f577d925/attachment.html From george.labuschagne at megchem.co.za Tue Jul 31 01:12:14 2018 From: george.labuschagne at megchem.co.za (George Labuschagne) Date: Tue, 31 Jul 2018 07:12:14 +0200 Subject: [wildfly-dev] X/Post from User List: After upgrading to JSF 2.3 - WildFly 13 Java EE 8 preview mode - iOS and Mac OSX fails to load HTTPS site getting UT005085 errors. Message-ID: <002301d4288d$0b2b3db0$2181b910$@megchem.co.za> Good day For now disabling HTTP/2 resolved the issue. https://developer.jboss.org/message/984406#984406 Hopefully this will be resolved in WildFly 14? Kind regards, George From: wildfly-dev-bounces at lists.jboss.org On Behalf Of George Labuschagne Sent: Monday, 30 July 2018 14:14 To: wildfly-dev at lists.jboss.org Subject: [wildfly-dev] X/Post from User List: After upgrading to JSF 2.3 - WildFly 13 Java EE 8 preview mode, iOS and Mac OSX fails to load HTTPS site getting UT005085 errors. Good day all I hope this is not frowned upon; if it is, sincerest apologies. I posted to the users list but perhaps there is a better chance getting an answer from the development list? Below is a copy and paste of the user list email chain so far: Good day According to this SO question?s comments: https://stackoverflow.com/questions/51484592/site-rendering-broken-on-mobile-after-moving-to-jdk-10-and-jsf-2-3 and this error for Payara: https://github.com/payara/Payara/issues/2625 It seems to be a problem that has to do with HTTP/2 PUSH So why is this only effecting iOS and Mac OSX? And any suggestions on how to resolve this issue? Kind regards, George From: jboss-user-bounces at lists.jboss.org > On Behalf Of George Labuschagne Sent: Monday, 30 July 2018 11:29 To: 'The JBoss User main mailing list' > Subject: Re: [jboss-user] After upgrading to JSF 2.3 - WildFly 13 Java EE 8 preview mode, iOS and Mac OSX fails to load HTTPS site getting UT005085 errors. Good day I was able to get onto the local LAN with my phone and connected to a normal HTTP session from my iPhone. Works 100%, fast, beautifully rendered with no warnings or error in any logs. Kind regards, George From: jboss-user-bounces at lists.jboss.org > On Behalf Of George Labuschagne Sent: Monday, 30 July 2018 11:02 To: jboss-user at lists.jboss.org Subject: [jboss-user] After upgrading to JSF 2.3 - WildFly 13 Java EE 8 preview mode, iOS and Mac OSX fails to load HTTPS site getting UT005085 errors. Good day We are using WildFly 13 in Java EE 8 preview mode with TLS enabled for HTTPS However, since updating the POM file (contents included below) and a few places in the code itself, we are able to run JSF 2.3.5.SP1 with PrimeFaces 6.2.7 and OmniFaces 3.1 on all devices and browser combinations apart from Apple products without any issue. When connecting with a non Apple based device to the site, there are zero warnings or errors in the log file. Connecting using an Apple based device fails to load the site correctly as the log file (relevant snippets included below) shows lots of resources failing to load. The weird thing is that this only happens with iOS (even on iOS 12 beta 3) and latest Mac OSX (don?t have older version of Mac OSX to test with). I logged this as a bug on Apple?s site but it is my personal opinion based on past experience that the chances of getting a speedy reply from Apple on this is slim. The error log starts with these long one line errors: /* error log snippet line 1 2018-07-30 09:09:18,741 ERROR [io.undertow] (default task-3078) UT005085: Connection io.undertow.server.protocol.http2.Http2ServerConnection at 7e55834 for exchange HttpServerExchange{ GET /edsnext/javax.faces.resource/omnifaces.js.xhtml request {accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], accept-language=[en-us], :authority=[edsnext.megchemsa.com:62543], accept-encoding=[gzip, deflate], :path=[/edsnext/javax.faces.resource/omnifaces.js.xhtml?ln=omnifaces&v=3.1], user-agent=[Mozilla/5.0 (iPhone; CPU iPhone OS 12_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Mobile/15E148 Safari/604.1], :scheme=[https], cookie=[JSESSIONID=U5X9u-A83bccAnpA1XUnEFzmngqI9iDJwuIiU_Qo], :method=[GET], Referer=[https://edsnext.megchemsa.com:62543/edsnext/], upgrade-insecure-requests=[1], Host=[edsnext.megchemsa.com:62543]} response {Expires=[Mon, 30 Jul 2018 09:57:18 GMT], ETag=[W/"5933-1532705069245"], Last-Modified=[Fri, 27 Jul 2018 15:24:29 GMT], Set-Cookie=[JSESSIONID=U5X9u-A83bccAnpA1XUnEFzmngqI9iDJwuIiU_Qo.edsnext; path=/edsnext], Content-Type=[application/javascript], Date=[Mon, 30 Jul 2018 07:09:18 GMT], :status=[200]}} was not closed cleanly, forcibly closing connection /* end of error log snippet line 1 It iterates over all the javax.faces.resources, giving one long error line per resource. Then it ends with long PrimeFaces warnings starting with: /* start of PrimeFaces warnings 2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3091) JSF1064: Unable to find or serve resource, fa/fontawesome-webfont.eot, from library, primefaces. 2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3084) JSF1064: Unable to find or serve resource, fonts/lato-regular-webfont.svg, from library, primefaces-omega. 2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3082) JSF1064: Unable to find or serve resource, fa/fontawesome-webfont.ttf, from library, primefaces. 2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3100) JSF1064: Unable to find or serve resource, fa/fontawesome-webfont.svg, from library, primefaces. 2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3103) JSF1064: Unable to find or serve resource, fonts/lato-bold-webfont.svg, from library, primefaces-omega. 2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3091) : java.nio.channels.ClosedChannelException /* end of PrimeFaces warnings This is followed by a stack trace dump from PrimeFaces But like I said previously, this only happens when browsing via iOS or Mac OSX? CentOS 7.5 with Chrome latest and FireFox Developer Edition latest as well as Windows 10 with all browsers works 100% no warnings or errors. Kind regards, George /* POM File 4.0.0 com.domain app 1.0-SNAPSHOT war ${project.artifactId} EDSNext http://edsnext.headoffice.megchem.co.za UTF-8 UTF-8 1.8 1.8 false JBoss public-jboss http://repository.jboss.org/nexus/content/groups/public-jboss/ java.net-maven2-SNAPSHOT-repository Java.net SNAPSHOT-Repository for Maven https://maven.java.net/content/repositories/snapshots/ default java.net-maven2-repository Java.net Repository for Maven https://maven.java.net/content/repositories/releases/ default oss.sonatype.org https://oss.sonatype.org/content/repositories/snapshots/ bintray-snapshot libs-snapshot http://oss.jfrog.org/artifactory/libs-snapshot false bintray-deluan-maven bintray http://dl.bintray.com/deluan/maven org.wildfly wildfly-spec-api 13.0.0.Final pom provided org.wildfly.bom wildfly-javaee7-with-tools provided pom 13.0.0.Final org.hibernate hibernate-core 5.3.1.Final provided org.hibernate.common hibernate-commons-annotations 5.0.2.Final provided org.hibernate.validator hibernate-validator 6.0.10.Final provided javax.persistence javax.persistence-api 2.2 org.hibernate hibernate-search-orm 5.5.8.Final provided org.jboss.spec.javax.faces jboss-jsf-api_2.3_spec 2.3.5.SP1 provided com.sun.faces jsf-impl 2.3.5.SP1 provided org.jboss.spec.javax.el jboss-el-api_3.0_spec 1.0.11.Final javax.el javax.el-api 3.0.1-b06 net.sf.jasperreports jasperreports 6.6.0 org.apache.httpcomponents httpclient 4.5.6 org.apache.httpcomponents httpcore 4.4.10 org.apache.shiro shiro-core 1.4.0 org.apache.shiro shiro-web 1.4.0 org.apache.shiro shiro-ehcache 1.4.0 org.primefaces primefaces 6.2.7 org.primefaces.extensions primefaces-extensions 6.2.7 org.omnifaces omnifaces 3.1 org.postgresql postgresql 42.2.4 org.apache.logging.log4j log4j-api 2.11.0 org.apache.logging.log4j log4j-core 2.11.0 org.apache.logging.log4j log4j-web 2.11.0 org.apache.logging.log4j log4j-slf4j-impl 2.11.0 com.intellij annotations 12.0 org.apache.commons commons-text 1.4 org.apache.poi poi 3.17 org.apache.poi poi-ooxml 3.17 org.apache.poi poi-scratchpad 3.17 org.apache.commons commons-lang3 3.7 commons-fileupload commons-fileupload 1.3.3 commons-io commons-io 2.6 org.projectlombok lombok 1.18.0 junit junit 4.12 test org.dbunit dbunit 2.5.4 test org.jboss.arquillian.junit arquillian-junit-container 1.4.0.Final test org.jboss.arquillian.extension arquillian-persistence-dbunit 1.0.0.Alpha7 test org.jboss.shrinkwrap.resolver shrinkwrap-resolver-impl-maven-archive 3.1.3 org.jboss.arquillian.graphene graphene-webdriver 2.3.2 pom test com.google.guava guava 25.1-jre test org.jboss.arquillian arquillian-bom 1.4.0.Final pom import org.jboss.arquillian.extension arquillian-drone-bom 2.5.1 pom import ${project.artifactId} org.apache.maven.plugins maven-enforcer-plugin 3.0.0-M2 enforce-maven enforce 3.3.9 /* end of POM file Disclaimer The content of this e-mail message and all attachments thereto (`this message`) does not necessarily reflect the views of MegChem (Pty) Ltd (`MegChem`). Before acting on the contents thereof, the recipient should verify that the originator has the appropriate delegated authority. In the event that this message has not been appropriately authorised in terms of MegChem`s delegation of authority, or in the event of the personal usage of MegChem`s e-mail facility, MegChem will not be liable for the contents of this message. 1. This message may contain information which is confidential, private or privileged in nature and subject to legal privilege. If you are not the intended recipient you may not peruse, use, disseminate, distribute or copy this message or its attachments. Please notify the sender immediately by e-mail, facsimile or telephone and thereafter return and or destroy this original message. 2. Please note that the recipient must scan this message and any attachments for viruses and the like. MegChem accepts no liability, damage or expense resulting directly or indirectly from the access of any message or it`s attachments or the use thereof. 3. MegChem reserves the right to monitor, read, filter, block, delete, use and act upon any incoming or outgoing message or it`s attachments sent or received by the employee, including hyperlinks in such message attachments and files copied or saved, automatically or by the employee on MegChem`s equipment. 4. Please report email abuse / misuse to mailabuse at megchem.co.za This email has been scanned for viruses and malware, and automatically archived by Mimecast SA (Pty) Ltd, an innovator in Software as a Service (SaaS) for business. Mimecast Unified Email Management ? (UEM) offers email continuity, security, archiving and compliance with all current legislation. To find out more, contact Mimecast . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180731/124cf86d/attachment-0001.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Untitled attachment 00158.txt Url: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180731/124cf86d/attachment-0001.txt From jperkins at redhat.com Tue Jul 31 12:24:15 2018 From: jperkins at redhat.com (James Perkins) Date: Tue, 31 Jul 2018 09:24:15 -0700 Subject: [wildfly-dev] File permissions discrepancy between zip and rpms installation (part2) In-Reply-To: References: Message-ID: I don't think it's an OS issue TBH. I just build WildFly locally on Fedora 28 and in some cases have different permissions than either distribution. If anything I think we'd need to analyze the directory structure and choose the appropriate permissions rather than trying to match them to a distribution. I do think it makes sense to have something consistent. Having the permissions depend on who's releasing seems a bit of an issue. On Mon, Jul 30, 2018 at 6:40 AM Romain Pelisse wrote: > Hi all, > > a while back, we've discussed the discrepancies in file rights between the > zipfile produced for Wildfly and the one build to be embedded into a RPM > (see issue JBEAP-12374[1] and WFLY-9574[2]). It turned out that the root > reason for those discrepancies was due to the system being used for > building - Wildfly being built on MacOS X and the EAP being built on > Fedora. This means that, the default privileges attributed to some files, > on MacOS X, differed to the one attributed on Fedora. > > Working on the previously mentioned issues, I have already reduced the > number of discrapencies. However, a few remains are described, in detail, > on the new issue (JBEAP-12374). For each type of discrepancy, I have a > proposal on how we should fix it. > > The only thing I need now is agreement from a few core developer (or > disagreement) so that I can implement (or not) those proposal (or > alternatively, asked the RPM team to set those discrepancies to be > "expected"). > > So if you have the time to take a look and say "ay" or "nay", it will be > awesome :) > > [1] https://issues.jboss.org/browse/JBEAP-12374 > [2] https://issues.jboss.org/browse/WFLY-9574 > [3] https://issues.jboss.org/browse/JBEAP-14922 > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180731/fc933c72/attachment.html From thofman at redhat.com Tue Jul 31 13:38:31 2018 From: thofman at redhat.com (Tomas Hofman) Date: Tue, 31 Jul 2018 19:38:31 +0200 Subject: [wildfly-dev] RA subsystem: renaming "pool-name" attribute to "name" In-Reply-To: References: <3a09c13d-3833-fdb5-b798-240dc2f341cb@redhat.com> Message-ID: I guess that's Steven Hawkins? Hello Steven, we are considering renaming "pool-name" attribute to "name" in and elements of the resource-adapters subsystem in Wildfly/EAP. These attributes only exists in the XML (standalone.xml, domain.xml), aren't accessible in the management model apart from their values being used in resource addresses. E.g. would be accessed in CLI as /subsystem=resource-adapters/resource-adapter=test/admin-objects=test-a-o So the only thing that would change is the XML attribute "pool-name" being renamed to "name". Do you see it as a complication from TEIID point of view, or do you know who could answer that? Thanks, Tomas On 30/07/18 22:45, Brian Stansberry wrote: > > > On Mon, Jul 30, 2018 at 3:32 AM, Tomas Hofman > wrote: > > Yes, that's what I believe should be done. > > Adding also Tomasz and Tom :). > > I'm yet to asses the impact on documentation, by my feeling from my initial > investigation was that I didn't found very many documents dealing with this. > > > Please check with the Teiid folks, as Teiid heavily uses this subsystem. > > > Am I correct in thinking that if the new parser is able to parse the old > config version, no other migration work is needed? > > > Right, unless Stefano wants the parser for the new schema version to be > forgiving and allow the old attribute. > > > Tomas > > On 19/07/18 22:38, Brian Stansberry wrote: > > So basically the issue here is that the xml attribute should be called > 'name' instead of 'pool-name'? > > Sounds like a minor Enhancement not a major Bug. If there's much in the > way of docs out there that use pool-name then the cost of changing it > (wrong docs) may outweigh any benefit. > > On Thu, Jul 19, 2018 at 9:24 AM, Tomas Hofman >> wrote: > > ? ? The and elements in > resource adapters > ? ? subsystem have "pool-name" attribute that looks like it isn't used for > ? ? anything, which is misleading for users. > > ? ? It looks that "pool-name" attribute was intended for functionality > that wasn't > ? ? implemented. The attributes are only present in XML, and do not > exist in > ? ? management model. > > ? ? During resource creation the values are passed into service value > objects > ? ? (ModifiableAdminObject, ModifiableConnDef), but #getPoolName() > methods are not > ? ? called from anywhere. > > ? ? The attributes can't be simply removed because their values are > used for > ? ? resource addressing, e.g. > > ? ? ?? ?/subsystem=resource-adapters/.../admin-objects=test-a-o:add(...) > > ? ? will produce > > ? ? ?? ? > > ? ? so some "name" attribute is still needed. > > ? ? Unless you think that this is not worth having new schema version > (or the > ? ? intended functionality that requires "pool-name" attrs is planned > to be > ? ? implemented), I would create new XSD schema version with "pool-name" > ? ? renamed to > ? ? "name" and update the parser. I suppose the new XSD version should > be 6.0, > ? ? rather than 5.1, no matter how small the change. > > ? ? Also, AFAIK this change couldn't be backported to released product > streams. > > ? ? The issue where this was raised is > https://issues.jboss.org/browse/JBEAP-15023 > > ? ? > > > ? ? --? ? ?Tomas Hofman > ? ? Software Engineer, JBoss SET > ? ? Red Hat > ? ? _______________________________________________ > ? ? wildfly-dev mailing list > wildfly-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > ? ? > > > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat > > > -- > Tomas Hofman > Software Engineer, JBoss SET > Red Hat > > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat -- Tomas Hofman Software Engineer, JBoss SET Red Hat From emartins at redhat.com Tue Jul 31 15:13:02 2018 From: emartins at redhat.com (Eduardo Martins) Date: Tue, 31 Jul 2018 20:13:02 +0100 Subject: [wildfly-dev] RA subsystem: renaming "pool-name" attribute to "name" In-Reply-To: References: <3a09c13d-3833-fdb5-b798-240dc2f341cb@redhat.com> Message-ID: <631F7116-F5A3-4721-93B6-1D0CA8FCC939@redhat.com> Such cosmetic change would require to be documented in migration guide, i.e. effort from Docs and QE teams, and the old schema would need to be supported too, i.e. effort from Dev to translate old to new. And that would be the optimistic scenario, where user doesn?t need to change configs, i.e. no Dev effort for the migration tool? ?E > On 31 Jul 2018, at 18:38, Tomas Hofman wrote: > > I guess that's Steven Hawkins? > > Hello Steven, > > we are considering renaming "pool-name" attribute to "name" in > and elements of the resource-adapters subsystem in > Wildfly/EAP. > > These attributes only exists in the XML (standalone.xml, domain.xml), aren't > accessible in the management model apart from their values being used in > resource addresses. E.g. > > > > would be accessed in CLI as > > /subsystem=resource-adapters/resource-adapter=test/admin-objects=test-a-o > > So the only thing that would change is the XML attribute "pool-name" being > renamed to "name". > > Do you see it as a complication from TEIID point of view, or do you know who > could answer that? > > Thanks, > Tomas > > On 30/07/18 22:45, Brian Stansberry wrote: >> >> >> On Mon, Jul 30, 2018 at 3:32 AM, Tomas Hofman >> >> wrote: >> >> Yes, that's what I believe should be done. >> >> Adding also Tomasz and Tom :). >> >> I'm yet to asses the impact on documentation, by my feeling from my initial >> investigation was that I didn't found very many documents dealing with this. >> >> >> Please check with the Teiid folks, as Teiid heavily uses this subsystem. >> >> >> Am I correct in thinking that if the new parser is able to parse the old >> config version, no other migration work is needed? >> >> >> Right, unless Stefano wants the parser for the new schema version to be >> forgiving and allow the old attribute. >> >> >> Tomas >> >> On 19/07/18 22:38, Brian Stansberry wrote: >> >> So basically the issue here is that the xml attribute should be called >> 'name' instead of 'pool-name'? >> >> Sounds like a minor Enhancement not a major Bug. If there's much in the >> way of docs out there that use pool-name then the cost of changing it >> (wrong docs) may outweigh any benefit. >> >> On Thu, Jul 19, 2018 at 9:24 AM, Tomas Hofman >> > >> >> wrote: >> >> The and elements in >> resource adapters >> subsystem have "pool-name" attribute that looks like it isn't used for >> anything, which is misleading for users. >> >> It looks that "pool-name" attribute was intended for functionality >> that wasn't >> implemented. The attributes are only present in XML, and do not >> exist in >> management model. >> >> During resource creation the values are passed into service value >> objects >> (ModifiableAdminObject, ModifiableConnDef), but #getPoolName() >> methods are not >> called from anywhere. >> >> The attributes can't be simply removed because their values are >> used for >> resource addressing, e.g. >> >> /subsystem=resource-adapters/.../admin-objects=test-a-o:add(...) >> >> will produce >> >> >> >> so some "name" attribute is still needed. >> >> Unless you think that this is not worth having new schema version >> (or the >> intended functionality that requires "pool-name" attrs is planned >> to be >> implemented), I would create new XSD schema version with "pool-name" >> renamed to >> "name" and update the parser. I suppose the new XSD version should >> be 6.0, >> rather than 5.1, no matter how small the change. >> >> Also, AFAIK this change couldn't be backported to released product >> streams. >> >> The issue where this was raised is >> https://issues.jboss.org/browse/JBEAP-15023 >> > >> >> >> >> >> -- Tomas Hofman >> Software Engineer, JBoss SET >> Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org > >> >> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> >> >> >> >> >> >> >> -- >> Brian Stansberry >> Manager, Senior Principal Software Engineer >> Red Hat >> >> >> -- >> Tomas Hofman >> Software Engineer, JBoss SET >> Red Hat >> >> >> >> >> -- >> Brian Stansberry >> Manager, Senior Principal Software Engineer >> Red Hat > > -- > Tomas Hofman > Software Engineer, JBoss SET > 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/20180731/31487083/attachment-0001.html