subject:"\[jira\] \[Updated\] \(HDFS\-3386\) BK JM \: Namenode is not deleting his lock entry '\/ledgers\/lock\/lock\-0000X', when fails to acquire the lock"

[jira] [Updated] (HDFS-3386) BK JM : Namenode is not deleting his lock entry '/ledgers/lock/lock-0000X', when fails to acquire the lock

2012-05-23 Thread Uma Maheswara Rao G (JIRA)


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

Uma Maheswara Rao G updated HDFS-3386:
--

Resolution: Duplicate
Status: Resolved  (was: Patch Available)

 BK JM : Namenode is not deleting his lock entry '/ledgers/lock/lock-X', 
 when fails to acquire the lock
 --

 Key: HDFS-3386
 URL: https://issues.apache.org/jira/browse/HDFS-3386
 Project: Hadoop HDFS
  Issue Type: Sub-task
  Components: ha
Reporter: surendra singh lilhore
Assignee: Ivan Kelly
Priority: Minor
 Fix For: 2.0.0, 3.0.0

 Attachments: HDFS-3386.diff


 When a Standby NN becomes Active, it will first create his sequential lock 
 entry create lock-000X  in ZK and then tries to acquire the lock as shown 
 below:
 {quote}
 myznode = zkc.create(lockpath + /lock-, new byte[] {'0'},
  Ids.OPEN_ACL_UNSAFE,
  CreateMode.EPHEMERAL_SEQUENTIAL);
 if ((lockpath + / + nodes.get(0)).equals(myznode)) {
 if (LOG.isTraceEnabled()) {
 LOG.trace(Lock acquired -  + myznode);
 }
 lockCount.set(1);
 zkc.exists(myznode, this);
 return;
 } else {
 LOG.error(Failed to acquire lock with  + myznode
 + ,  + nodes.get(0) +  already has it);
 throw new IOException(Could not acquire lock);
 }  
 {quote}
 Say the transition to standby fails to acquire the lock it will throw the 
 exception and NN is getting shutdown. Here the problem is, the lock entry 
 lock-000X will exists in the ZK till session expiry and the further start-up 
 will not be able to acquire lock.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HDFS-3386) BK JM : Namenode is not deleting his lock entry '/ledgers/lock/lock-0000X', when fails to acquire the lock

2012-05-23 Thread Uma Maheswara Rao G (JIRA)


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

Uma Maheswara Rao G updated HDFS-3386:
--

 Target Version/s: 2.0.1, 3.0.0
Affects Version/s: 3.0.0
   2.0.0
Fix Version/s: (was: 3.0.0)
   (was: 2.0.0)

 BK JM : Namenode is not deleting his lock entry '/ledgers/lock/lock-X', 
 when fails to acquire the lock
 --

 Key: HDFS-3386
 URL: https://issues.apache.org/jira/browse/HDFS-3386
 Project: Hadoop HDFS
  Issue Type: Sub-task
  Components: ha
Affects Versions: 2.0.0, 3.0.0
Reporter: surendra singh lilhore
Assignee: Ivan Kelly
Priority: Minor
 Attachments: HDFS-3386.diff


 When a Standby NN becomes Active, it will first create his sequential lock 
 entry create lock-000X  in ZK and then tries to acquire the lock as shown 
 below:
 {quote}
 myznode = zkc.create(lockpath + /lock-, new byte[] {'0'},
  Ids.OPEN_ACL_UNSAFE,
  CreateMode.EPHEMERAL_SEQUENTIAL);
 if ((lockpath + / + nodes.get(0)).equals(myznode)) {
 if (LOG.isTraceEnabled()) {
 LOG.trace(Lock acquired -  + myznode);
 }
 lockCount.set(1);
 zkc.exists(myznode, this);
 return;
 } else {
 LOG.error(Failed to acquire lock with  + myznode
 + ,  + nodes.get(0) +  already has it);
 throw new IOException(Could not acquire lock);
 }  
 {quote}
 Say the transition to standby fails to acquire the lock it will throw the 
 exception and NN is getting shutdown. Here the problem is, the lock entry 
 lock-000X will exists in the ZK till session expiry and the further start-up 
 will not be able to acquire lock.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HDFS-3386) BK JM : Namenode is not deleting his lock entry '/ledgers/lock/lock-0000X', when fails to acquire the lock

2012-05-10 Thread Ivan Kelly (JIRA)


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

Ivan Kelly updated HDFS-3386:
-

Attachment: HDFS-3386.diff

Patch applies on top of HDFS-3058

 BK JM : Namenode is not deleting his lock entry '/ledgers/lock/lock-X', 
 when fails to acquire the lock
 --

 Key: HDFS-3386
 URL: https://issues.apache.org/jira/browse/HDFS-3386
 Project: Hadoop HDFS
  Issue Type: Bug
  Components: ha
Reporter: surendra singh lilhore
Priority: Minor
 Fix For: 2.0.0, 3.0.0

 Attachments: HDFS-3386.diff


 When a Standby NN becomes Active, it will first create his sequential lock 
 entry create lock-000X  in ZK and then tries to acquire the lock as shown 
 below:
 {quote}
 myznode = zkc.create(lockpath + /lock-, new byte[] {'0'},
  Ids.OPEN_ACL_UNSAFE,
  CreateMode.EPHEMERAL_SEQUENTIAL);
 if ((lockpath + / + nodes.get(0)).equals(myznode)) {
 if (LOG.isTraceEnabled()) {
 LOG.trace(Lock acquired -  + myznode);
 }
 lockCount.set(1);
 zkc.exists(myznode, this);
 return;
 } else {
 LOG.error(Failed to acquire lock with  + myznode
 + ,  + nodes.get(0) +  already has it);
 throw new IOException(Could not acquire lock);
 }  
 {quote}
 Say the transition to standby fails to acquire the lock it will throw the 
 exception and NN is getting shutdown. Here the problem is, the lock entry 
 lock-000X will exists in the ZK till session expiry and the further start-up 
 will not be able to acquire lock.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HDFS-3386) BK JM : Namenode is not deleting his lock entry '/ledgers/lock/lock-0000X', when fails to acquire the lock

2012-05-10 Thread Ivan Kelly (JIRA)


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

Ivan Kelly updated HDFS-3386:
-

Fix Version/s: (was: 0.23.0)
   3.0.0
   2.0.0
 Assignee: Ivan Kelly
   Status: Patch Available  (was: Open)

 BK JM : Namenode is not deleting his lock entry '/ledgers/lock/lock-X', 
 when fails to acquire the lock
 --

 Key: HDFS-3386
 URL: https://issues.apache.org/jira/browse/HDFS-3386
 Project: Hadoop HDFS
  Issue Type: Bug
  Components: ha
Reporter: surendra singh lilhore
Assignee: Ivan Kelly
Priority: Minor
 Fix For: 2.0.0, 3.0.0

 Attachments: HDFS-3386.diff


 When a Standby NN becomes Active, it will first create his sequential lock 
 entry create lock-000X  in ZK and then tries to acquire the lock as shown 
 below:
 {quote}
 myznode = zkc.create(lockpath + /lock-, new byte[] {'0'},
  Ids.OPEN_ACL_UNSAFE,
  CreateMode.EPHEMERAL_SEQUENTIAL);
 if ((lockpath + / + nodes.get(0)).equals(myznode)) {
 if (LOG.isTraceEnabled()) {
 LOG.trace(Lock acquired -  + myznode);
 }
 lockCount.set(1);
 zkc.exists(myznode, this);
 return;
 } else {
 LOG.error(Failed to acquire lock with  + myznode
 + ,  + nodes.get(0) +  already has it);
 throw new IOException(Could not acquire lock);
 }  
 {quote}
 Say the transition to standby fails to acquire the lock it will throw the 
 exception and NN is getting shutdown. Here the problem is, the lock entry 
 lock-000X will exists in the ZK till session expiry and the further start-up 
 will not be able to acquire lock.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HDFS-3386) BK JM : Namenode is not deleting his lock entry '/ledgers/lock/lock-0000X', when fails to acquire the lock

2012-05-08 Thread surendra singh lilhore (JIRA)


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

surendra singh lilhore updated HDFS-3386:
-

Description: 
When a Standby NN becomes Active, it will first create his sequential lock 
entry create lock-000X  in ZK and then tries to acquire the lock as shown below:
{quote}
myznode = zkc.create(lockpath + /lock-, new byte[] {'0'},
 Ids.OPEN_ACL_UNSAFE,
 CreateMode.EPHEMERAL_SEQUENTIAL);
if ((lockpath + / + nodes.get(0)).equals(myznode)) {
if (LOG.isTraceEnabled()) {
LOG.trace(Lock acquired -  + myznode);
}
lockCount.set(1);
zkc.exists(myznode, this);
return;
} else {
LOG.error(Failed to acquire lock with  + myznode
+ ,  + nodes.get(0) +  already has it);
throw new IOException(Could not acquire lock);
}  
{quote}

Say the transition to standby fails to acquire the lock it will throw the 
exception and NN is getting shutdown. Here the problem is, the lock entry 
lock-000X will exists in the ZK till session expiry and the further start-up 
will not be able to acquire lock.

  was:

When a Standby NN becomes Active, it will first create his sequential lock 
entry create lock-000X  in ZK and then tries to acquire the lock as shown below:
{quote}
myznode = zkc.create(lockpath + /lock-, new byte[] {'0'},
 Ids.OPEN_ACL_UNSAFE,
 CreateMode.EPHEMERAL_SEQUENTIAL);
if ((lockpath + / + nodes.get(0)).equals(myznode)) {
if (LOG.isTraceEnabled()) {
LOG.trace(Lock acquired -  + myznode);
}
lockCount.set(1);
zkc.exists(myznode, this);
return;
} else {
LOG.error(Failed to acquire lock with  + myznode
+ ,  + nodes.get(0) +  already has it);
throw new IOException(Could not acquire lock);
}  
{quote}

Say the transition to standby fails to acquire the lock it will throw the 
exception and NN is getting shutdown. Here the problem is, the lock entry 
lock-000X will exists in the ZK till session expiry and the further start-up 
will not be able to acquire lock.

Summary: BK JM : Namenode is not deleting his lock entry 
'/ledgers/lock/lock-X', when fails to acquire the lock  (was: Namenode is 
not deleting his lock entry '/ledgers/lock/lock-X', when fails to acquire 
the lock)

 BK JM : Namenode is not deleting his lock entry '/ledgers/lock/lock-X', 
 when fails to acquire the lock
 --

 Key: HDFS-3386
 URL: https://issues.apache.org/jira/browse/HDFS-3386
 Project: Hadoop HDFS
  Issue Type: Bug
  Components: ha
Reporter: surendra singh lilhore
Priority: Minor
 Fix For: 0.23.0


 When a Standby NN becomes Active, it will first create his sequential lock 
 entry create lock-000X  in ZK and then tries to acquire the lock as shown 
 below:
 {quote}
 myznode = zkc.create(lockpath + /lock-, new byte[] {'0'},
  Ids.OPEN_ACL_UNSAFE,
  CreateMode.EPHEMERAL_SEQUENTIAL);
 if ((lockpath + / + nodes.get(0)).equals(myznode)) {
 if (LOG.isTraceEnabled()) {
 LOG.trace(Lock acquired -  + myznode);
 }
 lockCount.set(1);
 zkc.exists(myznode, this);
 return;
 } else {
 LOG.error(Failed to acquire lock with  + myznode
 + ,  + nodes.get(0) +  already has it);
 throw new IOException(Could not acquire lock);
 }  
 {quote}
 Say the transition to standby fails to acquire the lock it will throw the 
 exception and NN is getting shutdown. Here the problem is, the lock entry 
 lock-000X will exists in the ZK till session expiry and the further start-up 
 will not be able to acquire lock.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HDFS-3386) BK JM : Namenode is not deleting his lock entry '/ledgers/lock/lock-0000X', when fails to acquire the lock

[jira] [Updated] (HDFS-3386) BK JM : Namenode is not deleting his lock entry '/ledgers/lock/lock-0000X', when fails to acquire the lock

[jira] [Updated] (HDFS-3386) BK JM : Namenode is not deleting his lock entry '/ledgers/lock/lock-0000X', when fails to acquire the lock

[jira] [Updated] (HDFS-3386) BK JM : Namenode is not deleting his lock entry '/ledgers/lock/lock-0000X', when fails to acquire the lock

[jira] [Updated] (HDFS-3386) BK JM : Namenode is not deleting his lock entry '/ledgers/lock/lock-0000X', when fails to acquire the lock

5 matches

Site Navigation

Mail list logo

Footer information