On 17 October 2013 20:19, Mircea Markus wrote:
> let's keep this on -dev.
+1
> On Oct 17, 2013, at 6:24 PM, Sanne Grinovero wrote:
>> - Original Message -
>>>
>>> On Oct 17, 2013, at 2:28 PM, Sanne Grinovero wrote:
>>>
- Original Message -
> On Oct 17, 2013,
let's keep this on -dev.
On Oct 17, 2013, at 6:24 PM, Sanne Grinovero wrote:
> - Original Message -
>>
>> On Oct 17, 2013, at 2:28 PM, Sanne Grinovero wrote:
>>
>>>
>>>
>>> - Original Message -
On Oct 17, 2013, at 1:31 PM, Sanne Grinovero wrote:
> With some cu
On 10/17/13 4:52 PM, Dan Berindei wrote:
> Bela, do you really need to rename the thread? You already pass a name
> argument to the Thread constructor, why not create the thread with the
> "correct" name directly?
Correct, I'll change that. I used renameThreads() in the ctor out of
convenience,
On Oct 17, 2013, at 4:09 PM, Mircea Markus wrote:
>
> On Oct 17, 2013, at 2:10 PM, Sanne Grinovero wrote:
>
>> For example a strong use case for these events is data validation: I'm
>> looking forward for an integration with Bean Validation, and when that
>> happens I'm pretty sure we'll want
On 10/17/13 4:48 PM, Dennis Reed wrote:
> On 10/17/2013 05:26 AM, Bela Ban wrote:
>> The other thing to look at is the apparent cost of Thread.setName(): if
>> we cannot avoid thread many creations, we could experiment with *not*
>> naming threads, although this is IMO not a good idea.
>
> I agre
On Oct 17, 2013, at 2:10 PM, Sanne Grinovero wrote:
> For example a strong use case for these events is data validation: I'm
> looking forward for an integration with Bean Validation, and when that
> happens I'm pretty sure we'll want to rollback the transaction in case
> of validation failures.
On 10/17/2013 08:36 AM, Galder Zamarreño wrote:
>
> On Oct 11, 2013, at 11:30 AM, Pedro Ruivo wrote:
>
>> Hi guys.
>>
>> Re: https://issues.jboss.org/browse/ISPN-2090
>>
>> Summary: in tx caches, when @listener(sync = true), the callback is done
>> by the same thread as the transaction. However,
Bela, do you really need to rename the thread? You already pass a name
argument to the Thread constructor, why not create the thread with the
"correct" name directly?
On Thu, Oct 17, 2013 at 5:48 PM, Dennis Reed wrote:
> On 10/17/2013 05:26 AM, Bela Ban wrote:
> > The other thing to look at is
On 10/17/2013 05:26 AM, Bela Ban wrote:
> The other thing to look at is the apparent cost of Thread.setName(): if
> we cannot avoid thread many creations, we could experiment with *not*
> naming threads, although this is IMO not a good idea.
I agree that not naming the threads is a bad idea.
The
It looks like that this discussion is based on what's more convenient
for you all to code, but the decision should be made based on what
users need, and frankly I think there are lots of good reasons to
expect the event to happen in the scope of the same transaction, and
even had the capability to
This is a general question so moving it to infinispan-dev.
On Oct 17, 2013, at 1:13 PM, Divya Mehra wrote:
> Continuous Queries is a question we often get from JDG prospects.
>
> With Querying expected to be fully supported in Library mode and
> Events/Listeners already available in Library m
OK, so the first snapshot shows 18 secs for TP.receive() while the
second lists 22 seconds. In both cases, the bulk of the time is taken up
by thread creation and naming. Thread.setName() is 90% of the thread
creation.
This shows that the parsing of the message is insignificant, whereas the
pa
On 10/17/2013 09:36 AM, Galder Zamarreño wrote:
> On Oct 11, 2013, at 11:30 AM, Pedro Ruivo wrote:
>
>> Hi guys.
>>
>> Re: https://issues.jboss.org/browse/ISPN-2090
>>
>> Summary: in tx caches, when @listener(sync = true), the callback is done
>> by the same thread as the transaction. However, mos
On Oct 11, 2013, at 11:30 AM, Pedro Ruivo wrote:
> Hi guys.
>
> Re: https://issues.jboss.org/browse/ISPN-2090
>
> Summary: in tx caches, when @listener(sync = true), the callback is done
> by the same thread as the transaction. However, most of the events may
> not cause any problem, some of
14 matches
Mail list logo
