On 29 Jan 2013, at 18:27, Mircea Markus wrote:
> I guess Bela's question was about why System. currentTimeMillis() would
> trigger a context switch, I'm also curious about that one :-)
On its own it doesn't. But if we have a cached clock with a scheduled thread
updating that cached value per
IIRC, aggregating JavaDocs like that causes a mess of the build system, because
everything will be built and tests run twice. See
https://issues.jboss.org/browse/MODE-1104 for background (including the
pull-request). It's probably not easy to figure out how it works, but I could
explain it fair
The javadoc of Infinispan does not have references to the Hibernate
Search API; this is quite uncomfortable for Infinispan Query users: I
think we should at least import the annotations and the DSL docs.
http://docs.jboss.org/infinispan/5.2/apidocs/
http://docs.jboss.org/hibernate/search/4.2/api/
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.infinispan.org)
___
infinisp
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 17:45, Manik Surtani wrote:
>
> On 29 Jan 2013, at 17:17, Bela Ban wrote:
>
>>
>> On 1/29/13 5:25 PM, Sanne Grinovero wrote:
>>> Glad you started work on that :)
>>>
>>> Any currentTimeMillis() even today will blow away your cache line and
>>> probably trigger a context sw
On 29 Jan 2013, at 16:25, Sanne Grinovero wrote:
> Glad you started work on that :)
>
> Any currentTimeMillis() even today will blow away your cache line and
> probably trigger a context switch.
>
> Having it as a service we will be able to experiment: the first thing
> I'll do is replace it wit
On 29 Jan 2013, at 17:17, Bela Ban wrote:
>
> On 1/29/13 5:25 PM, Sanne Grinovero wrote:
>> Glad you started work on that :)
>>
>> Any currentTimeMillis() even today will blow away your cache line and
>> probably trigger a context switch.
>
> I understand the context switch (in general, it's
On 1/29/13 5:25 PM, Sanne Grinovero wrote:
> Glad you started work on that :)
>
> Any currentTimeMillis() even today will blow away your cache line and
> probably trigger a context switch.
I understand the context switch (in general, it's not recommended anyway
to invoke a system call in synchro
On 1/29/13 5:02 PM, Manik Surtani wrote:
> Thinking about Sanne's idea re: a clock service and not continuously relying
> on System.cTM, I stumbled upon this:
>
> https://blogs.oracle.com/ksrini/entry/we_take_java_performance_very
>
> The last section re: caching is interesting.
>
> Having all co
Interesting; looking at the code a bit more, I don't think this offers any
improvements except in the case where expiry is set. Granted, this is a useful
thing to have at that point, but I'm not entirely sure whether it will affect
the majority of users.
Anyway, to measure any benefit, I'm als
Glad you started work on that :)
Any currentTimeMillis() even today will blow away your cache line and
probably trigger a context switch.
Having it as a service we will be able to experiment: the first thing
I'll do is replace it with a NOOPService and see how much it improves.
Ideally I'd like
On 01/29/2013 02:30 PM, Sanne Grinovero wrote:
> @Manik yes I'm not using a CacheStore, I would presume the same. This
> is why I've created the Lucene-specific CacheLoader, maybe I should
> complete the job and make it a CacheStore.
>
>
Oh yeah, a Lucene CacheStore would be nice.
Tristan
Thinking about Sanne's idea re: a clock service and not continuously relying on
System.cTM, I stumbled upon this:
https://blogs.oracle.com/ksrini/entry/we_take_java_performance_very
The last section re: caching is interesting.
Having all code use a Clock.currentTimeMillis() and having an implem
Very nice, looking forward to the Lucene bench results.
I hope you'll run it with a distributed cache as well!
On Tue, Jan 29, 2013 at 3:30 PM, Sanne Grinovero wrote:
> No I'm not comparing with Lucene 3.6 now with this configuration. It
> is well known that Lucene 4 is significantly faster th
No I'm not comparing with Lucene 3.6 now with this configuration. It
is well known that Lucene 4 is significantly faster than Lucene 3, so
that would be unfair.
What is interesting is that when comparing our implementations vs. the
Apache stock ones while using Lucene 3 we where "very close", ofte
Have you got numbers comparing against Lucene 3.6 ?
Tristan
On 01/29/2013 12:53 AM, Sanne Grinovero wrote:
> These are preliminary results of our stressor; looks quite promising
> as I haven't yet looked into profiling / tuning:
>
> Stock Lucene RAMDirectory
> Searches: 14.799.852
> Write
> The second I have no idea how to implement as we do not have
> CacheEntryExpired event. True, spec is not rigorous that such an event
> has to be fired immediately after an entry has expired but eventually
> (which might be on access). Either way, I am all ears on sugges
Wow. That's impressive. I presume the numbers change quite drastically the
moment we have a cache store configured though?
On 28 Jan 2013, at 23:53, Sanne Grinovero wrote:
> These are preliminary results of our stressor; looks quite promising
> as I haven't yet looked into profiling / tuning:
On Mon, Jan 28, 2013 at 5:41 PM, Manik Surtani wrote:
>
> On 28 Jan 2013, at 15:22, Vladimir Blagojevic wrote:
>
> On 13-01-28 7:31 AM, Manik Surtani wrote:
>
> If you're ok with changing the core, you could add a getValue() method
> to CacheEntryCreatedEvent, and an isCreated() method to
> Ca
On Jan 28, 2013, at 12:43 PM, Manik Surtani wrote:
>
> On 28 Jan 2013, at 12:35, Dan Berindei wrote:
>
>>
>>
>> On Mon, Jan 28, 2013 at 1:56 PM, Manik Surtani wrote:
>> Let me clarify a few things on this thread. THere seems to be a bit of
>> confusion here. :)
>>
>> storeAsBinary in I
On Jan 28, 2013, at 3:07 PM, Vladimir Blagojevic wrote:
> On 13-01-28 6:56 AM, Manik Surtani wrote:
>>
>> Now lets consider what JSR 107 needs. Similarly named, the feature in JSR
>> 107 serves a completely different purpose, and this is referential
>> integrity. Think database-style isolat
22 matches
Mail list logo
