>if (key == null) {
>return createNewEntity();
>} else {
>Map map = service.get(null,
> Collections.singleton(key));
>if (map.isEmpty()) {
>return createNewEntity();
> } else {
>
The much awaited 5.2.CR1 is now out!
More about it here:
http://infinispan.blogspot.co.uk/2013/01/infinispan-520cr1-is-out.html
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> ma...@jboss.org
> twitt
new
> branch where we can merge such works.
>
> Same question for the Lucene4 support, which also will be ready soon.
>
> Cheers,
> Sanne
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.
new
> branch where we can merge such works.
>
> Same question for the Lucene4 support, which also will be ready soon.
>
> Cheers,
> Sanne
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.
s an experimental feature in 5.2: the reason
> is we have other work to move forward which needs a tagged version of
> the MongoDB Cachestore; there are some volunteers stalled waiting on
> this so I'm afraid that delaying it too much will turn them off.
>
> On 14 January 2013 14:
More about it here:
http://infinispan.blogspot.co.uk/2013/01/infinispan-520cr2-is-out.html
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman
then be updated as a pull request.
All sounds good! Not sure how Disqus would be used though - instead of github
annotations?
This is my understanding on how docs will be updated:
- when a functionality is changed the documentation(/src/docs) is
updated in the same p
r is big enough and
there's no key affinity, keeping data in binary format reduces the number of
times it is marshalled/unmarshalelled.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
n/language.oop5.traits.php
>
> MySQL has something similar:
>
> http://dev.mysql.com/doc/refman/5.5/en/create-database.html
> http://dev.mysql.com/doc/refman/5.5/en/drop-index.html
+1. Thanks for the clarification.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_
;
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> ___
> infinispan-dev mailing list
&
________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
In order to accommodate some critical bug fixes, $Subject.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
On 29 Jan 2013, at 14:08, Dan Berindei wrote:
> Very nice, looking forward to the Lucene bench results.
>
> I hope you'll run it with a distributed cache as well!
+1 :-)
Cheers,
--
Mircea Markus
Infinispan lead (www.
n of scala code to java, but about the very
specific contribution described above (even thought the mix of scala+java code
in ISPN is a a very interesting topic by itself).
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infi
On 31 Jan 2013, at 11:53, Manik Surtani wrote:
>
> On 31 Jan 2013, at 11:45, Mircea Markus wrote:
>
>> Hi,
>>
>>
>> The REST module is written in Scala (both main + tests). We have some *test*
>> contributions written in Java (thanks mlinhard).
&g
ine.
>
> I'd like to have an oportunity to add a Java test if it's something more
> complex in the future. - in cases where advantages and quickness of
> availability of java unit test outweigh the unniceness of the mixing.
>
> So +1 for allowing java test cas
hat because of Scala
language enhancements used in ISPN.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
with Java, although the
> server is probably not such a big problem as it is a standalone and
> independent subsystem.
>
> my 5 cents,
>
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
On 31 Jan 2013, at 12:47, Bela Ban wrote:
> On 1/31/13 1:37 PM, Manik Surtani wrote:
>>
>> On 31 Jan 2013, at 12:35, Mircea Markus > <mailto:mmar...@redhat.com>> wrote:
>>
>>> I don't think that encouraging scala code is good purely for
>>
On 31 Jan 2013, at 13:14, Manik Surtani wrote:
> On 31 Jan 2013, at 12:47, Bela Ban wrote:
>
>>
>> On 1/31/13 1:37 PM, Manik Surtani wrote:
>>>
>>> On 31 Jan 2013, at 12:35, Mircea Markus >> <mailto:mmar...@redhat.com>> wrote:
>>
On 31 Jan 2013, at 14:12, Manik Surtani wrote:
> On 31 Jan 2013, at 13:55, Mircea Markus wrote:
>
>> *Also as a java developer you have the general option of not learning Scala,
>> but you don't really have the option of not keeping up with Java8.
>
> So you ge
/ac0XD
[2] https://community.jboss.org/wiki/Non-BlockingStateTransferV2
[3] https://docs.jboss.org/author/display/ISPN/Cross+site+replication
[4] https://issues.jboss.org/browse/ISPN-1410
[5] http://goo.gl/zZVyF
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org
ut a 5.2.x branch of master. Please make sure the relevant fixes would be
contributed to both master (5.3) and back ported to 5.2.x (at this stage this
shouldn't be more than cherry-picking of the commits to the other branch).
[1] http://goo.gl/q7EKk
Cheers,
--
Mircea Markus
Infinispan
>
> Software Engineer
> JBoss SET
> JBoss EAP
>
> Twitter: @navssurtani
> Blog: navssurtani.blogspot.com
>
> From: "Dan Berindei"
> To: "infinispan -Dev List"
> Cc: "Mircea Markus"
> Sent: Monday, February 4, 2013 6:23:44 PM
> Su
On 1 Feb 2013, at 14:57, Michal Linhard wrote:
> On 01/31/2013 01:37 PM, Mircea Markus wrote:
>>
>> On 31 Jan 2013, at 12:28, Michal Linhard wrote:
>>
>>>
>>> In this special case I'm gonna try to rewrite the test case as an
>>> excercise
I might not want to - as an ISPN programmer - is to keep up with the
>> language enhancements in Scala. And I might need to do that because of Scala
>> language enhancements used in ISPN.
>
> ^ I wonder whether C programmers thought the same way 20 years ago.
Personally I don&#
Following the tradition, please bring your suggestion of beer-code name for the
new Infinispan release. Then we'll vote.
Mine is Guinness :-)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infin
ss Datagrid
> tel. +420532294559 ext. 62559
>
> Red Hat Czech, s.r.o.
> Brno, Purkyňova 99/71, PSČ 612 45
> Czech Republic
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailm
ssage could block in the
> | > other node is really, really hard (we can be sure only in case of
> | > RPC responses), especially when some locks come. I will welcome
> | > anything better.
> |
> | --
> | Bela Ban, JGroups lead (http://www.jgroups.org)
> |
> | _
ed be the TO code that we'll integrate in 5.3. Se in order to have TO in
ISPN we need these jgroups improvements in. Pedro - are there any other
modifications in *your branch* of jgroups that require integration into jgroups
upstream from a TO
Hi Bela,
Do you think we can have this particular improvement in JGroups by 18 Feb? That
week Pedro, Dan and I are going to start integrating TO protocols in ISPN and
this is a requirement for it.
On 8 Feb 2013, at 12:41, Pedro Ruivo wrote:
> On 2/8/13 12:26 PM, Mircea Markus wr
On 8 Feb 2013, at 14:31, Bela Ban wrote:
>
> On 2/8/13 3:23 PM, Mircea Markus wrote:
>> Hi Bela,
>>
>> Do you think we can have this particular improvement in JGroups by 18
>> Feb? That week Pedro, Dan and I are going to start integrating TO
>> protocols i
release in any real-life deployment, so we'll release 5.2.1.Final today.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infin
I've created a JIRA in the scope of Infinispan 5.3 to track the thread pool
improvements discussed in this email thread:
ISPN-2808 - Make Infinispan use its own thread pool for sending OOB messages in
order to avoid thread deadlocks
On 8 Feb 2013, at 14:44, Mircea Markus wrote:
>
&g
weeks release cycles after that with 4 Betas
- 2 CRs 1 + 1/2 weeks in between (code freeze)
- final on the 31 May
[1] http://goo.gl/cSWEz
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@l
Sometimes democracy gets funny: "Tactical Nuclear Penguin" is the name of our
next 5.3 release[1].
It's worth mentioning we have a tie: "Hopocalypse"being the alternative. Let's
use this one for our next release.
[1] https://community.jboss.org/polls/1115
Cheers
n 12 February 2013 14:06, Radoslav Husar wrote:
>>> Oh boy! Now we are serious competition to Fedora codenames. Their last
>>> name one is "Spherical Cow".
>>>
>>> Rado
>>>
>>> On 11/02/13 17:50, Mircea Markus wrote:
>>>&g
is
this needed for debugging state transfer issues? If so +1 for managing it with
the verbose flag.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
tp://red.ht/data-grid
> | |
> | |
> | ___
> | infinispan-dev mailing list
> | infinispan-dev@lists.jboss.org
> | https://lists.jboss.org/mailman/listinfo/infinispan-dev
> |
> |
> | __
Y have an
(significant) impact over embedded client.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Engineer, Infinispan
> http://infinispan.org
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_
On 25 Feb 2013, at 19:51, Ales Justin wrote:
> What if you just make this a component inside ISPN?
+1, as this pertains to ISPN.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-
; https://issues.jboss.org/browse/ISPN-2281
>
> Cheers,
> --
> Galder Zamarreño
> gal...@redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
>
> _
locks. can this meaning a problem with UNICAST3 or I had just lucky?
>
> Any other suggestion?
>
> Cheers,
> Pedro
>
>
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
he performance increase for writes is huge. I think this should be
the default, as read efficiency can be improved by L1.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://l
1 for consistency.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
On 26 Feb 2013, at 10:51, Manik Surtani wrote:
> In any case, whatever we decide, we (a) need something in place and (b) need
> it fast (pre-5.2.2), so that it is in JDG 6.1.GA.
>
> Do we have a JIRA for this?
here you go: https://github.com/infinispan/infinispan/pull/1683
Cheers
and seems to be a good candidate as it might acquire locks
-IndexUpdateCommand/ClusterQueryCommand - I'll let Sanne comment on these two,
which might require an update on query module as well
- MapCombineCommand if a cache loader is present (it iterates over the entries
in the loader)
Dan/A
> And put this new interceptor after the InvocationContextInterceptor?
we shouldn't create an interceptor yet, perhaps we'll do that with ISPN-2849.
>
> My opinion, it to dispatch the command to a new thread before invoking
> command.perform() in order to avoid to move so
try
> command.perform
> transport.sendResponse
> catch Thowable t
> transport.sendResponse(ExceptionResponse)
>
If it's only for this try-catch duplication then it should be fine.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
oughts?
>
> Cheers,
> --
> Galder Zamarreño
> gal...@redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
>
> _______
> infinispa
evaluation.
that's only if you have write skew check enabled.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
st
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Ma
oon as we have CI to check that Dan's commits to Infinispan don't
>> break Infinispan Server :)
>
> Speaking of CI, where are we with that?
I'm looking into it as we speak.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
__
to me like each node was favouring use of the CacheLoader
>>>>>> to retrieve keys that are not in memory, instead of using the cluster.
>>>>>> Does that seem reasonable? Is this the expected behaviour?
>>>>>>
>>>>>> I started to investigate this by turning on trace logging, in th
he last 24 hours from browsing the code, so I
>>> could easily be way off. I've attached the log snippets I thought
>>> relevant in [2].
>>>
>>> Any advice offered much appreciated.
>>> Thanks!
>>>
>>> James.
>>>
>>>
>>> [1] https://www.refheap.com/paste/12531
>>> [2] https://www.refheap.com/paste/12543
>>> ___
>>> infinispan-dev mailing list
>>> infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
one should
> only preload metadata, while in the original configuration this data
> would indeed be duplicated.
> Opened: https://issues.jboss.org/browse/ISPN-2938
>
> Sanne
>
> On 19 March 2013 11:51, Mircea Markus wrote:
>>
>> On 16 Mar 2013, at 01:19, Sanne Gri
ertain
> elements too. But nice you spotted the need to potentially filter what
> "preload" means in the scope of each cache, as the metadata one should
> only preload metadata, while in the original configuration this data
> would indeed be duplicated.
> Opened: https://
> extra cache store lookup.
I think the rule for going to the caches store should be based on key locality
- if the key does not map to the local node, then don't involve the store at
all locally, but delegate the store interaction to actual owner.
Cheers,
--
Mircea Markus
Infinispan
On 19 Mar 2013, at 15:17, Manik Surtani wrote:
>
> On 19 Mar 2013, at 15:07, Sanne Grinovero wrote:
>
>>
>>
>> - Original Message -
>>>
>>> On 19 Mar 2013, at 12:21, Mircea Markus wrote:
>>>
>>>> On 19 Mar 2013, a
ed as part of the
> put/replace…etc (I will email this around when in place).
>
> Cheers,
> --
> Galder Zamarreño
> gal...@redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Inf
inispan
> http://infinispan.org
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
some lock.
>
> Any other suggestions? If I was not clear let me know.
can't we reuse the lock-dependency graph from total order for this as well?
>
> Thanks.
>
> Cheers,
> Pedro
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://l
needs to be serizlized in the caller's thread for either the
bundler or FRAG2
>
> Cheers
> Dan
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mirce
mgroups=#!topic/lmax-disruptor/t7Hr8qY400E
thanks, good to know :-)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
any other suggestion?
> (I do have the security limits setup properly)
>
> Sanne
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
y, so what this
behaviour does is just to increase the inconsistency window.
On 19 Mar 2013, at 16:30, Mircea Markus wrote:
>
> On 19 Mar 2013, at 16:15, Dan Berindei wrote:
>
>> Hi Sanne
>>
>> On Tue, Mar 19, 2013 at 4:12 PM, Sanne Grinovero
>> wrote:
&g
ain an OOM (while I have 2GB !), last sign of life came
> > from the "Rolling Upgrade Tooling"
> >
> > I'm not going to merge/review any pull request until this works.
> >
> > Sanne
> >
> > On 20 March 2013 12:09, Mircea Markus wrote:
> >
ct
- would whit work with REST as well?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
rom the server and
>> deserialize it with Avro into a C++ "Person" object
>
> Yes, it should. And good idea, this will help us test cross-platform without
> a requirement for more Hot Rod clients at this stage.
+1
Ch
ion$1.run(AbstractListenerImpl.java:212)
> ... 31 more
>
> Sanne
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
Thanks dude!
On 5 Apr 2013, at 14:40, Manik Surtani wrote:
> Never mind, I had a few mins waiting for a delayed meeting to start ...
>
> https://github.com/infinispan/infinispan/pull/1753
> https://github.com/infinispan/infinispan/pull/1754
Cheers,
--
Mircea Markus
Inf
.0_17"
>> > Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
>> > Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
>> >
>> > this time again an OOM (while I have 2GB !), last sign of life came
>> > from the "Rolling Upgrade Tool
On 8 Apr 2013, at 10:02, Manik Surtani wrote:
>> I've upgrade to mvn 2.14
>
> You mean Surefire 2.14. You had me confused for a bit, since I'm pretty sure
> we enforce mvn 3.x. ;)
yep, surefire 2.14 :-)
Cheers,
--
Mircea Markus
Infinispan
ld take a look.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>> ./standalone.sh -c standalone-capedwarf.xml -b
>> -Djboss.node.name=some_name
>>
>> (8) deploy the app / ROOT.war
>>
>> ---
>>
>> Deploy this on a few nodes, goto browser: http://,
>> add a few flights and see how
g.infinispan.interceptors.InvocationContextInterceptor
would tell what you add to the cache so we can validate/invalidate 4.
>
> Sanne
> ___
> infinispan-dev mailing list
> infinispan-d
time the XSD was generated,
but not these days. Any cons for not dropping this?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/lis
Highlights:
- total order protocol for transactions
- JSR-107 support
- Lucene directory implementation based on Lucene 4
- packaging for the Infinispan server modules
Wanna know more?
http://infinispan.blogspot.co.uk/2013/04/infinispan-530alpha1-is-out.html
Cheers,
--
Mircea Markus
Infinispan
so I'd prefer we keep
>> it, or build a similar output in a different way.
>>
> Sanne, I'm already looking into building it in a different way.
Based on the XSD?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
ave two ways of doing the same thing.
Thoughts?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
overhead. The former
seems complex, doesn't scale(requires the implementation of indexing for every
programming language) and limiting (indexes need to be defined a priori,
cannot query for non-indexed data).
>
> Cheers
> Manik
>
> On 10 Apr 2013, at 17:11, Mircea Marku
sure JSON should be the format though. As you said it's quite
> verbose and string is not exactly the most efficient way to process
> data.
+1 to all the points above.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
d protocol which was
> supervised by Mircea Markus.
> I was able to develop the library upto Intelligence Level 2 (Topology Aware
> Client) and we released beta1 version[2].
>
> This summer also, I'm interested in contributing to Infinispan as a GSoC
> intern.
great to hear th
/20/2013 01:27 PM, Sanne Grinovero wrote:
>>>> I'm testing master, at da5c3f0
>>>>
>>>> Just killed a run which was using
>>>>
>>>> java version "1.7.0_17"
>>>> Java(TM) SE Runtime Environment (build 1.7.0_17
On 19 Apr 2013, at 08:47, Dan Berindei wrote:
> +1 to make CHMv8 the default on JDK6 and JDK7
+1
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.
r is willing to look at it.
We have quite some bugs that need fixing first, then performance :)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
On 22 Apr 2013, at 10:34, Dan Berindei wrote:
> Do you really need to set the classloader in all the cache configurations? I
> thought it was enough to set it in the global configuration.
That's what I thought as well.
Cheers,
--
Mircea Markus
Infinispan lead (www.inf
Infinispan in an isolated classloader.
>
> Maybe we should have an (optional) Parser API which takes explicit
> classloaders ?
+1
When reading the metadata only, wouldn't it make sense to try and use both
context and (fallback) class's class loaders? Would that solve the issue y
;>> read. I think some of the anti-collision features in V8 might come
>>>>> into
>>>>> play under some circumstances though which might affect performance in
>>>>> a
>>>>> negative way (wrt the constant big-O component) but overall in a
On 22 Apr 2013, at 13:16, Sanne Grinovero wrote:
> On 22 April 2013 12:07, Mircea Markus wrote:
>>
>> On 19 Apr 2013, at 18:02, Sanne Grinovero wrote:
>>
>>> It turns out this resource loading issue is biting also community users;
>>>
>>> I ha
r size of at least N
> if you want to reduce inconsistency in your grid during partitions.
would the read only partition be wiped out and repopulated during merge?
Otherwise not sure how useful this is as there'll still going to be
inconsistencies in the cluster, the same way the
n't have any data, then delete everything from the
>> cache store that is not mapped to the node in the consistent hash. Obviously
>> that can lead to consistency problems, just like our current merge
>> algorithm. It would be nice if we could handle both these cases the sa
> algorithm. It would be nice if we could handle both these cases the same way.
+1. The cache store is the equivalent of the read only partition.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
ink consistency is preserved in at least the following situations:
- the read-only partition has more than numOwner members. Reads in the active
partition would miss data. Also the conditional operation, that rely on
existing data, perform incorrectly.
- data is deleted in the active
span.org
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
t as far as keeping the
hash together with the key. Also this is an optimisation so we shouldn't go out
of our way in order to implement it.
> Sorry Galder, I forgot about your patch, but I still think we'd need a
> wrapper for keys in order to cache the hash code even if we co
d_pool.queue_enabled="false". If I enable queuing for my async
>> replication use case, my performance for sync very much degrades. But I
>> can easily flood/abuse the incoming thread pool if I disable queuing –
>> i.e. messages get dropped (XSite replic
1 - 100 of 1272 matches
Mail list logo
