From rory.odonnell at oracle.com Mon Jul 2 05:16:15 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 2 Jul 2018 10:16:15 +0100 Subject: [infinispan-dev] JDK 11 is now in Rampdown Phase one Message-ID: <78fa4727-3c49-c853-13be-b9937ef2fc38@oracle.com> Hi Galder, *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/infinispan-dev/attachments/20180702/fef95aef/attachment.html From slaskawi at redhat.com Thu Jul 5 04:51:59 2018 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Thu, 5 Jul 2018 10:51:59 +0200 Subject: [infinispan-dev] Proposal - encrypted cache In-Reply-To: References:

Message-ID: Just stumbled upon: https://blog.acolyer.org/2018/07/05/enclavedb-a-secure-database-using-sgx/ Perhaps using enclaves could be a way to secure in-memory data (especially having in mind that we can use off-heap). Adding mandatory TLS + Authentication would make Infinispan very secure. On Tue, Nov 29, 2016 at 10:24 AM Sebastian Laskawiec wrote: > With your explanation I think I get it now... > > So from my point of view, I would assume that we *can't* trust the > servers. But with TLS we *can* trust the communication channel. > > Does this makes sense now? > > On Mon, Nov 28, 2016 at 4:07 PM, Sanne Grinovero > wrote: > >> On 28 November 2016 at 07:21, Sebastian Laskawiec >> wrote: >> > Hey Sanne! >> > >> > Comments inlined. >> > >> > Thanks >> > Sebastian >> > >> > On Fri, Nov 25, 2016 at 2:55 PM, Sanne Grinovero >> > wrote: >> >> >> >> Hi Sebastian, >> >> you're opening a very complex (but interesting!) topic. >> >> >> >> As the paper you linked to also reminds, it's extremely hard to >> >> implement such a thing without "giving away" lots of useful metadata >> >> to a potential attacker. It's an interesting paper as they propose a >> >> technique to maintain query capabilities while not having the full >> >> data readability, yet as other papers which I've seen before it's both >> >> complex to implement, and leaves some questions unanswered; in this >> >> case they seem to "just" not being able to camouflage the data access >> >> patterns, which is pretty good but according to some experts really >> >> not enough to keep the decryption keys safe. >> >> >> >> The typical problem is that if the server has no clue about the >> >> encrypted blobs at all we won't be able to query it. However there's >> >> ongoing research (like this one?) about being still able to run >> >> queries on behalf of key-owning clients, identify a subset of the >> >> data, e.g. a *naive* example: if you know the data structure and can >> >> tell which section contains the "encrypted surname", then a client >> >> could query for identical matches on the "encrypted surname"; however >> >> this naive approach is critically flawed such as you might be able to >> >> extract the encryption keys by analysing the statistical frequency of >> >> signatures and run a dictionary attack, e.g. you might have a good >> >> guess about which surname is expected to be the most commonly used. >> >> You'll need salting techniques combined within the query capabilities, >> >> e.g. MAC (message authentication codes) but these either require you >> >> to trust the database (are we going in circles?) or expose you to >> >> other forms of attack. >> > >> > >> > Yes, you are correct. Not being able to query the server is a very >> serious >> > problem. But preventing a potential attacker from analyzing your >> > communication seems very easy to be solved - just use TLS to encrypt >> > connection between the client and the server. >> >> Maybe I misunderstood the "requirements" of your proposal. My answer >> was based on the assumption that the client wouldn't trust the >> servers, for example a client wanting to store sensible data in a >> "database as a service" platform, having a third party provide the >> service. >> If you use TLS during communication, it implies you don't trust the >> communication channels but somewhat trust the server. You might as >> well just use TLS and then not store the data in encrypted form, or >> share the encryption access with the servers? >> >> Thanks, >> Sanne >> >> >> > >> > So I think the main challenge is how to perform a search operation >> through >> > an encrypted data set... >> > >> >> >> >> >> >> While it's obvious that this introduces some limitations on search >> >> capabilities on the fields of the value, you might also have similar >> >> problems just on the keys. For example you might not be able to use >> >> any form of affinity which takes advantage of some domain specific >> >> knowledge, or just about do anything useful beyond the pure >> >> "key/value" capabilities which are extremely limited. >> >> Besides, even the fact that the "key" doesn't change over time might >> >> be critical: it means you can't use salting on the key, which again >> >> introduces dictionary attacks by merely observing the frequency of >> >> operations. >> >> >> >> Even if you're prepared to give up on all those features and accept >> >> some limitations to just encrypt it all on the client, the "grid" >> >> needs nevertheless to be considered a trusted party; given the large >> >> amount of data and access patterns, the data grid has so much insight >> >> on both data and access patterns, that I doubt it can be properly >> >> secured. >> > >> > >> > Granted. If a potential attacker had access to the machine hosting an >> > Infinispan Server (e.g. could do a memory snapshot), the encryption >> > algorithm would need to "survive" statistical analysis. >> > >> >> >> >> >> >> I'm not sure we have the right engineering skills to develop such a >> >> system, we'd need at least to brush up on existing research in this >> >> field, of which I'm not aware there being any "full solution" unless >> >> you give a good amount of trust to the database.. >> > >> > >> > There's a database called CryptDB: >> > >> http://bristolcrypto.blogspot.com/2013/11/how-to-search-on-encrypted-data-in.html >> > >> > I haven't looked into the research papers yet but if we had to trust any >> > database we should pick something like that. >> > >> >> >> >> >> >> I'd love it if someone could explore this more, but be aware that it's >> >> not as easy as just enabling encryption on the client. >> > >> > >> > I totally agree. Thanks a lot for pointing all those useful aspects! >> > >> >> >> >> >> >> Thanks, >> >> Sanne >> >> >> >> >> >> >> >> >> >> On 25 November 2016 at 12:32, Sebastian Laskawiec > > >> >> wrote: >> >> > 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 >> >> > >> >> > _______________________________________________ >> >> > 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 >> _______________________________________________ >> 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/infinispan-dev/attachments/20180705/5579868e/attachment-0001.html From emmanuel at hibernate.org Thu Jul 5 05:29:25 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 5 Jul 2018 11:29:25 +0200 Subject: [infinispan-dev] Proposal - encrypted cache In-Reply-To: References:

Message-ID: <20180705092925.GC28527@hibernate.org> If you ask Clement, it was quite a challenge to run one of the small JVM variant within the enclave. We would need a specific support at the VM level to do some piece of code within the enclave while others are not. On Thu 18-07-05 10:51, Sebastian Laskawiec wrote: >Just stumbled upon: >https://blog.acolyer.org/2018/07/05/enclavedb-a-secure-database-using-sgx/ > >Perhaps using enclaves could be a way to secure in-memory data (especially >having in mind that we can use off-heap). Adding mandatory TLS + >Authentication would make Infinispan very secure. > >On Tue, Nov 29, 2016 at 10:24 AM Sebastian Laskawiec >wrote: > >> With your explanation I think I get it now... >> >> So from my point of view, I would assume that we *can't* trust the >> servers. But with TLS we *can* trust the communication channel. >> >> Does this makes sense now? >> >> On Mon, Nov 28, 2016 at 4:07 PM, Sanne Grinovero >> wrote: >> >>> On 28 November 2016 at 07:21, Sebastian Laskawiec >>> wrote: >>> > Hey Sanne! >>> > >>> > Comments inlined. >>> > >>> > Thanks >>> > Sebastian >>> > >>> > On Fri, Nov 25, 2016 at 2:55 PM, Sanne Grinovero >>> > wrote: >>> >> >>> >> Hi Sebastian, >>> >> you're opening a very complex (but interesting!) topic. >>> >> >>> >> As the paper you linked to also reminds, it's extremely hard to >>> >> implement such a thing without "giving away" lots of useful metadata >>> >> to a potential attacker. It's an interesting paper as they propose a >>> >> technique to maintain query capabilities while not having the full >>> >> data readability, yet as other papers which I've seen before it's both >>> >> complex to implement, and leaves some questions unanswered; in this >>> >> case they seem to "just" not being able to camouflage the data access >>> >> patterns, which is pretty good but according to some experts really >>> >> not enough to keep the decryption keys safe. >>> >> >>> >> The typical problem is that if the server has no clue about the >>> >> encrypted blobs at all we won't be able to query it. However there's >>> >> ongoing research (like this one?) about being still able to run >>> >> queries on behalf of key-owning clients, identify a subset of the >>> >> data, e.g. a *naive* example: if you know the data structure and can >>> >> tell which section contains the "encrypted surname", then a client >>> >> could query for identical matches on the "encrypted surname"; however >>> >> this naive approach is critically flawed such as you might be able to >>> >> extract the encryption keys by analysing the statistical frequency of >>> >> signatures and run a dictionary attack, e.g. you might have a good >>> >> guess about which surname is expected to be the most commonly used. >>> >> You'll need salting techniques combined within the query capabilities, >>> >> e.g. MAC (message authentication codes) but these either require you >>> >> to trust the database (are we going in circles?) or expose you to >>> >> other forms of attack. >>> > >>> > >>> > Yes, you are correct. Not being able to query the server is a very >>> serious >>> > problem. But preventing a potential attacker from analyzing your >>> > communication seems very easy to be solved - just use TLS to encrypt >>> > connection between the client and the server. >>> >>> Maybe I misunderstood the "requirements" of your proposal. My answer >>> was based on the assumption that the client wouldn't trust the >>> servers, for example a client wanting to store sensible data in a >>> "database as a service" platform, having a third party provide the >>> service. >>> If you use TLS during communication, it implies you don't trust the >>> communication channels but somewhat trust the server. You might as >>> well just use TLS and then not store the data in encrypted form, or >>> share the encryption access with the servers? >>> >>> Thanks, >>> Sanne >>> >>> >>> > >>> > So I think the main challenge is how to perform a search operation >>> through >>> > an encrypted data set... >>> > >>> >> >>> >> >>> >> While it's obvious that this introduces some limitations on search >>> >> capabilities on the fields of the value, you might also have similar >>> >> problems just on the keys. For example you might not be able to use >>> >> any form of affinity which takes advantage of some domain specific >>> >> knowledge, or just about do anything useful beyond the pure >>> >> "key/value" capabilities which are extremely limited. >>> >> Besides, even the fact that the "key" doesn't change over time might >>> >> be critical: it means you can't use salting on the key, which again >>> >> introduces dictionary attacks by merely observing the frequency of >>> >> operations. >>> >> >>> >> Even if you're prepared to give up on all those features and accept >>> >> some limitations to just encrypt it all on the client, the "grid" >>> >> needs nevertheless to be considered a trusted party; given the large >>> >> amount of data and access patterns, the data grid has so much insight >>> >> on both data and access patterns, that I doubt it can be properly >>> >> secured. >>> > >>> > >>> > Granted. If a potential attacker had access to the machine hosting an >>> > Infinispan Server (e.g. could do a memory snapshot), the encryption >>> > algorithm would need to "survive" statistical analysis. >>> > >>> >> >>> >> >>> >> I'm not sure we have the right engineering skills to develop such a >>> >> system, we'd need at least to brush up on existing research in this >>> >> field, of which I'm not aware there being any "full solution" unless >>> >> you give a good amount of trust to the database.. >>> > >>> > >>> > There's a database called CryptDB: >>> > >>> http://bristolcrypto.blogspot.com/2013/11/how-to-search-on-encrypted-data-in.html >>> > >>> > I haven't looked into the research papers yet but if we had to trust any >>> > database we should pick something like that. >>> > >>> >> >>> >> >>> >> I'd love it if someone could explore this more, but be aware that it's >>> >> not as easy as just enabling encryption on the client. >>> > >>> > >>> > I totally agree. Thanks a lot for pointing all those useful aspects! >>> > >>> >> >>> >> >>> >> Thanks, >>> >> Sanne >>> >> >>> >> >>> >> >>> >> >>> >> On 25 November 2016 at 12:32, Sebastian Laskawiec >> > >>> >> wrote: >>> >> > 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 >>> >> > >>> >> > _______________________________________________ >>> >> > 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 >>> _______________________________________________ >>> 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 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: [infinispan-dev] [wildfly-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/infinispan-dev/attachments/20180710/d622fe38/attachment-0001.html From rory.odonnell at oracle.com Tue Jul 17 07:12:53 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 17 Jul 2018 12:12:53 +0100 Subject: [infinispan-dev] JDK 11 Early Access build 22 & JDK 12 Early Access b02 are available. Message-ID: Hi Galder, *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/infinispan-dev/attachments/20180717/40c3371f/attachment.html