On 04/08/2013 06:51 PM, Galder Zamarreño wrote:
> ^ That's certainly an option, but it's gotta be extensible (and
> retrievable), so that server's can build on top of it. For example,
> REST server might wanna add MIME info on top of it. It's got to be
> able to extend Metadata concrete class,
On Apr 8, 2013, at 4:09 PM, Manik Surtani wrote:
> Tombstones as well as external versioning - something Hibernate 2LC has
> needed for a while (and Max doesn't ever stop bugging me about!)
>
> Re: the serialisability, how about this: why make Metadata in interface? Why
> not a concrete clas
>> Nah, that would also show with standalone testing then, and it doesn't.
>
> Infinispan generates a gazillion more logging opportunities when
> clustering is enabled.. if it's enabled but hidden, it would still be
> different than standalone.
Ah, ok.
But from Marko's observations, this is not t
On 8 April 2013 15:52, Ales Justin wrote:
> Nah, that would also show with standalone testing then, and it doesn't.
Infinispan generates a gazillion more logging opportunities when
clustering is enabled.. if it's enabled but hidden, it would still be
different than standalone.
Sanne
Nah, that would also show with standalone testing then, and it doesn't.
Marko found out that DataNucleus is pushing DEBUG logs in, dunno yet why.
But, imo, that still shouldn't totally cripple app's performance, yet alone
kill it at the end.
e.g. I can imagine users trying to debug issues with
Is it possible you have the loggers set to a high level of detail but
only filter the results in the appender configuration?
In such a setup you would not writ much into the logs but you would
still have a huge performance penalty as we would still be generating
the intermediate strings, and Infini
>> Hmmm, we now disabled CapeDwarf logging, and it runs a lot better.
> what does a lot better mean? Does it run as expected?
Querying data on any node returns in ~30ms.
And it returns correct data. ;-)
>> We are logging every stuff that goes on,
>> and then it's up to user to filter it later --
On 8 Apr 2013, at 14:51, Mircea Markus wrote:
>
> On 8 Apr 2013, at 14:38, Ales Justin wrote:
>
>> Hmmm, we now disabled CapeDwarf logging, and it runs a lot better.
> what does a lot better mean? Does it run as expected?
Yes; better as in, still incorrect, but less so? ;)
--
Manik Surtani
Tombstones as well as external versioning - something Hibernate 2LC has needed
for a while (and Max doesn't ever stop bugging me about!)
Re: the serialisability, how about this: why make Metadata in interface? Why
not a concrete class, with a fixed set of attributes (lifespan, maxIdle,
Version
On 8 Apr 2013, at 14:38, Ales Justin wrote:
> Hmmm, we now disabled CapeDwarf logging, and it runs a lot better.
what does a lot better mean? Does it run as expected?
>
> We are logging every stuff that goes on,
> and then it's up to user to filter it later -- this is how GAE does it.
>
> The w
Hmmm, we now disabled CapeDwarf logging, and it runs a lot better.
We are logging every stuff that goes on,
and then it's up to user to filter it later -- this is how GAE does it.
The weird thing is that there shouldn't be any fine log traffic, INFO+ level
only.
Marko is looking into this.
But
Steps to re-produce:
(1) checkout JBossAS 7.2.0.Final tag --> JBOSS_HOME
(2) build CapeDwarf Shared
https://github.com/capedwarf/capedwarf-shared
(3) build CapeDwarf Blue
https://github.com/capedwarf/capedwarf-blue
(4) build CapeDwarf AS
https://github.com/capedwarf/capedwarf-jboss-as
mvn c
Got it, thanks!
+1 especially as it helps bringing tombstones, an urgent feature IMHO.
Sanne
On 8 April 2013 13:11, Galder Zamarreño wrote:
>
> On Apr 8, 2013, at 1:46 PM, Sanne Grinovero wrote:
>
>> I fail to understand the purpose of the feature then. What prevents me
>> to use the existing c
Hi Gauillaume,
thanks! make sure you write some comment on github when you do, as
adding a new commit won't send notifications automatically.
After a quick check I see however you didn't address all my comments;
please recheck the history and don't look just at your last commit:
when you pushed th
New error ...
https://gist.github.com/alesj/5336483
-Ales
On Apr 8, 2013, at 2:25 PM, Ales Justin wrote:
Ales is this error happening after a node failure?
>>
>> No node failure that I'm aware of.
>>
>> We did get some unexpected NPE in DataNucleus framework,
>> but, imo, that shouldn't
That's a ReplicationTimeout, I don't think Search has anything to do with it..
On 8 April 2013 13:25, Ales Justin wrote:
> Ales is this error happening after a node failure?
>
>
> No node failure that I'm aware of.
>
> We did get some unexpected NPE in DataNucleus framework,
> but, imo, that shou
>>> Ales is this error happening after a node failure?
>
> No node failure that I'm aware of.
>
> We did get some unexpected NPE in DataNucleus framework,
> but, imo, that shouldn't completely kill the app.
>
> We'll re-try.
Now I cannot even open an initial page ...
https://gist.github.com/a
Hello,
Don't know if someone saw it (in doubt, I'm sending this email). I have
updated (few weeks ago) the pull request about the MongoDB cachestore.
Let me know hat you think about it.
Have a nice day
Guillaume
2013/1/9 Guillaume SCHEIBEL
> Hi everyone,
>
> Finally, I made the last (for the
On Apr 8, 2013, at 1:46 PM, Sanne Grinovero wrote:
> I fail to understand the purpose of the feature then. What prevents me
> to use the existing code today just storing some extra fields in my
> custom values?
^ Nothing, this is doable.
> What do we get by adding this code?
^ You avoid the n
On 8 Apr 2013, at 12:19, Sanne Grinovero wrote:
> I do have a cleaner solution with proper lock cleanup routines, but
> these are based on the CAS operation too.. they are failing stress
> tests so I won't commit them yet.
Do you have a branch with a failing CAS test? I could take a look.
Cheers
>> Ales is this error happening after a node failure?
No node failure that I'm aware of.
We did get some unexpected NPE in DataNucleus framework,
but, imo, that shouldn't completely kill the app.
We'll re-try.
And then also re-try with no locking.
> Or make something clever based on JGroups vi
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 lead (www.infinispan.org)
__
On Mon, Apr 8, 2013 at 2:36 PM, Galder Zamarreño wrote:
>
> On Apr 8, 2013, at 1:11 PM, Dan Berindei wrote:
>
> >
> >
> >
> > On Mon, Apr 8, 2013 at 1:44 PM, Galder Zamarreño
> wrote:
> >
> > On Apr 8, 2013, at 12:35 PM, Galder Zamarreño wrote:
> >
> > >
> > > On Apr 8, 2013, at 11:17 AM, Mani
I fail to understand the purpose of the feature then. What prevents me
to use the existing code today just storing some extra fields in my
custom values? What do we get by adding this code?
Sanne
On 8 April 2013 12:40, Galder Zamarreño wrote:
>
> On Apr 8, 2013, at 1:26 PM, Sanne Grinovero wrot
On Apr 8, 2013, at 1:26 PM, Sanne Grinovero wrote:
> On 8 April 2013 12:06, Galder Zamarreño wrote:
>>
>> On Apr 8, 2013, at 12:56 PM, Sanne Grinovero wrote:
>>
>>>
>>>
>>>
>>> On 8 April 2013 11:44, Galder Zamarreño wrote:
>>>
>>> On Apr 8, 2013, at 12:35 PM, Galder Zamarreño wrote:
>
On Apr 8, 2013, at 1:11 PM, Dan Berindei wrote:
>
>
>
> On Mon, Apr 8, 2013 at 1:44 PM, Galder Zamarreño wrote:
>
> On Apr 8, 2013, at 12:35 PM, Galder Zamarreño wrote:
>
> >
> > On Apr 8, 2013, at 11:17 AM, Manik Surtani wrote:
> >
> >> All sounds very good. One important thing to consi
On 8 April 2013 12:06, Galder Zamarreño wrote:
>
> On Apr 8, 2013, at 12:56 PM, Sanne Grinovero wrote:
>
>>
>>
>>
>> On 8 April 2013 11:44, Galder Zamarreño wrote:
>>
>> On Apr 8, 2013, at 12:35 PM, Galder Zamarreño wrote:
>>
>> >
>> > On Apr 8, 2013, at 11:17 AM, Manik Surtani wrote:
>> >
>>
There should be no locking contention at all, that is the whole point
of using such a backend and forwarding changes to a single node: that
only a single node ever attempts to acquire this lock. Hence the error
is a simptom of some previous error, I primarily suspect cluster view
stability.
I inde
On Mon, Apr 8, 2013 at 1:44 PM, Galder Zamarreño wrote:
>
> On Apr 8, 2013, at 12:35 PM, Galder Zamarreño wrote:
>
> >
> > On Apr 8, 2013, at 11:17 AM, Manik Surtani wrote:
> >
> >> All sounds very good. One important thing to consider is that the
> reference to Metadata passed in by the client
On Apr 8, 2013, at 12:56 PM, Sanne Grinovero wrote:
>
>
>
> On 8 April 2013 11:44, Galder Zamarreño wrote:
>
> On Apr 8, 2013, at 12:35 PM, Galder Zamarreño wrote:
>
> >
> > On Apr 8, 2013, at 11:17 AM, Manik Surtani wrote:
> >
> >> All sounds very good. One important thing to consider i
On 8 April 2013 11:44, Galder Zamarreño wrote:
>
> On Apr 8, 2013, at 12:35 PM, Galder Zamarreño wrote:
>
> >
> > On Apr 8, 2013, at 11:17 AM, Manik Surtani wrote:
> >
> >> All sounds very good. One important thing to consider is that the
> reference to Metadata passed in by the client app will
On Apr 8, 2013, at 12:35 PM, Galder Zamarreño wrote:
>
> On Apr 8, 2013, at 11:17 AM, Manik Surtani wrote:
>
>> All sounds very good. One important thing to consider is that the reference
>> to Metadata passed in by the client app will be tied to the ICE for the
>> entire lifespan of the IC
On 8 Apr 2013, at 11:28, Ales Justin wrote:
> This "jgroups" backend was there "long" ago.
> And it was actually us - CD - that fixed it and made use of it.
> It's no different from static JGroups backed, the only diff that this one
> elects master automatically.
>
> I can change to Sanne's ne
On Apr 8, 2013, at 11:17 AM, Manik Surtani wrote:
> All sounds very good. One important thing to consider is that the reference
> to Metadata passed in by the client app will be tied to the ICE for the
> entire lifespan of the ICE. You'll need to think about a defensive copy or
> some other
This "jgroups" backend was there "long" ago.
And it was actually us - CD - that fixed it and made use of it.
It's no different from static JGroups backed, the only diff that this one
elects master automatically.
I can change to Sanne's new Ispn based prototype if it will help.
But - with my limi
I believe this new backend is WIP in Hibernate Search. Sanne, didn't you have
a prototype in Infinispan's codebase though?
On 5 Apr 2013, at 15:28, Ales Justin wrote:
>> are you not using the JGroups backend anymore?
>
> I'm using that "jgroups" backend, with auto-master election.
>
>> these
All sounds very good. One important thing to consider is that the reference to
Metadata passed in by the client app will be tied to the ICE for the entire
lifespan of the ICE. You'll need to think about a defensive copy or some other
form of making the Metadata immutable (by the user applicatio
On 5 Apr 2013, at 17:01, Mircea Markus 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. ;)
> and configured: forkCount=1/reuseForks=true (default settings) "which means
> that Surefire creates *one new JVM* p
Hi all,
As mentioned in
http://lists.jboss.org/pipermail/infinispan-dev/2013-March/012348.html, in
paralell to the switch to Equivalent* collections, I was also working on being
able to pass metadata into Infinispan caches. This is done to better support
the ability to store custom metadata in
On Apr 4, 2013, at 2:49 PM, Mircea Markus wrote:
> Hi,
>
> Once we have the x-protocols data access in place, do you see any issues with
> this approach:
> - hotrod java client + Avro writes an "Person" object
> - mechached C++ client reads the binary representation from the server and
> dese
40 matches
Mail list logo
