Proposal - encrypted cache
by Sebastian Laskawiec
Hey!
A while ago I stumbled upon [1]. The article talks about encrypting data
before they reach the server, so that the server doesn't know how to
decrypt it. This makes the data more secure.
The idea is definitely not new and I have been asked about something
similar several times during local JUGs meetups (in my area there are lots
of payments organizations who might be interested in this).
Of course, this can be easily done inside an app, so that it encrypts the
data and passes a byte array to the Hot Rod Client. I'm just thinking about
making it a bit easier and adding a default encryption/decryption mechanism
to the Hot Rod client.
What do you think? Does it make sense?
Thanks
Sebastian
[1] https://eprint.iacr.org/2016/920.pdf
5 years, 10 months
Infinispan client/server architecture based on gRPC
by Vittorio Rigamonti
Hi Infinispan developers,
I'm working on a solution for developers who need to access Infinispan
services through different programming languages.
The focus is not on developing a full featured client, but rather discover
the value and the limits of this approach.
- is it possible to automatically generate useful clients in different
languages?
- can that clients interoperate on the same cache with the same data types?
I came out with a small prototype that I would like to submit to you and on
which I would like to gather your impressions.
You can found the project here [1]: is a gRPC-based client/server
architecture for Infinispan based on and EmbeddedCache, with very few
features exposed atm.
Currently the project is nothing more than a poc with the following
interesting features:
- client can be generated in all the grpc supported language: java, go, c++
examples are provided;
- the interface is full typed. No need for marshaller and clients build in
different language can cooperate on the same cache;
The second item is my preferred one beacuse it frees the developer from
data marshalling.
What do you think about?
Sounds interesting?
Can you see any flaw?
There's also a list of issues for the future [2], basically I would like to
investigate these questions:
How far this architecture can go?
Topology, events, queries... how many of the Infinispan features can be fit
in a grpc architecture?
Thank you
Vittorio
[1] https://github.com/rigazilla/ispn-grpc
[2] https://github.com/rigazilla/ispn-grpc/issues
--
Vittorio Rigamonti
Senior Software Engineer
Red Hat
<https://www.redhat.com>
Milan, Italy
vrigamon(a)redhat.com
irc: rigazilla
<https://red.ht/sig>
5 years, 11 months
JDK 11 Early Access build 15 is available for download.
by Rory O'Donnell
Hi Galder,
**JDK 11 EA build 15 , *****under both the GPL and Oracle EA licenses,
is now available at **http://jdk.java.net/11**. **
*
* Newly approved Schedule, status & features
o http://openjdk.java.net/projects/jdk/11/
* Release Notes:
o http://jdk.java.net/11/release-notes
* Summary of changes
o http://jdk.java.net/11/changes
*Notable changes in JDK 11 EA builds since last email:*
* b15 - JDK-8201627 <http://bugs.openjdk.java.net/browse/JDK-8201627>
- Kerberos sequence number issues
* b13 - JDK-8200146 <http://bugs.openjdk.java.net/browse/JDK-8200146>
- Removal of appletviewer launcher
o deprecated in JDK 9 and has been removed in this release
* b13 - JDK-8201793 <http://bugs.openjdk.java.net/browse/JDK-8201793>
- java.lang.ref.Reference does not support cloning
**
**
JEPs proposed to target JDK 11 (review ends 2018/05/31 23:00 UTC)
330: Launch Single-File Source-Code Programs
<http://openjdk.java.net/jeps/330>
JEPs targeted to JDK 11, so far
309: Dynamic Class-File Constants <http://openjdk.java.net/jeps/309>
318: Epsilon: A No-Op Garbage Collector
<http://openjdk.java.net/jeps/318>
320: Remove the Java EE and CORBA Modules
<http://openjdk.java.net/jeps/320>
321: HTTP Client (Standard) <http://openjdk.java.net/jeps/321>
323: Local-Variable Syntax for Lambda Parameters
<http://openjdk.java.net/jeps/323>
324: Key Agreement with Curve25519 and Curve448
<http://openjdk.java.net/jeps/324>
327: Unicode 10 <http://openjdk.java.net/jeps/327>
328: Flight Recorder <http://openjdk.java.net/jeps/328>
329: ChaCha20 and Poly1305 Cryptographic Algorithms
<http://openjdk.java.net/jeps/329>
Finally, Initial TLSv1.3 implementation Released to the Open Sandbox.
Please note well: this branch is under
very active development and is not final by any means. Also note: by
releasing this code, we are not committing
a specific release or timeframe. We will continue development and fixing
bugs until the code is ready for inclusion
in the JDK. We welcome your feedback, more info [1]
Regards,
Rory
[1]
http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
5 years, 11 months
Maintenance of OpenShift templates
by Galder Zamarreño
Hi,
Looking at [1] and I'm wondering why the templates have to maintain a
different XML file for OpenShift?
We already ship an XML in the server called `cloud.xml`, that should
just work. Having a separate XML file in the templates means we're
duplicating the maintainance of XML files.
Also, users can now create caches programmatically. This is by far the
most common tweak that had to be done to the config. So, I see the
urgency to change XML files less immediate.
Sure, there will always be people who modify/tweak things and that's
fine. We should however show the people how to do that in a way that
doesn't require us to duplicate our maintanence work.
Also, if we want to show the users how to use a custom XML file, I don't
think we should show them how to embedd it in the template as JSON
[2]. It's quite a pain. Instead, the XML should be kept as a separate
file and the JSON file reference it.
Cheers,
[1]
https://github.com/infinispan/infinispan-openshift-templates/pull/16/files
[2] https://github.com/infinispan/infinispan-openshift-templates#maintenance-...
6 years
Passing client listener parameters programmatically
by Galder Zamarreno
Hi,
We're working with the OpenWhisk team to create a generic Feed that allows
Infinispan remote events to be exposed in an OpenWhisk way.
So, you'd pass in Hot Rod endpoint information, name of cache and other
details and you'd establish a feed of data from that cache for
create/updated/removed data.
However, making this generic is tricky when you want to pass in
filter/converter factory names since these are defined at the annotation
level.
Ideally we should have a way to pass in filter/converter factory names
programmatically. To avoid limiting ourselves, you could potentially pass
in an instance of the annotation in an overloaded method or as optional
parameter [1].
Thoughts?
Cheers,
Galder
[1]
https://stackoverflow.com/questions/16299717/how-to-create-an-instance-of...
6 years
Re: [infinispan-dev] [wildfly-dev] WFLYTX0013 in the Infinispan Openshift Template
by Sebastian Laskawiec
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(a)redhat.com>
wrote:
> Thanks Brian. Does it work for you Sebastian?
>
> On 8 May 2018 at 23:05, Brian Stansberry <brian.stansberry(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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/reso...
>>>>>>>>>
>>>>>>>>> On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson <
>>>>>>>>> tom.jenkinson(a)redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec <
>>>>>>>>>> slaskawi(a)redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey Tom,
>>>>>>>>>>>
>>>>>>>>>>> Comments inlined.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Sebastian
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson <
>>>>>>>>>>> tom.jenkinson(a)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...
>>>>>>>>>>>>> > 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-opensh...
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >
>>>>>>>>>>>>> https://github.com/jboss-openshift/cct_module/blob/master/os-jdg7-conffil...
>>>>>>>>>>>>>
>>>>>>>>>>>> > 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/f...
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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/65962cf...
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev(a)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
>>
>
>
6 years
Re: [infinispan-dev] [wildfly-dev] WFLYTX0013 in the Infinispan Openshift Template
by Brian Stansberry
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(a)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(a)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(a)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-quickstart
>>> s/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(a)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(a)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(a)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(a)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(a)redhat.com> wrote:
>>>>>>>
>>>>>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec <slaskawi(a)redhat.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Hey Tom,
>>>>>>>>>
>>>>>>>>> Comments inlined.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Sebastian
>>>>>>>>>
>>>>>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson <
>>>>>>>>> tom.jenkinson(a)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/TransactionSubsyste
>>>>>>>>>>> mRootResourceDefinition.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/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 <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/piperma
>>>>>>>>>>> il/wildfly-dev/attachments/20180416/65962cf1/attachment-0001
>>>>>>>>>>> .html
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev(a)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
6 years
Re: [infinispan-dev] [wildfly-dev] WFLYTX0013 in the Infinispan Openshift Template
by Brian Stansberry
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(a)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(a)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(a)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(a)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(a)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(a)redhat.com> wrote:
>>>>>
>>>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec <slaskawi(a)redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hey Tom,
>>>>>>>
>>>>>>> Comments inlined.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Sebastian
>>>>>>>
>>>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson <
>>>>>>> tom.jenkinson(a)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/TransactionSubsyste
>>>>>>>>> mRootResourceDefinition.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/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 <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/201
>>>>>>>>> 80416/65962cf1/attachment-0001.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)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
6 years
JDK 11 Early Access build 12 available
by Rory O'Donnell
Hi Galder,
**JDK 11 EA build 12 , *****under both the GPL and Oracle EA licenses,
is now available at **http://jdk.java.net/11**. **
*
* Newly approved Schedule, status & features
o http://openjdk.java.net/projects/jdk/11/
* Release Notes:
o http://jdk.java.net/11/release-notes
* Summary of changes
o https://download.java.net/java/early_access/jdk11/12/jdk-11+12.html
*Notable changes in JDK 11 EA builds since last email:*
* Build 11 - see Release Notes for details.
o JDK-8201315 : SelectableChannel.register may be invoked while a
selection operation is in progress
* Build 10 - see Release Notes for details.
o JDK-8200149 : Removal of "com.sun.awt.AWTUtilities" class
o JDK-8189997 (not public) : Enhanced KeyStore Mechanisms
o JDK-8175075 (not public) : 3DES Cipher Suites Disabled
* Build 9: - see Release Notes for details.
o JDK-8200152 : KerberosString uses UTF-8 encoding by default
o JDK-8200458 : Readiness information previously recorded in
SelectionKey ready set not preserved
**
*Draft JEP: Deprecate pack200, unpack200 tools and related APIs. [1]
*
This draft JEP [2] proposes to deprecate the pack200 APIs and tools in
the JDK. As outlined in the JEP, the usefulness of this technology
have diminishing returns, the components using them are being removed
and connectivity speeds have improved by leaps and bounds,
since its inception. Feedback appreciated via
http://mail.openjdk.java.net/pipermail/jdk-dev
Regards,
Rory
[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001074.html
[2] https://bugs.openjdk.java.net/browse/JDK-8200752
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
6 years