https://issues.jboss.org/browse/ISPN-1367
>
> ISPN-1367 is targeted to Infinispan 5.2, any idea of the target release
> date for that? I'm curious as to which AS release it might align with.
Definitely post EAP 6.
--
Manik Surtani
ma...@jboss.org
twitter.com/
on in your slides.
> ___
> infinispan-dev mailing list
> infinispan-...@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
ma...@jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_
(besides the TODOs)
>
> And of course if you can contribute some part, that would be awesome.
>
> Emmanuel
>
>
>
> ___
> infinispan-dev mailing list
> infinispan-...@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
ma..
Os)
>
> And of course if you can contribute some part, that would be awesome.
>
> Emmanuel
>
>
>
> ___
> infinispan-dev mailing list
> infinispan-...@lists.jboss.org
> https://lists.jboss.org/mailman/lis
hits = cq.getResultSize();
> log.info("hits= "+ hits);
>
>
> The hits is appearing empty.
>
> Regards,
> Vidya
> _______
> hibernate-dev mailing list
> hibernate-dev@list
27;s really a matter of opinion as to which is
"more important for Infinispan". :)
Cheers
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
___
hibernate-dev mailing li
Hi guys
Do you have an ETA on Hibernate Search 3.3.0, even early betas, etc? I'm
particularly keen on HSEARCH-397 (to be able to finalise ISPN-194).
Cheers
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscach
an/listinfo/hibernate-dev
>
>
> --
> Brian Stansberry
> Lead, AS Clustering
> JBoss by Red Hat
> ___
> infinispan-dev mailing list
> infinispan-...@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik
gt;> could be ordered based on a column? i.e. age. Also, tools or client jmx
>> code could convert those longs into whatever they want: seconds,
>> minutes...etc
>>
>> The reason I think JMX is a good candidate here is this is inherently
>> monitoring
>
> The reason I think JMX is a good candidate here is this is inherently
> monitoring information and it allows us to expose internal information
> via primitives without having to expose internal classes.
>
> Thoughts?
>
> Cheers,
> --
> Galder Zamarreño
>
;ve applied the patch and reproduced the failure. Looking into it
> right now.
To confirm, you only have this failure when using the cache in a
clustered mode? I.e., using it in LOCAL mode works fine?
Cheers
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://w
can't use Infinispan's eager lock as this ownership is spanning
> multiple transactions; am I right on this? It would be quite useful if
> I could keep owning the lock even after the transaction commit, or
> have a separate TX running for the lock lifecycle, like a LockManager
>
ss is still in the cluster
(check using CacheManager.getMembers()). If the address doesn't exist
(stale lock) remove and overwrite (using replace() to prevent
concurrent overwrites)
WDYT?
- Manik
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http:
ACHE_STORE is totally new for me, maybe I
> just misunderstood the usage.
You could use SKIP_CACHE_STORE, but that only means the lock marker
won't be loaded off disk or some other cache store. It could still be
loaded from a neighbouring node.
--
Manik Surtani
ma...@jboss.org
Lead,
On 29 Sep 2009, at 10:19, Mircea Markus wrote:
>
> On Sep 29, 2009, at 12:08 PM, Manik Surtani wrote:
>
>>
>> On 29 Sep 2009, at 09:57, Mircea Markus wrote:
>>
>>> Hi,
>>>
>>> Again, this is a feature from Coherence[1].
>>>
>&
tinuousquery.htm#BABBEIAH
___
infinispan-dev mailing list
infinispan-...@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
On 28 Sep 2009, at 10:08, Emmanuel Bernard wrote:
>
> On 28 sept. 09, at 10:48, Manik Surtani wrote:
>
>>
>> On 27 Sep 2009, at 11:26, Sanne Grinovero wrote:
>>
>>> Next version of Lucene will provide helpers and tools to make it
>>> easy
>>
is is made to be specific to Hibernate
Search, rather than more generic, for Lucene? As far as Infinispan is
concerned I couldn't care either way since we just depend on HS.
Cheers
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lead, JBoss Cache
; > infinispan-...@lists.jboss.org
>
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> Navin Surtani
>
>
>
> Intern Infinispan
>
> Intern JBoss Cache Searchable
>
>
>
> ___
>
&
> >
>>> >>> >>
>>> >>> >> Sent from my phone.
>>> >>> >>
>>> >>> >> On 13/09/2009, at 8:37 AM, Jeff Ramsdale >
>>> >>> >> wrote:
>>> >>> >>
>>>> infinispan-dev mailing list
>>>>> infinispan-...@lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>
>>> --
>>> Galder Zamarreño
>>> Sr. Software Engineer
>>> Infinispan, JBoss
>>> Hibernate 3.5.0.Beta-1 has been released. Please see
>>>>>>> http://in.relation.to/12153.lace for details.
>>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Sr. Software
arch umbrella due to potential
synergies and spin it out if needed.
Ok. Just make sure we use a different maven module or something so
that there are no dependencies on the rest of HS or Hibernate.
Otherwise spinning out will be a PITA. Lucene should be the only
dependencies of this code
On 27 Aug 2009, at 13:06, Emmanuel Bernard wrote:
On 27 août 09, at 13:07, Manik Surtani wrote:
Very elegant. I'm generally a big fan of 'builder' patterns like
this, but this really isn't a DSL, is it? :) When you first
mentioned a DSL I had visions of defining
PhraseQuery - needs to fillup all accepted terms
FieldScoreQuery
ValueSourceQuery
FuzzyLikeThis
MoreLikeThis
On 25 août 09, at 16:43, Manik Surtani wrote:
On 25 Aug 2009, at 13:34, Emmanuel Bernard wrote:
On 25 août 09, at 14:27, Manik Surtani wrote:
A DSL would work, but I'd rather not
ed with used by infinispan.
In pom file there was dependency on hibernate common annotations
3.2.shapshot. It should't be 3.5?
Cheers,
Lukasz
_______
infinispan-dev mailing list
infinispan-...@lists.jboss.org
https://lists.jboss.org/mai
Wahey! We're on our way. We should blog about this.
On 19 Aug 2009, at 08:32, Galder Zamarreno wrote:
> A FYI: Integrated with HB trunk and test now passes without any probs.
>
> Many thanks Steve!
>
> On 08/18/2009 10:57 PM, Manik Surtani wrote:
>> Great!
>
>>> BulkOperationCleanupAction worked because it was still using the
>>> older
>>> Hibrnate cache SPIs. See
>>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-4034
>>>
>>>
>
> --
> Galder Zamarreño
> Sr. So
; I agree but seeing that the logic was present in JBC, I assumed that
> this might have been discussed in the past.
The JBC logic here was not put in place for Hibernate.
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lead, JBoss Cach
cleanup call happen in beforeCompletion(), after any
Hibernate resources have performed their beforeCompletion() steps?
> Would there be any problems in maintaining the previous logic?
While I don't have any problems reverting to the older logic, I just
feel that doing so hides bu
ay, as far as defaults are concerned, I think the best is to
use the FileCacheStore (no external dependencies that way), and one
cache store per node (so there is no constraint on a shared volume).
But it is a good idea to note down the thoughts above in a README or a
wiki page somewhere.
n the writer thread would need to know when to end this batch)
2009/8/14 Manik Surtani
On 14 Aug 2009, at 10:17, Łukasz Moreń wrote:
Yes, but i.e. FSDirectory flushes changes if any file descriptor is
created/updated - can be many in one IndexWriter life.
In infinispan case implementation, I
t;>>>>>>>> transaction,
>> >>>>>>>>>>> and are looking for segments which are not yet in
index.
>> >>>>>>>>>>> Changes will be visible when AD.3 is completed.
>> >>>>>>>>>>> For tests i tried to commit transaction when merge
starts
>> >>>>>>>>>>> and then
>> >>>>>>>>>>> everything worked well. But then i need to start it
again.
>> >>>>>>>>>>>
>> >>>>>>>>>>> 3. index writer releases lock - transaction is
commited, all
>> >>>>>>>>>>> changes
>> >>>>>>>>>>> made in this transaction are visible for other threads.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Maybe using some other transaction manager could help?
>> >>>>>>>>>>>
>> >>>>>>>>>>> What about Infinispan cache configuration? Some
configuration
>> >>>>>>>>>>> mechanism should be exposed to the user,
>> >>>>>>>>>>> or we can hardcoded one in
InfinispanDirectoryProvider is
>> >>>>>>>>>>> enough?
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> 2009/8/12 Emmanuel Bernard
>> >>>>>>>>>>> why?
>> >>>>>>>>>>> Emmanuel Bernard
>> >>>>>>>>>>> Pending
>> >>>>>>>>>>> you there?
>> >>>>>>>>>>> Emmanuel Bernard
>> >>>>>>>>>>> Pending
>> >>>>>>>>>>> Ok please describe in details what is going on. From
what
>> >>>>>>>>>>> you are
>> >>>>>>>>>>> describing the tx cannot see all segments which looks
like an
>> >>>>>>>>>>> infinispan bug to me.
>> >>>>>>>>>>> Pending
>> >>>>>>>>>>>
>> >>>>>>>>>>> As a back up you can try wo transaction and see if
that works
>> >>>>>>>>>>> Emmanuel Bernard
>> >>>>>>>>>>> Pending
>> >>>>>>>>>>> technically the lucene index should cope with that
>> >>>>>>>>>>> Emmanuel Bernard
>> >>>>>>>>>>> 11:16
>> >>>>>>>>>>> but I like this approach less
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Let's try and chat by email IF I'm not online, I need
to run
>> >>>>>>>>>>> on some
>> >>>>>>>>>>> errands today.
>> >>>>>>>>>>>
>> >>>>>>>> ___
>> >>>>>>>> infinispan-dev mailing list
>> >>>>>>>> infinispan-...@lists.jboss.org
>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Jason T. Greene
>> >>>>>>> JBoss, a division of Red Hat
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Jason T. Greene
>> >>>>> JBoss, a division of Red Hat
>> >>>>>
>> >>>>
>> >>>> ___
>> >>>> infinispan-dev mailing list
>> >>>> infinispan-...@lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >>>
>> >>> ___
>> >>> hibernate-dev mailing list
>> >>> hibernate-dev@lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> >>
>> >
>
>
___
infinispan-dev mailing list
infinispan-...@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
will try
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> explain
>>>>>>>>>>>>>>> it more clear.
>>>>>>>>>>>>>>>
>>>>>>
On 13 Aug 2009, at 19:11, Emmanuel Bernard wrote:
>
> Infini guys, do you support transactional operation spanning several
> concurrent threads?
The *same* tx on different threads? That's disallowed by the JTA spec.
Cheers
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lea
On 11 Aug 2009, at 16:59, Galder Zamarreno wrote:
>
>
> On 08/11/2009 05:42 PM, Manik Surtani wrote:
>>
>> On 11 Aug 2009, at 16:34, Galder Zamarreno wrote:
>>
>>>
>>>
>>> On 08/10/2009 01:09 PM, Galder Zamarreno wrote:
On 11 Aug 2009, at 16:34, Galder Zamarreno wrote:
>
>
> On 08/10/2009 01:09 PM, Galder Zamarreno wrote:
>>
>> On 08/10/2009 12:42 PM, Manik Surtani wrote:
>
>
>
>>> Well, I think we need both.
>>>
>>> getConfiguration(String name) to
On 8 Aug 2009, at 08:14, Galder Zamarreno wrote:
>
> On 08/07/2009 02:06 PM, Manik Surtani wrote:
>>
>> On 7 Aug 2009, at 12:51, Galder Zamarreno wrote:
>>
>>> Manik,
>>>
>>> While I working on this, I've noted the following. If we define
c'd to make it
clear that caches already started using such a configuration will not
be affected when a configuration changes.
I guess this also renders CacheManager.defineCache() API useless/
obsolete, since getConfiguration() should always return a
configuration, even if one didn&#
___
> infinispan-dev mailing list
> infinispan-...@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
For some reason this got swallowed. Thanks for resending, Emmanuel.
My comments inline.
On 6 Aug 2009, at 15:19, Emmanuel Bernard wrote:
Begin forwarded message:
From: Emmanuel Bernard
Date: August 4, 2009 08:53:07 EDT
To: Manik Surtani
Cc: hibernate-dev@lists.jboss.org, infinispan
uld be nice, e.g.
>>
>> hibernate.cache.infinispan.Users.max_age=5000
>>
>> Perhaps just support LRU that way; if people want exotic stuff beyond
>> LRU they have to go to the Infinispan config.
>
> I like the idea a lot. This would limit the number of files to
>
velyEvictedLRUCache for [Users]
AggressivelyEvictedLRUCache for [Orders]
LargeCapacityFIFOCache for [ProductsCatalog]
etc. may well prove useful.
Brian/Steve - care to chime in?
Cheers
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan
.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
type? In which case
couldn't these scale up dynamically and potentially on-demand? No
wait - these are fixed in Hibernate Search on startup, correct?
Cheers
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www
cluster team does have a set of lab servers used to test,
benchmark, etc. You will need to "book" time on this cluster though
since it is shared between JBC/Infinispan, JGroups and JBoss AS
clustering devs.
Cheers
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lead, JBoss
, at 10:53, Sanne Grinovero wrote:
Hello,
I'm forwarding this email to Emmanuel and Hibernate Search dev, as I
believe we should join the discussion.
Could we keep both dev-lists (jbosscache-...@lists.jboss.org,
hibernate-dev@lists.jboss.org ) on CC ?
Sanne
2009/4/29 Manik Surtani :
On 2
ce by:
>>>
>>> 1) revert pom in my checkout of the 3.3.1 tag so it uses JBC 2.1.0.GA
>>> 2) revert any compiled classes back to the original 3.3.1
>>> mvn -Dmaven.test.skip.exec=true clean install
>>>
>>> 3) change the pom so it uses JBC 3.3.0.CR1
all
>>
>> 3) change the pom so it uses JBC 3.3.0.CR1 and JGroups 2.6.5
>> 4) run the testsuite
>>
>> mvn -Ptest test
>>
>> Tests run: 225, Failures: 0, Errors: 21, Skipped: 0
>>
>> 5) force a new compile and then retest:
>>
>> mvn -
Weird, getInstance() was removed in early ALPHAs, and was replaced again
pretty quickly - in 3.0.0.BETA1, even.
http://fisheye.jboss.org/browse/JBossCache/core/tags/3.0.0.BETA1/src/main/java/org/jboss/cache/DefaultCacheFactory.java?r=6676
2008/10/18 Jason T. Greene <[EMAIL PROTECTED]>
> Brian
On 13 Oct 2008, at 15:18, Brian Stansberry wrote:
Manik Surtani wrote:
Guys,
The API of JBC 3.0 is compatible with 2.x so the actual provider
code should not change, but we probably want to test MVCC as a
locking scheme as well.
So, we either
1) need a cache-jbosscache3 module (yuk
few extra tests.
or,
2) assume that cache-jbosscache2 refers to an API and not a version
of the cache. So update the cache used in cache-jbosscache2 to 3.0.0,
and add the extra MVCC tests as well.
My pref would be for 2, what do you guys think?
Cheers
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
[EMAIL PROTECTED]
___
jbosscache-dev mailing list
[EMAIL PROTECTED]
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
Manik Surtani
Lead, JBoss Cache
[EMAIL PROTECTED]
___
't affect 1LC and go straight to 2LC,
so I could be wrong. :-)
Cheers,
Manik
--
Manik Surtani
Lead, JBoss Cache
[EMAIL PROTECTED]
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Hi guys,
would appreciate your thoughts and comments on the ${SUBJECT}:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163564
Cheers
--
Manik Surtani
Lead, JBoss Cache
[EMAIL PROTECTED]
___
hibernate-dev mail
Search should look natural to cache users, not Hibernate users :)
Yup. :-)
--
Manik Surtani
Lead, JBoss Cache
[EMAIL PROTECTED]
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
s generally use this method and find
that they need it? If so then I will try and implement it
otherwise then I will just make it throw an exception.
Thanks again :)
Navin.
--
Manik Surtani
Lead, JBoss Cache
[EMAIL PROTECTED]
___
hibernate
edId means that we won't be able to use @ContainedIn probably
(as we don't have a getter). We can think about that later.
I'm guessing this is a marker to inform the DocumentBuilder not to
expect a @DocumentId field, and with information on how to fetch a
document id to be u
an route the request back
through Hibernate; Hibernate can then manage ordering the
callbacks?
I don't recall more progress on that topic.
Don't forget this one - manik ? :)
I think he's teaching this week??
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red
On 31 Mar 2007, at 19:01, Owen Taylor wrote:
On Fri, 2007-03-16 at 01:23 +, Manik Surtani wrote:
Guys,
I've updated the JIRA [1] and the Javadocs on the Cache interface [2]
to reflect the new functioning of putForExternalRead(), which I will
implement by 2.0.0.BETA2.
This looks l
w your thoughts!
Cheers,
Manik
[1] http://jira.jboss.com/jira/browse/JBCACHE-848
[2] http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jboss/JBossCache/src/
org/jboss/cache/Cache.java?view=co
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: [EMAIL PROTECTED]
Telephone: +44 7786 702
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: [EMAIL PROTECTED]
Telephone: +44 7786 702 706
MSN: [EMAIL PROTECTED]
Yahoo/AIM/Skype: maniksurtani
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.j
6
International toll free (Uruguay): 0004 019 0088
International toll free (Venezuela): 0 800 100 5202
Manik Surtani wrote:
+1
On 22 Feb 2007, at 18:19, Steve Ebersole wrote:
Brian Stansberry wrote:
Sent this out a while back, but the conf call didn't come off
due to scheduling issues. Time
conference call details. Those cc'ed
on the mailing lists are welcome to join in.
Also including Owen explicitly, since I am not sure if he is part
of either list.
That date/time is fine for me.
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: [EMAIL PROTE
64 matches
Mail list logo
