Jim Kellerman (JIRA | 9 Feb 22:07 2008
Picon

[jira] Commented: (HBASE-413) add mailing list to gmane.org


    [
https://issues.apache.org/jira/browse/HBASE-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567363#action_12567363
] 

Jim Kellerman commented on HBASE-413:
-------------------------------------

I received email today stating that hbase-dev and hbase-user are available on gmane.org at
gmane.comp.java.hadoop.hbase.devel and gmane.comp.java.hadoop.hbase.user respectively.

> add mailing list to gmane.org
> -----------------------------
>
>                 Key: HBASE-413
>                 URL: https://issues.apache.org/jira/browse/HBASE-413
>             Project: Hadoop HBase
>          Issue Type: Wish
>            Reporter: Billy Pearson
>            Priority: Minor
>             Fix For: 0.1.0
>
>
> do we want our mailing list on gmane?
> I use it for tracking hadoop when we where on there so I thank it would be helpfull and can not thank of any
reason not to.
> looking at there FAQ we need to subscribe the list to them
> http://gmane.org/faq.php
> The subscribe form is here
> http://gmane.org/subscribe.php
(Continue reading)

stack (JIRA | 9 Feb 23:44 2008
Picon

[jira] Created: (HBASE-431) javadoc links are broke

javadoc links are broke
-----------------------

                 Key: HBASE-431
                 URL: https://issues.apache.org/jira/browse/HBASE-431
             Project: Hadoop HBase
          Issue Type: Bug
            Reporter: stack

Hbase javadoc is no longer in core hadoop.  Means our links from wiki, etc., to javadoc are hanging.  Make them
point to our nightly build when its up and running

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Apache Hudson Server | 9 Feb 23:44 2008
Picon

Build failed in Hudson: HBase-Patch #14

See http://hudson.zones.apache.org/hudson/job/HBase-Patch/14/changes

Changes:

[stack] HBASE-426 hbase can't find remote filesystem

[stack] HBASE-481 Move HMaster and related classes into master package
Part 4: I committed changes in below configs. unintentionally.

[stack] HBASE-418 Move HMaster and related classes into master package
Part 3: Missed non-moved file edits.

[stack] HBASE-418 Move HMaster and related classes into master package
Part 2 (Previous patch moved these classes but turns out new version
also had changes in them -- adding these now).

[stack] HBASE-418 Move HMaster and related classes into master package

[stack] HBASE-406 Remove HTable and HConnection close methods

[jimk] HBASE-421   TestRegionServerExit broken

[stack] HBASE-3 rest server: configure number of threads for jetty
HBASE-416 Add apache-style logging to REST server and add setting log level, etc.

[stack] HBASE-425 Fix doc. so it accomodates new hbase untethered context

[stack] HBASE-56 Unnecessary HQLClient Object creation in a shell loop

[stack] HBASE-2 hlog numbers should wrap around when they reach 999
(Continue reading)

Billy Pearson (JIRA | 9 Feb 23:48 2008
Picon

[jira] Created: (HBASE-432) Rest scanner is not starting at the correct key when useing start_key

Rest scanner is not starting at the correct key when useing start_key
---------------------------------------------------------------------

                 Key: HBASE-432
                 URL: https://issues.apache.org/jira/browse/HBASE-432
             Project: Hadoop HBase
          Issue Type: Bug
          Components: rest
         Environment: hbase-620205
            Reporter: Billy Pearson
            Priority: Minor
             Fix For: 0.2.0
         Attachments: curl.log

no matter where I tell the scanner to start it always starts with this key
%20%20.gr.counseling.www/greekatalog/index.php-c=481.htm:http

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Billy Pearson (JIRA | 9 Feb 23:48 2008
Picon

[jira] Updated: (HBASE-432) Rest scanner is not starting at the correct key when useing start_key


     [
https://issues.apache.org/jira/browse/HBASE-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Billy Pearson updated HBASE-432:
--------------------------------

    Attachment: curl.log

attached curl example

> Rest scanner is not starting at the correct key when useing start_key
> ---------------------------------------------------------------------
>
>                 Key: HBASE-432
>                 URL: https://issues.apache.org/jira/browse/HBASE-432
>             Project: Hadoop HBase
>          Issue Type: Bug
>          Components: rest
>         Environment: hbase-620205
>            Reporter: Billy Pearson
>            Priority: Minor
>             Fix For: 0.2.0
>
>         Attachments: curl.log
>
>
> no matter where I tell the scanner to start it always starts with this key
> %20%20.gr.counseling.www/greekatalog/index.php-c=481.htm:http

(Continue reading)

Billy Pearson (JIRA | 10 Feb 00:04 2008
Picon

[jira] Created: (HBASE-433) region server should deleted restore log after successfull restore

region server should deleted restore log after successfull restore
------------------------------------------------------------------

                 Key: HBASE-433
                 URL: https://issues.apache.org/jira/browse/HBASE-433
             Project: Hadoop HBase
          Issue Type: Bug
          Components: regionserver
            Reporter: Billy Pearson
            Priority: Trivial
             Fix For: 0.2.0

Currently we do not remove the restore log "oldlogfile.log" after we reopen a region after a crashed region server.

Suggestion would be to remove after we successfully flush of all the edits to a mapfile

so something like:
replay log 
memcache flush
deleted log

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Billy Pearson (JIRA | 10 Feb 00:12 2008
Picon

[jira] Commented: (HBASE-433) region server should deleted restore log after successfull restore


    [
https://issues.apache.org/jira/browse/HBASE-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567373#action_12567373
] 

Billy Pearson commented on HBASE-433:
-------------------------------------

might also take a look at what point the master sees a region as crashed from a region server

example

say I have a failed region server and master loads and saves restore logs for each region 

on the reopen of a region and say it replaying the logs and crashes 

Would the master overwrite the old log file with a new one or would the master not consider the region as part
of the region server on a crash until it receives an MSG_REPORT_PROCESS_OPEN message?
Should look in to this so we do not have a risk of over writing a restore log file that has not successfully
loaded and flushed to disk.

> region server should deleted restore log after successfull restore
> ------------------------------------------------------------------
>
>                 Key: HBASE-433
>                 URL: https://issues.apache.org/jira/browse/HBASE-433
>             Project: Hadoop HBase
>          Issue Type: Bug
>          Components: regionserver
>            Reporter: Billy Pearson
(Continue reading)

Jim Kellerman (JIRA | 10 Feb 02:32 2008
Picon

[jira] Commented: (HBASE-433) region server should deleted restore log after successfull restore


    [
https://issues.apache.org/jira/browse/HBASE-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567390#action_12567390
] 

Jim Kellerman commented on HBASE-433:
-------------------------------------

Current situation:

If a region server crashes before it has closed any log files, then all it will leave is one zero length log
file which will be ignored.

However, if the region server crashes after closing one or more log files, and the region server was
starting up a region that had an old log file (and the region server crashed before recovering the old log
file), then yes, the old log file would be overwritten.

Solution for current situation:

HLog.splitLog should check for the presence of an existing log file, and copy its contents into a new file
before processing the region server's log file(s).

Future (when HDFS has appends):

The region server will never leave a zero length log file unless it has received no updates since it started
or since it closed the most recent log file.

Solution for future:

If HDFS supports appends to an existing file, then splitLog should open the region's old log file for append
(Continue reading)

Jim Kellerman (JIRA | 10 Feb 02:34 2008
Picon

[jira] Commented: (HBASE-433) region server should deleted restore log after successfull restore


    [
https://issues.apache.org/jira/browse/HBASE-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567391#action_12567391
] 

Jim Kellerman commented on HBASE-433:
-------------------------------------

And yes, the region server should delete the old log file once it has been completely recovered and flushed.

> region server should deleted restore log after successfull restore
> ------------------------------------------------------------------
>
>                 Key: HBASE-433
>                 URL: https://issues.apache.org/jira/browse/HBASE-433
>             Project: Hadoop HBase
>          Issue Type: Bug
>          Components: regionserver
>            Reporter: Billy Pearson
>            Priority: Trivial
>             Fix For: 0.2.0
>
>
> Currently we do not remove the restore log "oldlogfile.log" after we reopen a region after a crashed
region server.
> Suggestion would be to remove after we successfully flush of all the edits to a mapfile
> so something like:
> replay log 
> memcache flush
> deleted log
(Continue reading)

Jim Kellerman (JIRA | 10 Feb 03:02 2008
Picon

[jira] Created: (HBASE-434) TestTableIndex failed in HBasePatch build #14

TestTableIndex failed in HBasePatch build #14
---------------------------------------------

                 Key: HBASE-434
                 URL: https://issues.apache.org/jira/browse/HBASE-434
             Project: Hadoop HBase
          Issue Type: Bug
          Components: test
    Affects Versions: 0.2.0
            Reporter: Jim Kellerman

TestTableIndex failed in HBase-Patch build #14. See http://hudson.zones.apache.org/hudson/job/HBase-Patch/14/testReport/

junit.framework.AssertionFailedError
	at org.apache.hadoop.hbase.MultiRegionTable.makeMultiRegionTable(MultiRegionTable.java:137)
	at org.apache.hadoop.hbase.mapred.TestTableIndex.setUp(TestTableIndex.java:125)

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Gmane