hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <e...@apache.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 20:57:47 GMT
I've put up another release candidate (RC1) just now. It includes 23 more
jiras including disabling master-meta colocation. Please try to test and
vote by Friday.

Thanks JM for the failure reporting. TestAssignmentManager and
TestSplitLogManager
are pretty flaky lately.

Stack, I think I've uploaded my signing key to MIT servers. It should also
be there at https://people.apache.org/keys/committer/enis.asc and
https://www.us.apache.org/dist/hbase/KEYS. I don't know whether I have to
put it anywhere else.

Enis

On Tue, Sep 16, 2014 at 9:19 AM, Jean-Marc Spaggiari <
jean-marc@spaggiari.org> wrote:

> 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