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
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 ales.jus...@gmail.com wrote:
are you not using the JGroups backend anymore?
I'm using that jgroups backend, with auto-master
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 limited
On Apr 8, 2013, at 11:17 AM, Manik Surtani msurt...@redhat.com 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
On 8 Apr 2013, at 11:28, Ales Justin ales.jus...@gmail.com 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
On Apr 8, 2013, at 12:35 PM, Galder Zamarreño gal...@redhat.com wrote:
On Apr 8, 2013, at 11:17 AM, Manik Surtani msurt...@redhat.com 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
On 8 April 2013 11:44, Galder Zamarreño gal...@redhat.com wrote:
On Apr 8, 2013, at 12:35 PM, Galder Zamarreño gal...@redhat.com wrote:
On Apr 8, 2013, at 11:17 AM, Manik Surtani msurt...@redhat.com wrote:
All sounds very good. One important thing to consider is that the
reference to
On Mon, Apr 8, 2013 at 1:44 PM, Galder Zamarreño gal...@redhat.com wrote:
On Apr 8, 2013, at 12:35 PM, Galder Zamarreño gal...@redhat.com wrote:
On Apr 8, 2013, at 11:17 AM, Manik Surtani msurt...@redhat.com wrote:
All sounds very good. One important thing to consider is that the
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
On 8 April 2013 12:06, Galder Zamarreño gal...@redhat.com wrote:
On Apr 8, 2013, at 12:56 PM, Sanne Grinovero sa...@infinispan.org wrote:
On 8 April 2013 11:44, Galder Zamarreño gal...@redhat.com wrote:
On Apr 8, 2013, at 12:35 PM, Galder Zamarreño gal...@redhat.com wrote:
On Apr 8,
On Apr 8, 2013, at 1:11 PM, Dan Berindei dan.berin...@gmail.com wrote:
On Mon, Apr 8, 2013 at 1:44 PM, Galder Zamarreño gal...@redhat.com wrote:
On Apr 8, 2013, at 12:35 PM, Galder Zamarreño gal...@redhat.com wrote:
On Apr 8, 2013, at 11:17 AM, Manik Surtani msurt...@redhat.com
On Apr 8, 2013, at 1:26 PM, Sanne Grinovero sa...@infinispan.org wrote:
On 8 April 2013 12:06, Galder Zamarreño gal...@redhat.com wrote:
On Apr 8, 2013, at 12:56 PM, Sanne Grinovero sa...@infinispan.org wrote:
On 8 April 2013 11:44, Galder Zamarreño gal...@redhat.com wrote:
On
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 gal...@redhat.com wrote:
On Apr 8, 2013, at 1:26 PM, Sanne
On Mon, Apr 8, 2013 at 2:36 PM, Galder Zamarreño gal...@redhat.com wrote:
On Apr 8, 2013, at 1:11 PM, Dan Berindei dan.berin...@gmail.com wrote:
On Mon, Apr 8, 2013 at 1:44 PM, Galder Zamarreño gal...@redhat.com
wrote:
On Apr 8, 2013, at 12:35 PM, Galder Zamarreño
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)
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
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,
On Apr 8, 2013, at 1:46 PM, Sanne Grinovero sa...@infinispan.org 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?
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 guillaume.schei...@gmail.com
Hi everyone,
Finally,
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 ...
That's a ReplicationTimeout, I don't think Search has anything to do with it..
On 8 April 2013 13:25, Ales Justin ales.jus...@gmail.com 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,
New error ...
https://gist.github.com/alesj/5336483
-Ales
On Apr 8, 2013, at 2:25 PM, Ales Justin ales.jus...@gmail.com 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
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
Got it, thanks!
+1 especially as it helps bringing tombstones, an urgent feature IMHO.
Sanne
On 8 April 2013 13:11, Galder Zamarreño gal...@redhat.com wrote:
On Apr 8, 2013, at 1:46 PM, Sanne Grinovero sa...@infinispan.org wrote:
I fail to understand the purpose of the feature then. What
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
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
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 weird
On 8 Apr 2013, at 14:51, Mircea Markus mmar...@redhat.com 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? ;)
--
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 -- this
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
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
On 8 April 2013 15:52, Ales Justin ales.jus...@gmail.com 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
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 the
On Apr 8, 2013, at 4:09 PM, Manik Surtani msurt...@redhat.com 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
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, so
35 matches
Mail list logo
