To clarify some points rised on the thread "Design change in
Infinispan Query", which I don't wish to derail further:
The Query engine can actually apply per-entry user restriction access
in an efficient way which doesn't involve (necessarily) to check each
result; currently this needs specific us
I'm a bit skeptical.
It might sound a sensible request currently, but if you do so you
inherently "promise" that tasks are going to be executed on a specific
server; AFAIK we promise execution on data locality, but maintaining a
good level of flexibility you can evolve your system to smarter load
b
Hey,
There is an interesting request from community to include an Address along with
a Future returned for a subtask being executed [1].
I think it makes sense what this user wants. We might create Future sub
interface that has getAddress method and we can return an object implementing
that in
On 25 Feb 2014, at 16:08, Mircea Markus wrote:
>
> On Feb 25, 2014, at 9:28 AM, Emmanuel Bernard wrote:
>
>>> On 24 févr. 2014, at 17:39, Mircea Markus wrote:
>>>
>>>
On Feb 17, 2014, at 10:13 PM, Emmanuel Bernard
wrote:
By the way, Mircea, Sanne and I had quite a lo
On Feb 26, 2014, at 2:33 PM, Adrian Nistor wrote:
> On 02/26/2014 04:20 PM, Mircea Markus wrote:
>> On Feb 26, 2014, at 2:13 PM, Dan Berindei wrote:
>>
>>>
>>>
>>> On Wed, Feb 26, 2014 at 3:12 PM, Mircea Markus wrote:
>>>
>>> On Feb 25, 2014, at 5:08 PM, Sanne Grinovero wrote:
>>>
T
I agree, sounds like a sensible thing to do. But this needs to be
planned carefully and when exactly is the good time to do it, soon and
have it ready for 7.0.0.Final?
On 2/26/2014, 10:29 AM, Dan Berindei wrote:
>
>
>
>
> If we move all internal classes to .impl sub-packages, it will be
> quite
On Wed, Feb 26, 2014 at 4:24 PM, Tristan Tarrant wrote:
> On 26/02/2014 15:02, Mircea Markus wrote:
> > On Feb 26, 2014, at 1:05 PM, Tristan Tarrant
> wrote:
> >
> >> Dear all,
> >>
> >> our JavaDocs currently encompass all of our classes, interfaces, etc
> >> with no clear distinction between pu
On 02/26/2014 04:20 PM, Mircea Markus wrote:
> On Feb 26, 2014, at 2:13 PM, Dan Berindei wrote:
>
>>
>>
>> On Wed, Feb 26, 2014 at 3:12 PM, Mircea Markus wrote:
>>
>> On Feb 25, 2014, at 5:08 PM, Sanne Grinovero wrote:
>>
>>> There also is the opposite problem to be considered, as Emmanuel
>>> s
On 26/02/2014 15:02, Mircea Markus wrote:
> On Feb 26, 2014, at 1:05 PM, Tristan Tarrant wrote:
>
>> Dear all,
>>
>> our JavaDocs currently encompass all of our classes, interfaces, etc
>> with no clear distinction between public and private API/SPI. I would
>> like to clearly mark which of our cl
On Feb 26, 2014, at 2:13 PM, Dan Berindei wrote:
>
>
>
> On Wed, Feb 26, 2014 at 3:12 PM, Mircea Markus wrote:
>
> On Feb 25, 2014, at 5:08 PM, Sanne Grinovero wrote:
>
> > There also is the opposite problem to be considered, as Emmanuel
> > suggested on 11/04/2012:
> > you can't forbid t
On Feb 26, 2014, at 1:05 PM, Tristan Tarrant wrote:
> Dear all,
>
> our JavaDocs currently encompass all of our classes, interfaces, etc
> with no clear distinction between public and private API/SPI. I would
> like to clearly mark which of our classes/interfaces are public API.
> Should we:
On Wed, Feb 26, 2014 at 3:12 PM, Mircea Markus wrote:
>
> On Feb 25, 2014, at 5:08 PM, Sanne Grinovero wrote:
>
> > There also is the opposite problem to be considered, as Emmanuel
> > suggested on 11/04/2012:
> > you can't forbid the user to store the same object (same type and same
> > id) in
Dear all,
our JavaDocs currently encompass all of our classes, interfaces, etc
with no clear distinction between public and private API/SPI. I would
like to clearly mark which of our classes/interfaces are public API.
Should we:
- add some decoration / visual cue to such elements to distinguis
On Feb 25, 2014, at 5:08 PM, Sanne Grinovero wrote:
> There also is the opposite problem to be considered, as Emmanuel
> suggested on 11/04/2012:
> you can't forbid the user to store the same object (same type and same
> id) in two different caches, where each Cache might be using different
> in
Great job, Radim! Looking forward to Radargun 2.0!
On Wed, Feb 26, 2014 at 12:47 PM, Galder Zamarreño wrote:
> Great work Radim!!! Awesome job and very interesting roadmap :)
>
> On 20 Feb 2014, at 15:40, Radim Vansa wrote:
>
> > Hi all,
> >
> > it has been a long time since last release of Rad
Great work Radim!!! Awesome job and very interesting roadmap :)
On 20 Feb 2014, at 15:40, Radim Vansa wrote:
> Hi all,
>
> it has been a long time since last release of RadarGun. We have been
> using it intensively and developed many new features - 1.0.0 had 7,340
> lines of Java code, 1.1.0
On Wed, Feb 26, 2014 at 8:56 AM, Galder Zamarreño wrote:
>
> On 19 Feb 2014, at 12:03, Sanne Grinovero wrote:
>
> > On 19 February 2014 07:12, Galder Zamarreño wrote:
> >>
> >> On 03 Feb 2014, at 19:01, Dan Berindei wrote:
> >>
> >>>
> >>>
> >>>
> >>> On Mon, Feb 3, 2014 at 6:28 PM, Radim Vans
On 19 Feb 2014, at 17:44, Dennis Reed wrote:
> On 02/19/2014 12:57 AM, Galder Zamarreño wrote:
>> On 31 Jan 2014, at 08:32, Dennis Reed wrote:
>>
>>> It would be a loss of functionality.
>>>
>>> As a common example, the AS web session replication cache is configured
>>> for ASYNC by default,
Hi Faseela,
Can you create a unit test demonstrating this (including the config.xml file)?
There are plenty of examples in [1].
Cheers,
[1]
https://github.com/infinispan/infinispan/tree/master/core/src/test/java/org/infinispan/configuration
On 20 Feb 2014, at 10:11, Faseela K wrote:
> Hi,
>
On 19 Feb 2014, at 12:03, Sanne Grinovero wrote:
> On 19 February 2014 07:12, Galder Zamarreño wrote:
>>
>> On 03 Feb 2014, at 19:01, Dan Berindei wrote:
>>
>>>
>>>
>>>
>>> On Mon, Feb 3, 2014 at 6:28 PM, Radim Vansa wrote:
>>> For sync we would want to invoke directly to avoid conte
20 matches
Mail list logo
