Docs refactored in HEAD
by Manik Surtani
Guys,
I've refactored the docs in HEAD.
1) Please make sure you're using the *latest* docbook-support module
[1] (the one from svn; not the old, frozen CVS version)
2) I've updated the look and feel of both the style sheets for the
html-ized versions as well as the PDFs that are printed.
3) Reorganised and re-written large portions of the user guide -
will have a draft of these on labs.jboss.com for review by tomorrow
morning
More from me soon.
[1] http://fisheye.jboss.com/browse/JBossAS/docbook-support
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
17 years, 10 months
RE: [jbosscache-dev] FYI- increase CC build timeout
by Rajesh Rajasekaran
The current timeout is at 4 hrs.
I am increasing this to 5 hrs and forcing a build now.
-----Original Message-----
From: Ryan Campbell
Sent: Monday, January 22, 2007 10:50 AM
To: Vladimir Blagojevic; 'Manik Surtani'; Rajesh Rajasekaran
Cc: 'jbosscache-dev(a)lists.jboss.org'
Subject: RE: [jbosscache-dev] FYI- increase CC build timeout
Rajesh, can you look at this?
> -----Original Message-----
> From: Vladimir Blagojevic
> Sent: Monday, January 22, 2007 5:06 PM
> To: Manik Surtani; Ryan Campbell
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: RE: [jbosscache-dev] FYI- increase CC build timeout
>
> Ryan,
>
> Any estimate on this task. If it is a simple change we would
> appreciate if it can get resolved soon since we really need those
reports
> at this stage of JBC development (preparing 2.0 release).
>
>
> Yeah new tests are running around 190-200 minutes. Not all tests
should
> be run on boths stacks but it seemed like a maintenance headache to
> maintain
> a list of tests that are non-local (replicated) and run only those
tests
> on
> udp and tcp. If someone has a clever idea how to do this please speak
up.
>
> So for now we run all the tests twice.
>
> Cheers.
>
>
>
> > -----Original Message-----
> > From: Manik Surtani [mailto:manik@jboss.org]
> > Sent: Monday, January 22, 2007 8:45 AM
> > To: Vladimir Blagojevic
> > Cc: jbosscache-dev(a)lists.jboss.org
> > Subject: Re: [jbosscache-dev] FYI- increase CC build timeout
> >
> > Is this for the overall test suite, controlled by the CC
> > script? I presume this has to do with the introduction of
> > new tests (specifically with re-running all repl tests with
> > both tcp and udp?)
> >
> > --
> > Manik Surtani
> >
> > Lead, JBoss Cache
> > JBoss, a division of Red Hat
> >
> > Email: manik(a)jboss.org
> > Telephone: +44 7786 702 706
> > MSN: manik(a)surtani.org
> > Yahoo/AIM/Skype: maniksurtani
> >
> >
> >
> > On 19 Jan 2007, at 17:17, Vladimir Blagojevic wrote:
> >
> > > http://jira.jboss.com/jira/browse/JBQA-622
> > >
> > > _______________________________________________
> > > jbosscache-dev mailing list
> > > jbosscache-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> >
> >
> >
17 years, 10 months
RE: [jbosscache-dev] FYI- increase CC build timeout
by Ryan Campbell
Rajesh, can you look at this?
> -----Original Message-----
> From: Vladimir Blagojevic
> Sent: Monday, January 22, 2007 5:06 PM
> To: Manik Surtani; Ryan Campbell
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: RE: [jbosscache-dev] FYI- increase CC build timeout
>
> Ryan,
>
> Any estimate on this task. If it is a simple change we would
> appreciate if it can get resolved soon since we really need those
reports
> at this stage of JBC development (preparing 2.0 release).
>
>
> Yeah new tests are running around 190-200 minutes. Not all tests
should
> be run on boths stacks but it seemed like a maintenance headache to
> maintain
> a list of tests that are non-local (replicated) and run only those
tests
> on
> udp and tcp. If someone has a clever idea how to do this please speak
up.
>
> So for now we run all the tests twice.
>
> Cheers.
>
>
>
> > -----Original Message-----
> > From: Manik Surtani [mailto:manik@jboss.org]
> > Sent: Monday, January 22, 2007 8:45 AM
> > To: Vladimir Blagojevic
> > Cc: jbosscache-dev(a)lists.jboss.org
> > Subject: Re: [jbosscache-dev] FYI- increase CC build timeout
> >
> > Is this for the overall test suite, controlled by the CC
> > script? I presume this has to do with the introduction of
> > new tests (specifically with re-running all repl tests with
> > both tcp and udp?)
> >
> > --
> > Manik Surtani
> >
> > Lead, JBoss Cache
> > JBoss, a division of Red Hat
> >
> > Email: manik(a)jboss.org
> > Telephone: +44 7786 702 706
> > MSN: manik(a)surtani.org
> > Yahoo/AIM/Skype: maniksurtani
> >
> >
> >
> > On 19 Jan 2007, at 17:17, Vladimir Blagojevic wrote:
> >
> > > http://jira.jboss.com/jira/browse/JBQA-622
> > >
> > > _______________________________________________
> > > jbosscache-dev mailing list
> > > jbosscache-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> >
> >
> >
17 years, 10 months
RE: [jbosscache-dev] FYI- increase CC build timeout
by Vladimir Blagojevic
Ryan,
Any estimate on this task. If it is a simple change we would
appreciate if it can get resolved soon since we really need those
reports
at this stage of JBC development (preparing 2.0 release).
Yeah new tests are running around 190-200 minutes. Not all tests should
be run on boths stacks but it seemed like a maintenance headache to
maintain
a list of tests that are non-local (replicated) and run only those tests
on
udp and tcp. If someone has a clever idea how to do this please speak
up.
So for now we run all the tests twice.
Cheers.
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Monday, January 22, 2007 8:45 AM
> To: Vladimir Blagojevic
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] FYI- increase CC build timeout
>
> Is this for the overall test suite, controlled by the CC
> script? I presume this has to do with the introduction of
> new tests (specifically with re-running all repl tests with
> both tcp and udp?)
>
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
>
> On 19 Jan 2007, at 17:17, Vladimir Blagojevic wrote:
>
> > http://jira.jboss.com/jira/browse/JBQA-622
> >
> > _______________________________________________
> > jbosscache-dev mailing list
> > jbosscache-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
>
>
17 years, 10 months
JDBCCacheLoader - performance improvement suggestion
by Mircea Markus
Hi guys,
I've took a look at the implementation of JDBCCacheLoader and here are some
thoughts on it.
There is an alternative way of persisting trees into the database. It has
certain advantages compared to the straight forward solution of each node
keeping a reference to its parent ( a.k.a. Adjacency List Model). The basic
idea is to traverse the tree in preorder and add some indexing info to each
node - you can find a nice and simple description of the model here:
http://www.sitepoint.com/print/hierarchical-data-database. This indexing
info will be further used for optimizing fetching and removing operations.
The big advantage is that all the recursive calls for the loadSubtree and
removeSubtree operations are nicely avoided. Drawback - insertions is
slightly more time consuming.
I've made a comparison between this approach and the existing implementation
and here are some figures. Methods that are affected are: remove(Fqn),
loadState(Fqn subtree, ..) and put(Fqn, value)
1) remove(Fqn). Current recursive implementation performs about pow(m,n)
database calls. M = the average # of children, n the depth of the subtree.
The new approach would reduce it to a fix value(3 calls - retrieve the node,
delete it together with all its children, update indexes)
2) loadState(Fqn subtree, ..) - similar to remove; pow(m,n) database calls,
2 queries for loading it.
3) put(Fqn, value) - here is the drawback. Normally a new update should be
performed in order to shift the indexes. An optimization can be performed
though. By indexing with a step of lets say 10, we'll be assured that the
next 9 insertion will not conflict, so the drawback would be an update for
each 9 insertions - not a big deal I would say.
If you guys find it usefully, really glad to go ahead with an implementation
and compare the performance figures...
Cheers,
Mircea
17 years, 10 months
RE: [jbosscache-dev] JBC BETA2
by Brian Stansberry
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Guys,
>
> I'd like to freeze and tag BETA2 by EOF Monday. If there is
> anything you feel you cannot get in by EOF Monday could you
> please defer them for BETA2. Brian and Ben, I see a bunch of
> tasks assigned to you guys targeted for BETA1.
>
> Cheers,
Sure, np.
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
17 years, 10 months
JBC BETA2
by Manik Surtani
Guys,
I'd like to freeze and tag BETA2 by EOF Monday. If there is anything
you feel you cannot get in by EOF Monday could you please defer them
for BETA2. Brian and Ben, I see a bunch of tasks assigned to you
guys targeted for BETA1.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
17 years, 10 months
RE: [jbosscache-dev] Alternatives to using AS DataSource remotely? - itcaused me some headaches today :(
by Galder Zamarreno
I've gone for the 3rd option and have got most of the JDBCCacheLoaderTest running successfully. Need to make sure that I can override the setting to use DummyTransactions as per the CacheLoaderTestBase, which do not relate in this case.
I think I should also be able to avoid compile time dependencies on any AS libraries, using an Microcontainer 1.0 style XML based injection of pojos needed to run this tests. Adrian gave me a hand here :). The only compile time dependency would be on Microcontainer 1.0.x.
If I can't get this working and make all tests run successfully, we should be fine for the moment. ManagedCF path for JDBCCacheLoaderTest would still require manual testing but should be much easier than it was a couple of days ago... :D
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Galder Zamarreno
Sent: 17 January 2007 21:08
To: jbosscache-dev(a)lists.jboss.org
Cc: Clebert Suconic
Subject: [jbosscache-dev] Alternatives to using AS DataSource remotely? - itcaused me some headaches today :(
After a bit of a fight, I have managed to run unsuccessfully JDBCCacheLoaderTest accessing the AS datasource remotely. The tests were failing with JBoss Serialization and not with Java Serialization.
After a bit of thought and discussion with Clebert, my gut feeling started to tell me that using the DataSource remotely was probably influencing the errors reported with JBoss Serialization.
I then took one of the tests and put it in a SAR and deployed in AS with the new JBossCache. I run the one of the failing tests via the MBean interface with jboss serialization on and it worked fine.
What does this tell me? Until we're not able to run the JDBCCacheLoaderTest inside the AS, we're not gonna be able to confirm that JDBCCacheLoader works fine inside AS. Besides, some of the tests use transactions and it'd be ideal to use JBoss TransactionManager for that.
This is important for the work I'm doing so that I can confirm I haven't broken anything anywhere else while introducing C3P0 connection pooling, so 3 choices here:
1) HACK, UGLY and everything bad u can think of!!! Create a SAR that contains all the tests in JDBCCacheLoaderTest and parent and check manually the logs. uuuuggghhhhh
2) Start up a mini App Server (JNDI, JDBC Connection Pooling, TransactionManager). If the JNDI was started locally from the unit test, I could potentially plug the Hypersonic DataSource and JBoss Transaction Manager and I could run the tests very easily and confirm that it works. Have you done this? Do you see it feasible? I might be able to use EJB3 standalone to provide a small container for this...
3) Create some kind of SAR that is deployed in a running AS and runs the test. I used to do this using Cactus in my previous work but didn't like it at all. Quite ugly as well.
Any other opinions?
p.s. Clebert, thanks for your help today :)
Cheers,
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 10 months
(no subject)
by Galder Zamarreno
Hi,
I have uploaded a head.zip file to /clebert-testcase in ftp.jboss.com. All you need to do to replicate this issue is:
1) Unzip head.zip somewhere
2) Download a 4.0.5.GA distribution and open server/default/deploy/hsqldb-ds.xml. Add <use-java-context>false</use-java-context> element inside <local-tx-datasource> element so that the datasource is accessible remotely.
3) Startup the default configuration
4) With IntelliJ, open JBossCache.ipr and run JDBCCacheLoaderTest. You should see most of the tests failing with the stacktrace attached here. This tests are testing that JBossCache can write and read correctly to a backend JDBC cache store. Writing to the db via a remote connection to the datasource seems to work relatively ok, but the stacktrace is produced at reading time, when we get the InputStream and we ask JBossSerialization to create an ObjectInputStream out of it.
This does not happen when the DataSource is retrieved locally. I'm a bit busy currently developing a new feature for JBossCache but I should be able to help you at the end of next week to narrow this down.
As I said, if you run JDBCCacheLoaderTest with -Dserialization.jboss=false, almost all tests pass and the ones that don't are not because of an issue with serialization itself.
I don't have time right now to dig deeper, but I'll have a go in a couple of weeks. Just wanted to send the email so that you have something if you wanna try it yourself.
Apologies for not being able to give you more insight to he cause of the issue.
Cheers,
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
17 years, 10 months
