JAX-RS systest failures with jetty7

Hello. I'm working with a modified version of the chukwa trunk which
outputs mysql using the MetricDataLoader. Before suggesting the obvious,
these things are out of my control :)

I'm just exploring how Chukwa handles various error conditions. For
instance, if the chukwa machine lost contact with the mysql server because
of a network failure and the MDL threw an error. My assumption was that on
a subsequent running of the MDL, when the database was available again, it
would pick up processing where it left off. That doesn't seem to be the
case, though. Can anyone tell me how to recover from such an error? 


- William Bajzek
willia### @gmail.com

Hi,

Last time I worked on the testsuites in trunk the tests that were
enabled were all passing. That was about 6 or more weeks ago. Since
then a number of the tests are failing which also is reflected in the
tck results. Please please run the testsuites or at least watch the
build results and make sure that your changes didn't break the tests.

Jarek

Hi,

I see the tinderbox test started failing on the 22nd of June [1].
The failures are in derbyall run in the old harness. Some changes to the 
masters were committed under DERBY-1482.

However, when I run these on my local machine, they pass.
Can any one confirm this?
I'd like to figure out if there is a problem with the tinderbox test 
environment, or if we have a real regression test failure.
We'll get another data point of the daily/nightly runs fail later today.


Thanks,


[1] 
http://dbtg.foundry.sun.com/derby/tes...mmary-956763.html

I've just fixed a break (r979569) that was stopping the hudson builds
running all the tests.  However even with the aborted tests run, there
were a lot of regressions.  See:

 
http://hudson.zones.apache.org/hudson...4-full-tests/272/

Unfortunately, hudson hadn't done a build in a while so quite a few
changes went into that build which makes it harder to see what might
have caused the failures.

The latest test run:

 
http://hudson.zones.apache.org/hudson...4-full-tests/275/

should at least run all the tests.

Please can we focus on fixing these regressions?

Regards,
 Mark.

I recently started seeing quite a lot of socket test failures on my
main Debian Linux machine.  It turns out that an upgrade of the netbase
package included a new file:

  /etc/sysctl.d/bindv6only.conf

which sets the system configuration:

  net.ipv6.bindv6only = 1

which means that IPv6 bound sockets only accept IPv6 connections and not
IPv4 connections (w/address mapping).  The expectation is that daemons
wanting to accept both IPv6 and IPv4 connections bind twice.

Then I had a Eureka! moment and remembered that I had some FreeBSD
changes that I had not committed yet because I was still getting socket
test failures when I had fixed everything that I thought was broken....
and the pattern of failures was similar.  Changing the equivalent
"net.inet6.ip6.v6only=0" seems to have fixed most of the remaining
issues.  I'll tidy up these changes[0] and commit them shortly.

For the time being I've changed this back on my machine (by editing the
above file and replacing the 1 with 0).  However, I wonder if we should
be handling this in the classlib implementation.  If we don't then users
will experience a change in behaviour unless they change the system
default but changing the system default may have unintended consequences
for other applications.

I believe it is possible to set the IPV6_V6ONLY socket option to avoid
the change in behaviour but for the moment, it looks like the RI is not
doing this so I guess we shouldn't either?

Regards,
 Mark.

[0] Mostly removing the many things that I tried that we not actually
    necessary ;-)

     [
https://issues.apache.org/jira/browse...nels:all-tabpanel
]

Lily Wei reopened DERBY-3852:

     [
https://issues.apache.org/jira/browse...nels:all-tabpanel
]

Kathey Marsden closed DERBY-3852.

Hi all,

There's an interesting paper published where the authors describe a
project for failure testing in distributed systems. As an example the show
how they could find issues in Hadoop HDFS. They also mention they are
working on similar tests for Cassandra. Worth a read. Hopefully they will
publish their results about Cassandra and the source code involved..

http://www.eecs.berkeley.edu/Pubs/Tec...EECS-2010-98.html

/Johan

     [
https://issues.apache.org/jira/browse...nels:all-tabpanel
]

Myrna van Lunteren closed DERBY-4536.

     [
https://issues.apache.org/jira/browse...nels:all-tabpanel
]

Myrna van Lunteren reassigned DERBY-4536:

Console testsuite has failures with Tomcat assembly

Update testsuite to fix the failures and add new test cases

Update enterprise-testsuite to fix test failures

     [
https://issues.apache.org/jira/browse...nels:all-tabpanel
]

viola.lu closed GERONIMO-4738.

     [
https://issues.apache.org/jira/browse...nels:all-tabpanel
]

viola.lu closed GERONIMO-4738.

    [
https://issues.apache.org/jira/browse...8#action_12875448
] 

viola.lu commented on GERONIMO-4738:

     [
https://issues.apache.org/jira/browse...nels:all-tabpanel
]

viola.lu reopened GERONIMO-4738:

     [
https://issues.apache.org/jira/browse...nels:all-tabpanel
]

Delos Dai resolved GERONIMO-4738.

Console testsuite failures are caused by the new DOJO navigation tree

Update commands-testsuite to fix failures and remove dropped feature test