hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Marc Spaggiari <jean-m...@spaggiari.org>
Subject Re: First release candidate for HBase 0.99.0 (RC0) is available. Please vote by 09/17/2014
Date Tue, 16 Sep 2014 16:19:00 GMT
FYI, still on 0.99.0 RC 0 for now. I have been able to stabilize the tests
on my side. Issues where because of zombi deamons from previous tests. So I
now kill them all before I restart, and clear the tmp directory.

Now, with JDK1.8 I have been able to run it 5 times, got 5 times the same
error.

Tests in error:
  org.apache.hadoop.hbase.http.TestSSLHttpServer: Subject class type
invalid.
  org.apache.hadoop.hbase.http.TestSSLHttpServer

Tests run: 918, Failures: 0, Errors: 2, Skipped: 5

On the log side:
2014-09-11 21:42:59,198 DEBUG [pool-1-thread-1] log.Slf4jLog(40): stopped
org.mortbay.jetty.webapp.WebAppContext@a5993cf
{/,file:/home/jmspaggi/hbase-0.99.0/hbase-server/target/test-classes/webapps/test}
2014-09-11 21:42:59,198 INFO  [pool-1-thread-1] log.Slf4jLog(67): Stopped
SslSocketConnector@localhost:0
2014-09-11 21:42:59,200 DEBUG [2116514935@qtp-1330098355-2]
log.Slf4jLog(49): EXCEPTION
java.net.SocketException: Socket closed
        at java.net.SocketInputStream.read(SocketInputStream.java:190)
        at java.net.SocketInputStream.read(SocketInputStream.java:122)
        at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
        at sun.security.ssl.InputRecord.read(InputRecord.java:480)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
        at
sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:884)
        at sun.security.ssl.AppInputStream.read(AppInputStream.java:102)
        at org.mortbay.io.ByteArrayBuffer.readFrom(ByteArrayBuffer.java:382)
        at org.mortbay.io.bio.StreamEndPoint.fill(StreamEndPoint.java:114)
        at
org.mortbay.jetty.bio.SocketConnector$Connection.fill(SocketConnector.java:198)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:290)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
        at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
        at
org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:713)
        at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
2014-09-11 21:42:59,201 DEBUG [2116514935@qtp-1330098355-2]
log.Slf4jLog(40): EOF
2014-09-11 21:42:59,201 DEBUG [pool-1-thread-1] log.Slf4jLog(40): stopped
SslSocketConnector@localhost:0
2014-09-11 21:42:59,201 DEBUG [2090681887@qtp-1330098355-0]
log.Slf4jLog(49): EXCEPTION
java.net.SocketException: Socket closed
        at java.net.SocketInputStream.read(SocketInputStream.java:190)
        at java.net.SocketInputStream.read(SocketInputStream.java:122)
        at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
        at sun.security.ssl.InputRecord.read(InputRecord.java:480)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
        at
sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:884)
        at sun.security.ssl.AppInputStream.read(AppInputStream.java:102)
        at org.mortbay.io.ByteArrayBuffer.readFrom(ByteArrayBuffer.java:382)
        at org.mortbay.io.bio.StreamEndPoint.fill(StreamEndPoint.java:114)
        at
org.mortbay.jetty.bio.SocketConnector$Connection.fill(SocketConnector.java:198)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:290)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
        at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
        at
org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:713)
        at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
2014-09-11 21:42:59,201 DEBUG [pool-1-thread-1] log.Slf4jLog(40): stopping
Server@6ba1e06e
2014-09-11 21:42:59,201 DEBUG [2090681887@qtp-1330098355-0]
log.Slf4jLog(40): EOF
2014-09-11 21:42:59,201 DEBUG [pool-1-thread-1] log.Slf4jLog(40): stopping
ContextHandlerCollection@50958cf6


On JDK1.7 I got a failure in
testBalanceOnMasterFailoverScenarioWithClosedNode(org.apache.hadoop.hbase.master.TestAssignmentManager):
test timed out after 60000 milliseconds

Most probably because a previous test using mini cluster did not kill it
corretly, or because 2 was running at the same time?

2014-09-16 09:23:03,226 DEBUG [pool-1-thread-1]
zookeeper.MiniZooKeeperCluster(171): Failed binding ZK Server to client
port: 59854
java.net.BindException: Adresse déjà utilisée
        at sun.nio.ch.Net.bind0(Native Method)
        at sun.nio.ch.Net.bind(Net.java:444)


And
testGetPreviousRecoveryMode(org.apache.hadoop.hbase.master.TestSplitLogManager)
too. Not the first time.

I have been able to get a correct run from time to time, but not that often.

JM


2014-09-15 17:50 GMT-04:00 Enis Söztutar <enis.soz@gmail.com>:

> Yeah, it will be even more confusing for having colocation on for 0.99.0,
> but off for 0.99.1 and 1.0.
>
> Let me spin up another RC today, and do a 3 day vote.
>
> Enis
>
> On Mon, Sep 15, 2014 at 1:06 PM, lars hofhansl <larsh@apache.org> wrote:
>
> > I think HBASE-11604 warrants a new RC. Maybe in a dev release we could be
> > more relaxed about this, would still be confusing for folks who play with
> > this the first time, see the changed the behavior, and then they play
> again
> > and it's back to what it was before.
> >
> > -- Lars
> >
> >
> >
> > ----- Original Message -----
> > From: Stack <stack@duboce.net>
> > To: HBase Dev List <dev@hbase.apache.org>
> > Cc:
> > Sent: Monday, September 15, 2014 9:15 AM
> > Subject: Re: First release candidate for HBase 0.99.0 (RC0) is available.
> > Please vote by 09/17/2014
> >
> > On Sun, Sep 14, 2014 at 11:05 PM, Enis Söztutar <enis.soz@gmail.com>
> > wrote:
> >
> > > Ok,
> > >
> > > Let me sink this RC, and spin another quick one containing HBASE-11604.
> > > Will do tomorrow.
> > >
> > >
> > You don't want to just fix in a 0.99.1?
> >
> >
> >
> > > Should I wait for HBASE-11967?
> > >
> >
> >
> > I'd say no.  Non-critical.  Takes some work to repro.  We've had this
> > problem always it seems.
> >
> > St.Ack
> >
> >
> >
> >
> >
> >
> >
> > > Enis
> > >
> > > On Fri, Sep 12, 2014 at 11:04 PM, Andrew Purtell <
> > andrew.purtell@gmail.com
> > > >
> > > wrote:
> > >
> > > > I agree it would be surprising to have masters running RegionServers
> > and
> > > > hosting regions. Maybe we can take that kind of departure for 2.0?
> (Or
> > > even
> > > > 1.1?) It's not clear what state that will end up in. Default-on
> > features
> > > in
> > > > 1.0 should carry forward and promote stability and familiarity?
> > > >
> > > >
> > > > > On Sep 11, 2014, at 10:02 AM, Stack <stack@duboce.net> wrote:
> > > > >
> > > > > Thanks for doing the helpful writeup Enis. It helps doing
> evaluation.
> > > > >
> > > > > I have one question below.
> > > > >
> > > > > On Thu, Sep 11, 2014 at 1:56 AM, Enis Söztutar <enis@apache.org>
> > > wrote:
> > > > > ...
> > > > >
> > > > >>
> > > > >> Starting with 0.99.0, the HBase master server and backup master
> > > servers
> > > > >> will
> > > > >> also act as a region server. RPC port and info port for web UI
is
> > > shared
> > > > >> for
> > > > >> the master and region server roles. Active master will be hosting
> > the
> > > > meta
> > > > >> table (and other hbase system tables, acl and namespace) by
> default
> > > > >> (unless configured otherwise). The master and backup masters
will
> > not
> > > be
> > > > >> hosting user level regions. See HBASE-10569 and HBASE-11604 for
> more
> > > > >> details.
> > > > >
> > > > > I think we should change this so this is NOT the default in 1.0.
> What
> > > do
> > > > > folks think?  The new deploy topology will surprise going from
> > earlier
> > > > > version. Better folks enable it explicitly*?
> > > > > St.Ack
> > > > >
> > > > > * I used to be in favor of this feature being on by default but I
> > have
> > > > > since changed my mind given how I see meta hosting evolving in the
> > > > > near-future.
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message