From ttarrant at redhat.com Fri Dec 1 03:26:37 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Fri, 1 Dec 2017 09:26:37 +0100 Subject: [infinispan-dev] PR labels Message-ID: Hello people, I'd like to rationalize the PR labels because I believe some of them are useless: [Ready for review] - Any PR without the [Preview] label must fall under this category [Backport] - The burden should be on the PR owner to create relevant backport PRs, not on the reviewer [Wait CI Results] - PRs should only be integrated after a successful CI run (or when failures can be proven to be pre-existing) [Check CI Failures!] - The CI runs already add failure/success to the PR status. Checking CI failures should apply to ALL PRs. [On Ice] PR should be closed and reopened when relevant again. Comments/suggestions ? Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From rvansa at redhat.com Fri Dec 1 04:04:16 2017 From: rvansa at redhat.com (Radim Vansa) Date: Fri, 1 Dec 2017 10:04:16 +0100 Subject: [infinispan-dev] PR labels In-Reply-To: References: Message-ID: <9a588075-4ccf-8416-5269-f0a98c627917@redhat.com> On 12/01/2017 09:26 AM, Tristan Tarrant wrote: > Hello people, > > I'd like to rationalize the PR labels because I believe some of them are > useless: > > [Ready for review] - Any PR without the [Preview] label must fall under > this category > [Backport] - The burden should be on the PR owner to create relevant > backport PRs, not on the reviewer I think that [Backport] means that this is already in upstream, and therefore review should be mostly formal (not breaking APIs but not "this could be done 1% better. Also it is a second warning for reviewer that this shouldn't be cherry-picked on master (when merging from cmdline). > [Wait CI Results] - PRs should only be integrated after a successful CI > run (or when failures can be proven to be pre-existing) > [Check CI Failures!] - The CI runs already add failure/success to the PR > status. Checking CI failures should apply to ALL PRs. > [On Ice] PR should be closed and reopened when relevant again. > > Comments/suggestions ? > > Tristan -- Radim Vansa JBoss Performance Team From rvansa at redhat.com Fri Dec 1 04:07:11 2017 From: rvansa at redhat.com (Radim Vansa) Date: Fri, 1 Dec 2017 10:07:11 +0100 Subject: [infinispan-dev] PR labels In-Reply-To: <9a588075-4ccf-8416-5269-f0a98c627917@redhat.com> References: <9a588075-4ccf-8416-5269-f0a98c627917@redhat.com> Message-ID: On 12/01/2017 10:04 AM, Radim Vansa wrote: > On 12/01/2017 09:26 AM, Tristan Tarrant wrote: >> Hello people, >> >> I'd like to rationalize the PR labels because I believe some of them are >> useless: >> >> [Ready for review] - Any PR without the [Preview] label must fall under >> this category >> [Backport] - The burden should be on the PR owner to create relevant >> backport PRs, not on the reviewer > > I think that [Backport] means that this is already in upstream, and > therefore review should be mostly formal (not breaking APIs but not > "this could be done 1% better. Hit send too fast... The complexity of a review indicates time spent with the review; I'd expect a backport review to be a 15 minute job, not 2 hour one, so when looking for a appetizer before lunch these are on-sight good candidates. > Also it is a second warning for reviewer that this shouldn't be > cherry-picked on master (when merging from cmdline). > >> [Wait CI Results] - PRs should only be integrated after a successful CI >> run (or when failures can be proven to be pre-existing) >> [Check CI Failures!] - The CI runs already add failure/success to the PR >> status. Checking CI failures should apply to ALL PRs. >> [On Ice] PR should be closed and reopened when relevant again. >> >> Comments/suggestions ? >> >> Tristan > > -- Radim Vansa JBoss Performance Team From pedro at infinispan.org Fri Dec 1 07:03:02 2017 From: pedro at infinispan.org (Pedro Ruivo) Date: Fri, 1 Dec 2017 12:03:02 +0000 Subject: [infinispan-dev] PR labels In-Reply-To: References: Message-ID: <0df34c91-96b8-c615-15ff-c87f0d47fba1@infinispan.org> Hi, can we keep the "changes suggested/required"? This would be exclusive with "ready for preview" and means someone review the PR and requires a reply from the author. Cheers, Pedro On 01-12-2017 08:26, Tristan Tarrant wrote: > Hello people, > > I'd like to rationalize the PR labels because I believe some of them are > useless: > > [Ready for review] - Any PR without the [Preview] label must fall under > this category > [Backport] - The burden should be on the PR owner to create relevant > backport PRs, not on the reviewer > [Wait CI Results] - PRs should only be integrated after a successful CI > run (or when failures can be proven to be pre-existing) > [Check CI Failures!] - The CI runs already add failure/success to the PR > status. Checking CI failures should apply to ALL PRs. > [On Ice] PR should be closed and reopened when relevant again. > > Comments/suggestions ? > > Tristan > From ttarrant at redhat.com Fri Dec 1 08:53:20 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Fri, 1 Dec 2017 14:53:20 +0100 Subject: [infinispan-dev] PR labels In-Reply-To: <0df34c91-96b8-c615-15ff-c87f0d47fba1@infinispan.org> References: <0df34c91-96b8-c615-15ff-c87f0d47fba1@infinispan.org> Message-ID: Sure: all the labels I haven't mentioned can stay. Tristan On 12/1/17 1:03 PM, Pedro Ruivo wrote: > Hi, > > can we keep the "changes suggested/required"? > This would be exclusive with "ready for preview" and means someone > review the PR and requires a reply from the author. > > Cheers, > Pedro > > On 01-12-2017 08:26, Tristan Tarrant wrote: >> Hello people, >> >> I'd like to rationalize the PR labels because I believe some of them are >> useless: >> >> [Ready for review] - Any PR without the [Preview] label must fall under >> this category >> [Backport] - The burden should be on the PR owner to create relevant >> backport PRs, not on the reviewer >> [Wait CI Results] - PRs should only be integrated after a successful CI >> run (or when failures can be proven to be pre-existing) >> [Check CI Failures!] - The CI runs already add failure/success to the PR >> status. Checking CI failures should apply to ALL PRs. >> [On Ice] PR should be closed and reopened when relevant again. >> >> Comments/suggestions ? >> >> Tristan >> > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From slaskawi at redhat.com Fri Dec 1 09:13:40 2017 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Fri, 01 Dec 2017 14:13:40 +0000 Subject: [infinispan-dev] PR labels In-Reply-To: References: Message-ID: Hey Tristan, Comments inlined. Thanks, Sebastian On Fri, Dec 1, 2017 at 9:28 AM Tristan Tarrant wrote: > Hello people, > > I'd like to rationalize the PR labels because I believe some of them are > useless: > > [Ready for review] - Any PR without the [Preview] label must fall under > this category > If a PR doesn't fall into Preview category, it must be Ready for Review. In my opinion "Ready for Review" is redundant. > [Backport] - The burden should be on the PR owner to create relevant > backport PRs, not on the reviewer > +1 > [Wait CI Results] - PRs should only be integrated after a successful CI > run (or when failures can be proven to be pre-existing) > All PRs should be evaluated by Jenkins. The CI check has 3 icons on Github Pull Request page - green tick, red cross and yellow dot. Yellow dot means that the PR is being built right now (or waiting in the queue). I believe "Wait CI Results" and that yellow dot are identical and "Wait CI Result" is redundant. > [Check CI Failures!] - The CI runs already add failure/success to the PR > status. Checking CI failures should apply to ALL PRs. > [On Ice] PR should be closed and reopened when relevant again. > Let just close such PRs! Redundant... > > Comments/suggestions ? > > Tristan > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > 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/20171201/0a1c3ecf/attachment.html From mudokonman at gmail.com Fri Dec 1 10:18:55 2017 From: mudokonman at gmail.com (William Burns) Date: Fri, 01 Dec 2017 15:18:55 +0000 Subject: [infinispan-dev] Exposure location of Minimum Node Required Message-ID: Recently I have been working on [1]. Calculating this value is not a hard task. However as usual the hardest thing is where does this live and what is its name. In regards to its location I have a few places I was thinking: 1. CacheImpl/CacheManagerImpl - it would just be an exposed ManagedAttribute This is my least favorite. 2. CacheMgmtInterceptor/Stats/ClusterStats This is available at both cache and cluster levels, but this isn't really a stat. However this one is the only option I found that actually aggregates all nodes data to be presented, which would give a better estimate (since each node can have a varying amount of data they could each have a different idea of required node count). 3. CacheHealth/ClusterHealth This is available at both cache and cluster levels. However these were designed for health checks, but it seems like a legitimate place to me. The only problem is the values aren't aggregated and just called from 1 node. I am personally leaning towards #2 or #3. Also I am open if we have other alternatives I am not aware of :) Let me know what you all think? [1] https://issues.jboss.org/browse/ISPN-6879 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20171201/0839b3bb/attachment.html From ttarrant at redhat.com Sun Dec 3 12:07:38 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Sun, 3 Dec 2017 18:07:38 +0100 Subject: [infinispan-dev] PR labels In-Reply-To: References:

Message-ID: <7f6a76ea-9c5f-5023-e165-c5669a0c5804@redhat.com> You basically just said +1 to all the ones I want to remove :) Tristan On 12/1/17 3:13 PM, Sebastian Laskawiec wrote: > Hey Tristan, > > Comments inlined. > > Thanks, > Sebastian > > On Fri, Dec 1, 2017 at 9:28 AM Tristan Tarrant > wrote: > > Hello people, > > I'd like to rationalize the PR labels because I believe some of them are > useless: > > [Ready for review] - Any PR without the [Preview] label must fall under > this category > > > If a PR doesn't fall into Preview category, it must be Ready for Review. > In my opinion "Ready for Review" is redundant. > > [Backport] - The burden should be on the PR owner to create relevant > backport PRs, not on the reviewer > > > +1 > > [Wait CI Results] - PRs should only be integrated after a successful CI > run (or when failures can be proven to be pre-existing) > > > All PRs should be evaluated by Jenkins. The CI check has 3 icons on > Github Pull Request page - green tick, red cross and yellow dot. Yellow > dot means that the PR is being built right now (or waiting in the > queue). I believe "Wait CI Results" and that yellow dot are identical > and "Wait CI Result" is redundant. > > [Check CI Failures!] - The CI runs already add failure/success to the PR > status. Checking CI failures should apply to ALL PRs. > [On Ice] PR should be closed and reopened when relevant again. > > > Let just close such PRs! Redundant... > > > Comments/suggestions ? > > Tristan > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > 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 > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From ttarrant at redhat.com Sun Dec 3 12:08:06 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Sun, 3 Dec 2017 18:08:06 +0100 Subject: [infinispan-dev] PR labels In-Reply-To: References: <9a588075-4ccf-8416-5269-f0a98c627917@redhat.com> Message-ID: <604db493-807e-5d47-8da9-c141531d6e82@redhat.com> Ok, good point. Tristan On 12/1/17 10:07 AM, Radim Vansa wrote: > On 12/01/2017 10:04 AM, Radim Vansa wrote: >> On 12/01/2017 09:26 AM, Tristan Tarrant wrote: >>> Hello people, >>> >>> I'd like to rationalize the PR labels because I believe some of them are >>> useless: >>> >>> [Ready for review] - Any PR without the [Preview] label must fall under >>> this category >>> [Backport] - The burden should be on the PR owner to create relevant >>> backport PRs, not on the reviewer >> >> I think that [Backport] means that this is already in upstream, and >> therefore review should be mostly formal (not breaking APIs but not >> "this could be done 1% better. > > Hit send too fast... The complexity of a review indicates time spent > with the review; I'd expect a backport review to be a 15 minute job, not > 2 hour one, so when looking for a appetizer before lunch these are > on-sight good candidates. > >> Also it is a second warning for reviewer that this shouldn't be >> cherry-picked on master (when merging from cmdline). > >> >>> [Wait CI Results] - PRs should only be integrated after a successful CI >>> run (or when failures can be proven to be pre-existing) >>> [Check CI Failures!] - The CI runs already add failure/success to the PR >>> status. Checking CI failures should apply to ALL PRs. >>> [On Ice] PR should be closed and reopened when relevant again. >>> >>> Comments/suggestions ? >>> >>> Tristan >> >> > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From ttarrant at redhat.com Mon Dec 4 02:26:20 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Mon, 4 Dec 2017 08:26:20 +0100 Subject: [infinispan-dev] Exposure location of Minimum Node Required In-Reply-To: References: Message-ID: <4bbe3681-e074-bc40-f6aa-12a622c2304e@redhat.com> On 12/1/17 4:18 PM, William Burns wrote: > Recently I have been working on [1]. Calculating this value is not a > hard task. However as usual the hardest thing is where does this live > and what is its name. > > In regards to its location I have a few places I was thinking: > > 1. CacheImpl/CacheManagerImpl - it would just be an exposed ManagedAttribute > This is my least favorite. > > 2. CacheMgmtInterceptor/Stats/ClusterStats > This is available at both cache and cluster levels, but this isn't > really a stat. However this one is the only option I found that actually > aggregates all nodes data to be presented, which would give a better > estimate (since each node can have a varying amount of data they could > each have a different idea of required node count). The "Stats" name is a misnomer already, as we return cache information which is not a statistic (e.g. cache size). In any case this is the right place. Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From ttarrant at redhat.com Mon Dec 4 02:29:10 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Mon, 4 Dec 2017 08:29:10 +0100 Subject: [infinispan-dev] PR labels In-Reply-To: <604db493-807e-5d47-8da9-c141531d6e82@redhat.com> References: <9a588075-4ccf-8416-5269-f0a98c627917@redhat.com> <604db493-807e-5d47-8da9-c141531d6e82@redhat.com> Message-ID: <07bb3922-409c-509e-1769-3bc79c0cde57@redhat.com> Following the suggestions, I have removed: [Ready for review] - Use [Preview] when it ain't ready [Wait CI Results] - Always wait for CI results [Check CI Failures!] - See above [On Ice] - Just close it and reopen it [Next release] - Just close it and reopen it I have left [Backport] in there to mean "already fuly reviewed for another branch, only minimal effort required here". Tristan On 12/3/17 6:08 PM, Tristan Tarrant wrote: > Ok, good point. > > Tristan > > On 12/1/17 10:07 AM, Radim Vansa wrote: >> On 12/01/2017 10:04 AM, Radim Vansa wrote: >>> On 12/01/2017 09:26 AM, Tristan Tarrant wrote: >>>> Hello people, >>>> >>>> I'd like to rationalize the PR labels because I believe some of them >>>> are >>>> useless: >>>> >>>> [Ready for review] - Any PR without the [Preview] label must fall under >>>> this category >>>> [Backport] - The burden should be on the PR owner to create relevant >>>> backport PRs, not on the reviewer >>> >>> I think that [Backport] means that this is already in upstream, and >>> therefore review should be mostly formal (not breaking APIs but not >>> "this could be done 1% better. >> >> Hit send too fast... The complexity of a review indicates time spent >> with the review; I'd expect a backport review to be a 15 minute job, not >> 2 hour one, so when looking for a appetizer before lunch these are >> on-sight good candidates. >> >>> Also it is a second warning for reviewer that this shouldn't be >>> cherry-picked on master (when merging from cmdline). >> >>> >>>> [Wait CI Results] - PRs should only be integrated after a successful CI >>>> run (or when failures can be proven to be pre-existing) >>>> [Check CI Failures!] - The CI runs already add failure/success to >>>> the PR >>>> status. Checking CI failures should apply to ALL PRs. >>>> [On Ice] PR should be closed and reopened when relevant again. >>>> >>>> Comments/suggestions ? >>>> >>>> Tristan >>> >>> >> > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From ttarrant at redhat.com Mon Dec 4 11:01:23 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Mon, 4 Dec 2017 17:01:23 +0100 Subject: [infinispan-dev] Weekly IRC Metting logs 2017-12-04 Message-ID: <613b8325-11d8-bc80-a456-81d763b06a7b@redhat.com> Hi all, we had our weekly meeting on #infinispan. The logs: http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2017/infinispan.2017-12-04-15.00.log.html Enjoy Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From galder at redhat.com Thu Dec 7 10:35:12 2017 From: galder at redhat.com (Galder =?utf-8?Q?Zamarre=C3=B1o?=) Date: Thu, 07 Dec 2017 16:35:12 +0100 Subject: [infinispan-dev] Prepending internal cache names with org.infinispan instead of triple underscore In-Reply-To: <40590687-6bdd-fd3c-29a9-bb047c82323e@redhat.com> (Tristan Tarrant's message of "Mon, 6 Nov 2017 12:31:03 +0100") References: <79C9D2B6-C425-4617-85F1-52B2253C20EB@redhat.com>

<82703f60-3b6d-0f6e-26a1-263ec52fe442@redhat.com> <65a5f299-8fd0-a187-8951-e10698c2c280@redhat.com> <40590687-6bdd-fd3c-29a9-bb047c82323e@redhat.com> Message-ID: Tristan Tarrant writes: Thanks everyone, I've created a JIRA to track this: https://issues.jboss.org/browse/ISPN-8595 > To add to Adrian's history lesson: > > ClusterRegistry (a single, replicated, non-persistent, scoped cache) was > replaced with the InternalCacheRegistry which provides a common way for > subsystems to register internal caches with the "traits" they want but > configured to take into account some global settings. This means setting > up proper security roles, persistent paths, etc. > > We do however have a proliferation of caches and in my ISPN-7776 PR I've > reintroduced a scoped config/state cache which can be shared by > interested parties. > > I do like the org.infinispan prefix for internal caches (and I've > amended my PR to use that). I'm not that concerned about the additional > payload, since most of the internal caches we have at the moment change > infrequently (schema, script, topology, etc), but we should probably > come up with a proper way to identify caches with a common short ID. > > Tristan > > On 11/6/17 10:46 AM, Adrian Nistor wrote: >> Different internal caches have different needs regarding consistency, >> tx, persistence, etc... >> The first incarnation of ClusterRegistry was using a single cache and >> was implemented exactly as you suggested, but had major shortcomings >> satisfying the needs of several unrelated users, so we decided to split. >> >> On 11/03/2017 10:42 AM, Radim Vansa wrote: >>> Because you would have to duplicate entire Map on each update, unless >>> you used not-100%-so-far functional commands. We've used the ScopedKey >>> that would make this Cache, Object>. This >>> approach was abandoned with ISPN-5932 [1], Adrian and Tristan can >>> elaborate why. >>> >>> Radim >>> >>> [1] https://issues.jboss.org/browse/ISPN-5932 >>> >>> On 11/03/2017 09:05 AM, Sebastian Laskawiec wrote: >>>> I'm pretty sure it's a silly question, but I need to ask it :) >>>> >>>> Why can't we store all our internal information in a single, >>>> replicated cache (of a type ). PURPOSE >>>> could be an enum or a string identifying whether it's scripting cache, >>>> transaction cache or anything else. The value (Map) >>>> would store whatever you need. >>>> >>>> On Fri, Nov 3, 2017 at 2:24 AM Sanne Grinovero >>> > wrote: >>>> >>>> On 2 November 2017 at 22:20, Adrian Nistor >>> > wrote: >>>> > I like this proposal. >>>> >>>> +1 >>>> >>>> > On 11/02/2017 03:18 PM, Galder Zamarre?o wrote: >>>> >> Hi all, >>>> >> >>>> >> I'm currently going through the JCache 1.1 proposed changes, >>>> and one that made me think is [1]. In particular: >>>> >> >>>> >>> Caches do not use forward slashes (/) or colons (:) as part of >>>> their names. Additionally it is >>>> >>> recommended that cache names starting with java. or >>>> javax.should not be used. >>>> >> I'm wondering whether in the future we should move away from >>>> the triple underscore trick we use for internal cache names, and >>>> instead just prepend them with `org.infinispan`, which is our >>>> group id. I think it'd be cleaner. >>>> >> >>>> >> Thoughts? >>>> >> >>>> >> [1] https://github.com/jsr107/jsr107spec/issues/350 >>>> >> -- >>>> >> Galder Zamarre?o >>>> >> Infinispan, Red Hat >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> 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 galder at redhat.com Thu Dec 7 12:09:52 2017 From: galder at redhat.com (Galder =?utf-8?Q?Zamarre=C3=B1o?=) Date: Thu, 07 Dec 2017 18:09:52 +0100 Subject: [infinispan-dev] Data format not supported with REST Message-ID: Hey Tristan, I was trying your REST curl example in [1], but I'm getting "Data format not supported" error when doing a get. See output in [2]. I'm using 9.1.0, maybe something has changed? Looking at our docu, we don't seem to have any curl REST examples. Cheers, Galder [1] https://developer.jboss.org/thread/274501 [2] https://gist.github.com/galderz/21997d4b673908943a11a38c51d4cc9d From gustavo at infinispan.org Thu Dec 7 14:04:50 2017 From: gustavo at infinispan.org (Gustavo Fernandes) Date: Thu, 7 Dec 2017 19:04:50 +0000 Subject: [infinispan-dev] Data format not supported with REST In-Reply-To: References: Message-ID: Looks like a bug in 9.1.x, the rest server is not handling 'Accept */*' properly, so you need to add the header with the "Accept: text/plain" for the GET This does not happen in 9.2.x, I will look to backport it. Thanks, Gustavo On Thu, Dec 7, 2017 at 5:09 PM, Galder Zamarre?o wrote: > > Hey Tristan, > > I was trying your REST curl example in [1], but I'm getting "Data format > not supported" error when doing a get. See output in [2]. > > I'm using 9.1.0, maybe something has changed? > > Looking at our docu, we don't seem to have any curl REST examples. > > Cheers, > Galder > > [1] https://developer.jboss.org/thread/274501 > [2] https://gist.github.com/galderz/21997d4b673908943a11a38c51d4cc9d > _______________________________________________ > 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/20171207/1337de31/attachment.html From slaskawi at redhat.com Fri Dec 8 05:15:07 2017 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Fri, 08 Dec 2017 10:15:07 +0000 Subject: [infinispan-dev] Data format not supported with REST In-Reply-To: References: Message-ID: Hey Galder, Curl adds "Accepts: */*" header, which is not supported at the moment. I would call it a bug and I think we should fix it in https://issues.jboss.org/browse/ISPN-8566. @Gustavo - WDYT? Thanks, Sebastian On Thu, Dec 7, 2017 at 7:38 PM Galder Zamarre?o wrote: > > Hey Tristan, > > I was trying your REST curl example in [1], but I'm getting "Data format > not supported" error when doing a get. See output in [2]. > > I'm using 9.1.0, maybe something has changed? > > Looking at our docu, we don't seem to have any curl REST examples. > > Cheers, > Galder > > [1] https://developer.jboss.org/thread/274501 > [2] https://gist.github.com/galderz/21997d4b673908943a11a38c51d4cc9d > _______________________________________________ > 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/20171208/b4df4f81/attachment-0001.html From gustavo at infinispan.org Fri Dec 8 05:27:45 2017 From: gustavo at infinispan.org (Gustavo Fernandes) Date: Fri, 8 Dec 2017 10:27:45 +0000 Subject: [infinispan-dev] Data format not supported with REST In-Reply-To: References:

Message-ID: On Fri, Dec 8, 2017 at 10:15 AM, Sebastian Laskawiec wrote: > Hey Galder, > > Curl adds "Accepts: */*" header, which is not supported at the moment. I > would call it a bug and I think we should fix it in > https://issues.jboss.org/browse/ISPN-8566. > > @Gustavo - WDYT? > +1, thanks for locating the JIRA, I'll make sure to have it fixed in 9.1. In the meantime, putting the "Accept" header is a valid workaround. Thanks, Gustavo > Thanks, > Sebastian > > On Thu, Dec 7, 2017 at 7:38 PM Galder Zamarre?o wrote: > >> >> Hey Tristan, >> >> I was trying your REST curl example in [1], but I'm getting "Data format >> not supported" error when doing a get. See output in [2]. >> >> I'm using 9.1.0, maybe something has changed? >> >> Looking at our docu, we don't seem to have any curl REST examples. >> >> Cheers, >> Galder >> >> [1] https://developer.jboss.org/thread/274501 >> [2] https://gist.github.com/galderz/21997d4b673908943a11a38c51d4cc9d >> _______________________________________________ >> 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/20171208/27df2991/attachment.html From ttarrant at redhat.com Mon Dec 11 10:45:23 2017 From: ttarrant at redhat.com (Tristan Tarrant) Date: Mon, 11 Dec 2017 16:45:23 +0100 Subject: [infinispan-dev] Weekly IRC Meeting logs 2017-12-11 Message-ID: <8b7b2f5b-8abe-fee1-9e1d-296392cc8b82@redhat.com> @All, the weekly meeting logs are available for your perusal here: http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2017/infinispan.2017-12-11-15.01.log.html Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From karesti at redhat.com Tue Dec 12 11:11:00 2017 From: karesti at redhat.com (Katia Aresti) Date: Tue, 12 Dec 2017 17:11:00 +0100 Subject: [infinispan-dev] First article about Vert.x and Infinispan Message-ID: Hi all, I've published a first article here http://blog.infinispan.org/2017/12/first-steps-with-vertx-and-infinispan-rest-api.html This tutorial is for beginners. I have a second tutorial that covers PUSH API that will be published in two days. I've done a split because the blog post was a bit too big for a single post. Thank you Galder and Thomas S for the review ! If you see anything that should be changed, please, contact me ! Cheers, Katia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20171212/e1279bc0/attachment.html From galder at redhat.com Wed Dec 13 11:16:53 2017 From: galder at redhat.com (Galder Zamarreno) Date: Wed, 13 Dec 2017 17:16:53 +0100 Subject: [infinispan-dev] First article about Vert.x and Infinispan In-Reply-To: References: Message-ID: Great article!! Thanks ? On Tue, Dec 12, 2017 at 5:11 PM, Katia Aresti wrote: > Hi all, > > I've published a first article here > > http://blog.infinispan.org/2017/12/first-steps-with- > vertx-and-infinispan-rest-api.html > > This tutorial is for beginners. I have a second tutorial that covers PUSH > API that will be published in two days. I've done a split because the blog > post was a bit too big for a single post. > > Thank you Galder and Thomas S for the review ! > > If you see anything that should be changed, please, contact me ! > > Cheers, > > Katia > > > _______________________________________________ > 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/20171213/6e4b4e85/attachment.html From karesti at redhat.com Thu Dec 14 14:21:35 2017 From: karesti at redhat.com (Katia Aresti) Date: Thu, 14 Dec 2017 20:21:35 +0100 Subject: [infinispan-dev] 2nd article about Vert.x and Infinispan Message-ID: Hi all, I've published the 2nd article of my tutorial ! *http://blog.infinispan.org/2017/12/first-steps-with-vertx-and-infinispan-push-api.html * If you see anything that should be changed, please, contact me ! Cheers, Katia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20171214/840958e8/attachment.html From tsegismont at gmail.com Fri Dec 15 01:46:09 2017 From: tsegismont at gmail.com (Thomas SEGISMONT) Date: Fri, 15 Dec 2017 07:46:09 +0100 Subject: [infinispan-dev] 2nd article about Vert.x and Infinispan In-Reply-To: References: Message-ID: Great work Katia! Le 14 d?c. 2017 23:09, "Katia Aresti" a ?crit : > Hi all, > > I've published the 2nd article of my tutorial ! > > *http://blog.infinispan.org/2017/12/first-steps-with-vertx-and-infinispan-push-api.html > * > > > If you see anything that should be changed, please, contact me ! > > Cheers, > > Katia > > _______________________________________________ > 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/20171215/29709d45/attachment.html From rory.odonnell at oracle.com Mon Dec 18 05:18:21 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 18 Dec 2017 10:18:21 +0000 Subject: [infinispan-dev] JDK 10 entered Rampdown Phase One on 14th of December Message-ID: <107acad0-4ef2-af71-bc4d-9c529deceee8@oracle.com> ?Hi Galder, *JDK 10 entered Rampdown Phase One on Thursday, 14 December [1] * * The Rampdown Phase One process will be similar to that of JDK 9 [2]. *JDK 10 Early Access? build 36 is available at : - jdk.java.net/10/* Notable changes since previous email. *JEPS included **the last 3 builds:* JDK-8192833 :This is the primary implementation subtask of JEP 322 - *Time-Based Release Versioning* JDK-8189941 : Implementation JEP 312: Thread-local handshake JDK-8186571 : Implementation: JEP 307: Parallel Full GC for G1 JDK-8190308 : Implementation: JEP 316: Heap Allocation on Alternative Memory Devices *build 36 *JDK-8148421 : Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension JDK-5016517 : Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent ** *build 35 * JDK-8188870 - Bump classfile version number to 54 JDK-8185985 - HTML files in doc-files subdirectories are wrapped with standard javadoc decorations JDK-8186535 *- *Remove deprecated pre-1.2 SecurityManager methods and fields *build 34* - JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" *Bug fixes reported by Open Source Projects? :* JDK-8191078 : Wrong "Package not found" warning JDK-8191636 : [Windows] jshell tool: Wrong character in /env class-path command crashes jshell JDK-8191834 : Assigning a void expression to a "var" crashes the compiler JDK-8182638 : [macosx] Active modal dialog is hidden by another non-active one JDK-8043315 : Nimbus: Setting Nimbus.Overrides property affects custom keymap installation JDK-8172244 : AIOOBE in KeyStore.getCertificateAlias on Windows JDK-8180141 : Missing entry in LineNumberTable for break statement that jumps out of try-finall JDK 10 Schedule, Status & Features are available [3] *Feedback* - If you have suggestions or encounter bugs, please submit them using the usual Java SE bug-reporting channel. Be sure to include complete version information from the output of the |java --version| command. Regards, Rory [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-December/000357.html [2] http://openjdk.java.net/projects/jdk9/rdp-1 [3] http://openjdk.java.net/projects/jdk/10/ -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20171218/968519c8/attachment-0001.html From remerson at redhat.com Mon Dec 18 11:45:49 2017 From: remerson at redhat.com (Ryan Emerson) Date: Mon, 18 Dec 2017 11:45:49 -0500 (EST) Subject: [infinispan-dev] 9.2.0.Beta2 Released In-Reply-To: <196425908.360993.1513614623418.JavaMail.zimbra@redhat.com> References: <196425908.360993.1513614623418.JavaMail.zimbra@redhat.com> Message-ID: <248620979.365271.1513615549948.JavaMail.zimbra@redhat.com> Hi all, I am pleased to announce that we have released 9.2.0.Beta2. Blog post: http://blog.infinispan.org/2017/12/infinispan-920beta2-released.html Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310799&version=12335608 Regards Ryan From remerson at redhat.com Tue Dec 19 08:44:53 2017 From: remerson at redhat.com (Ryan Emerson) Date: Tue, 19 Dec 2017 08:44:53 -0500 (EST) Subject: [infinispan-dev] Infinispan 9.1.4.Final Released In-Reply-To: <1478536875.564772.1513691015403.JavaMail.zimbra@redhat.com> Message-ID: <848919699.566067.1513691093750.JavaMail.zimbra@redhat.com> Hi Everyone, I am please to announce that 9.1.4.Final has been released. Blog post: http://blog.infinispan.org/2017/12/infinispan-911final-released.html Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310799&version=12336151 Regards Ryan