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.jenkin...@redhat.com> wrote: > Sure - thanks! > > On 10 May 2018 at 02:56, Sebastian Laskawiec <slask...@redhat.com> 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.jenkin...@redhat.com> >> wrote: >> >>> Thanks Brian. Does it work for you Sebastian? >>> >>> On 8 May 2018 at 23:05, Brian Stansberry <brian.stansbe...@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.jenkin...@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.stansbe...@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.jenkin...@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.stansbe...@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 < >>>>>>>> slask...@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.jenkin...@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 <slask...@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.jenkin...@redhat.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec < >>>>>>>>>>>> slask...@redhat.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hey Tom, >>>>>>>>>>>>> >>>>>>>>>>>>> Comments inlined. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Sebastian >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson < >>>>>>>>>>>>> tom.jenkin...@redhat.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 16 April 2018 at 09:31, <> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Adding +WildFly Dev <wildfly-dev at lists.jboss.org> 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 <rhusar at >>>>>>>>>>>>>>> redhat.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > Hi Sebastian, >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec >>>>>>>>>>>>>>> > <slaskawi at redhat.com> 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 <sanne at >>>>>>>>>>>>>>> infinispan.org> >>>>>>>>>>>>>>> > > wrote: >>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec <slaskawi >>>>>>>>>>>>>>> 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 <sanne >>>>>>>>>>>>>>> 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-...@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 >>>> >>> >>> >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev