Is this the issue, Bela?
https://issues.jboss.org/browse/JGRP-1116
Thanks,
Alan
- Original Message -
> From: "Galder Zamarreño"
> To: "infinispan -Dev List"
> Sent: Monday, August 14, 2017 9:04:50 AM
> Subject: Re: [infinispan-dev] Hot Rod client sending data to itself -
> ISPN-8186
>
Hey Sebastian,
I completely agree that hosting [1] in the /rest context is superior to [2]. I
think that is what you are proposing, right? :-)
Thanks,
Alan
- Original Message -
> From: "Sebastian Laskawiec"
> To: "infinispan -Dev List"
> Sent: Tuesday, June 13, 2017 9:10:40 AM
>
I read it, and now I am infected!
- Original Message -
> From: "Tristan Tarrant"
> To: "infinispan -Dev List"
> Sent: Friday, June 9, 2017 9:10:25 AM
> Subject: [infinispan-dev] Test. Don't read.
>
> I told you not to read it.
> ___
> infinisp
ibuted infinispan-embedded uberjar
> and infinispan-embedded umbrella artifact.
>
> Radim
>
> On 06/08/2017 08:04 PM, Alan Field wrote:
> > Wasn't the ability to add a single dependency to a project to start using
> > Infinispan the whole purpose for the uber jars
Wasn't the ability to add a single dependency to a project to start using
Infinispan the whole purpose for the uber jars? I'm not trying to make an
argument for keeping them, because I know they have caused many issues. I just
think that if we are going to remove them from Maven, then there shou
As confusing as this is, I agree with Tristan! :-)
- Original Message -
> From: "Tristan Tarrant"
> To: "infinispan -Dev List" , "Jiri Holusa"
>
> Sent: Friday, May 5, 2017 11:12:31 AM
> Subject: Re: [infinispan-dev] Documentation code snippets
>
> +1 for #2 from me too
>
> Tristan
>
- Original Message -
> From: "Pedro Ruivo"
> To: "ispn-dev"
> Sent: Wednesday, February 22, 2017 9:59:21 AM
> Subject: [infinispan-dev] Default TCP configuration is broken.
>
> Hi team,
>
> The 'default-jgroups-tcp.xml" has MFC protocol without the FRAG2/3
> protocol. This is broken w
- Original Message -
> From: "Gustavo Fernandes"
> To: "infinispan -Dev List"
> Sent: Friday, September 30, 2016 5:58:27 AM
> Subject: Re: [infinispan-dev] Hot Rod testing
> > I wonder if something like Haxe [1] could help here in defining a language
> > agnostic
>
> > TCK (maybe an sk
Hey Galder,
- Original Message -
> From: "Galder Zamarreño"
> To: "infinispan -Dev List"
> Sent: Friday, September 23, 2016 11:33:12 AM
> Subject: Re: [infinispan-dev] Hot Rod testing
>
>
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
> > On 15 Sep 2016, at 13:58, Sebastian Laskawiec
I also like this idea for a Unit-Based TCK for all clients, if this is possible.
> - we identify and group the tests depending on their scope (basic
> protocol ops, bulk ops, topology/failover, security, etc). A client
> which implements the functionality of a group MUST pass all of the tests
> in
- Original Message -
> From: "Bela Ban"
> To: infinispan-dev@lists.jboss.org
> Sent: Tuesday, September 6, 2016 11:14:48 AM
> Subject: [infinispan-dev] Doing my part to shed weight...
>
> I'm currently training for a half-marathon in November and need to lose
> some weight, so I thought
A little late to the discussion but if all of the pods share the same set of
volumes, couldn't you also use the FILE_PING discovery protocol between the
pods?
Thanks,
Alan
- Original Message -
> From: "Sebastian Laskawiec"
> To: "infinispan -Dev List" , "Bela Ban"
> , "Kevin Conner
Hey,
We have a new inter starting on the JDG QE team. Martin Vrábel will be working
with the remotely from Prague where he is at Czech Technical University.
Please welcome Martin to the team!
Thanks,
Alan
BTW, Martin picked a position on Infinispan over Kubernetes!
--
Alan Field
Supervisor
in a chart, or fail the build if the value of the
> metric increases too much (like we have now for the test duration). It
> does sound interesting, but I'm not sure where you guys got the idea
> that a failed build will prevent a PR from being integrated ;)
>
> Cheers
> Dan
I really like the idea of "forcing a trend of improvement"! :-) I agree with
Radim that getting the improvement in the code is the hard part. Running static
analysis tools on the files you are modifying is a great way to tackle the
problem in a manageable fashion. Looking at all of the output ac
come to a solution that is more automatic than the current
state. Removing JAXB may have been the correct decision, but the replacement
seems to have created a bigger maintenance problem.
Thanks,
Alan
- Original Message -
> From: "Alan Field"
> To: "infinispan -Dev
; and the code...Part One
>
> On 16/09/14 12:04, Alan Field wrote:
> > Hey,
> >
> > I have been looking at the differences between default values in the XSD vs
> > the default values in the configuration builders. [1] I created a list of
> > differences and tal
Hey,
I have been looking at the differences between default values in the XSD vs the
default values in the configuration builders. [1] I created a list of
differences and talked to Dan about his suggestion for the defaults. The
numbers in parentheses are Dan's suggestions, but he also asked me
Hey Bela,
> Just a quick heads up. I'm currently working on
> https://issues.jboss.org/browse/JGRP-1877, which it critical as it may:
> - cause RPCs to return prematurely (possibly with a TimeoutException), or
> - cause RPCs to blocks for a long time (pick which one is worse :-))
How frequently c
these special
> categories (and sometimes moved from DEBUG to INFO).
> Cheers
> Dan
> On Tue, Aug 12, 2014 at 3:20 PM, Alan Field < afi...@redhat.com > wrote:
> > I would also propose these categories for log messages:
>
> > org.infinispan.QUERY
>
> &g
I would also propose these categories for log messages:
org.infinispan.QUERY
org.infinispan.MAPREDUCE
org.infinispan.DISTEXEC
Thanks,
Alan
- Original Message -
> From: "Tristan Tarrant"
> To: "infinispan -Dev List"
> Sent: Tuesday, August 12, 2014 10:35:34 AM
> Subject: [infinispan-dev
that's not the case.
Sorry for the noise, and for my confusion.
Thanks,
Alan
- Original Message -
> From: "Alan Field"
> To: "infinispan -Dev List"
> Sent: Tuesday, July 29, 2014 9:53:42 AM
> Subject: Re: [infinispan-dev] Cache.size()
issues) or state transfer while you did the
> map/reduce task and had it based on if passivation was enabled or not
> (a bit messy but doable).
>
> The distributed iterator should work irrespective of configuration or
> concurrent operations though.
>
> On Fri, Jul 25, 2014
changed in a way
> > that i would report full cache size, not just the size of container/the
> > size of cache store?
> >
> > Radim
> >
> > On 07/25/2014 03:54 PM, Alan Field wrote:
> >> Hey,
> >>
> >> I have been looking at adding the abil
[2]
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-radargun-gettotalcachesize-test/6
--
Alan Field
Principal Quality Engineer - JBoss Data Grid
T: (919) 890-8932 | Ext. 8148932
___
infinispan-dev mailing list
infinispan-dev@lists.jboss
- Original Message -
> From: "Martin Gencur"
> To: "infinispan -Dev List"
> Sent: Friday, June 13, 2014 7:36:10 AM
> Subject: Re: [infinispan-dev] Issue with JGroups config files in ispn-core
>
> On 12.6.2014 20:14, Tristan Tarrant wrote:
> > On 12/06/14 18:46, Dennis Reed wrote:
> >>
Tristan,
So the server and library configuration parsers will handle something like this?
If this is true, then I agree that this is a good solution as well.
Thanks,
Alan
- Original Message -
> From: "Tristan Tarrant"
> To: "infinispan -Dev List"
> Sent: Thursday,
Chocolate Rain [1]
*That name also comes with a theme song! [2]
Alan
[1] http://www.beeradvocate.com/beer/profile/16866/53728/
[2] https://www.youtube.com/watch?v=EwTZ2xpQwpA&feature=kp
- Original Message -
> From: "Mircea Markus"
> To: "infinispan -Dev List"
> Sent: Wednesday, June 4
For Map/Reduce v1 this is definitely the case:
https://hadoop.apache.org/docs/r1.2.1/mapred_tutorial.html#Task+Execution+%26+Environment
" The TaskTracker executes the Mapper / Reducer task as a child process in a
separate jvm. "
I believe this is also the case for Map/Reduce v2, but I have
Hey,
First off, I think integrating Infinispan with Hadoop using the InputFormat and
OutputFormat interfaces is a really good idea, instead of using the file system
interfaces. That's the approach that Gluster is using, but I don't think it's
ideal for Infinispan.
> So to clarify, we will have
Yes! Congratulations Radim on defeating Maven's Release Plugin!
- Original Message -
> From: "Radim Vansa"
> To: "infinispan -Dev List"
> Sent: Thursday, February 20, 2014 9:40:41 AM
> Subject: [infinispan-dev] RadarGun 1.1.0.Final released
>
> Hi all,
>
> it has been a long time since
ormant than the older one, but it eliminates the
> need to use DONT_BUNDLE (old: OOB), as single messages will be sent
> immediately. For example, sync RPCs now don't need to be marked as OOB /
> DONT_BUNDLE any longer
>
> On 6/5/13 4:39 PM, Alan Field wrote:
> > Thanks,
he 3.2.x bundler). The 3.3.x bundler is more efficient though
>
> On 6/5/13 4:15 PM, Alan Field wrote:
> > Sorry, not sure where I was getting 2.7.x, I meant 3.2.x. (The version
> > included with Infinispan 5.2)
> >
> > Sorry,
> > Alan
> >
> > ---
ev] Infinispan 5.3 and the new JGroups bundler
>
>
>
> On 6/5/13 3:51 PM, Alan Field wrote:
> > Hey Pedro,
> >
> >>> 1) What is the default bundler used in JGroups 2.7.x?
> >>
> >> Bela is the right person to answer this, but I think the new bu
be ignored?
Thanks,
Alan
- Original Message -
> From: "Pedro Ruivo"
> To: infinispan-dev@lists.jboss.org
> Sent: Wednesday, June 5, 2013 9:47:51 AM
> Subject: Re: [infinispan-dev] Infinispan 5.3 and the new JGroups bundler
>
> Hi Alan,
>
> On 06/05/201
Hey Pedro,
I have a couple of questions for you about this.
1) What is the default bundler used in JGroups 2.7.x?
2) Are there any issues with running versions of Infinispan < 5.3 with the new
bundler?
Thanks,
Alan
- Original Message -
> From: "Pedro Ruivo"
> To: "ispn-dev"
> Sent:
36 matches
Mail list logo
