ldap/servers/plugins/replication/repl5_replica_config.c | 1 +
1 file changed, 1 insertion(+)
New commits:
commit 378de6aabc37e2efa1176b8b41e2dd661c750036
Author: Mark Reynolds <mreynolds(a)redhat.com>
Date: Fri Nov 6 14:41:36 2015 -0500
Ticket 48325 - Replica promotion leaves RUV out of order
Bug Description: When promoting a consumer to a master the new RUV
element is appended to the RUV. However, when trying
to replicate from the newly promoted replica the
remote replica checks the first element in the RUV
and sees that its the same replica ID, and aborts the
replication session. Essentailly this completely
breaks replication between the two servers, and can
actually corrupt other RUVs on other replicas.
Fix Description: When promoting a replica to a master, reorder the RUV
so that it is the first in the list.
https://fedorahosted.org/389/ticket/48325
Reviewed by: nhosoi(Thanks!)
(cherry picked from commit b896840d270a540698f35a4aac4f7a91742952b0)
diff --git a/ldap/servers/plugins/replication/repl5_replica_config.c b/ldap/servers/plugins/replication/repl5_replica_config.c
index 755097a..08fd9b3 100644
--- a/ldap/servers/plugins/replication/repl5_replica_config.c
+++ b/ldap/servers/plugins/replication/repl5_replica_config.c
@@ -983,6 +983,7 @@ replica_config_change_type_and_id (Replica *r, const char *new_type,
csngen_rewrite_rid(gen, rid);
if(purl && type == REPLICA_TYPE_UPDATABLE){
ruv_add_replica(ruv, rid, purl);
+ ruv_move_local_supplier_to_first(ruv, rid);
replica_reset_csn_pl(r);
}
ruv_delete_replica(ruv, oldrid);
ldap/servers/plugins/replication/repl5_replica_config.c | 1 +
1 file changed, 1 insertion(+)
New commits:
commit 2764bc455bef2e88713fc014d917c74df9c484ae
Author: Mark Reynolds <mreynolds(a)redhat.com>
Date: Fri Nov 6 14:41:36 2015 -0500
Ticket 48325 - Replica promotion leaves RUV out of order
Bug Description: When promoting a consumer to a master the new RUV
element is appended to the RUV. However, when trying
to replicate from the newly promoted replica the
remote replica checks the first element in the RUV
and sees that its the same replica ID, and aborts the
replication session. Essentailly this completely
breaks replication between the two servers, and can
actually corrupt other RUVs on other replicas.
Fix Description: When promoting a replica to a master, reorder the RUV
so that it is the first in the list.
https://fedorahosted.org/389/ticket/48325
Reviewed by: nhosoi(Thanks!)
(cherry picked from commit b896840d270a540698f35a4aac4f7a91742952b0)
diff --git a/ldap/servers/plugins/replication/repl5_replica_config.c b/ldap/servers/plugins/replication/repl5_replica_config.c
index 8718f92..849184f 100644
--- a/ldap/servers/plugins/replication/repl5_replica_config.c
+++ b/ldap/servers/plugins/replication/repl5_replica_config.c
@@ -1032,6 +1032,7 @@ replica_config_change_type_and_id (Replica *r, const char *new_type,
csngen_rewrite_rid(gen, rid);
if(purl && type == REPLICA_TYPE_UPDATABLE){
ruv_add_replica(ruv, rid, purl);
+ ruv_move_local_supplier_to_first(ruv, rid);
replica_reset_csn_pl(r);
}
ruv_delete_replica(ruv, oldrid);
ldap/servers/plugins/replication/repl5_replica_config.c | 1 +
1 file changed, 1 insertion(+)
New commits:
commit 6180b91c3f65e9c5e375816a72baa95678458a0a
Author: Mark Reynolds <mreynolds(a)redhat.com>
Date: Fri Nov 6 14:41:36 2015 -0500
Ticket 48325 - Replica promotion leaves RUV out of order
Bug Description: When promoting a consumer to a master the new RUV
element is appended to the RUV. However, when trying
to replicate from the newly promoted replica the
remote replica checks the first element in the RUV
and sees that its the same replica ID, and aborts the
replication session. Essentailly this completely
breaks replication between the two servers, and can
actually corrupt other RUVs on other replicas.
Fix Description: When promoting a replica to a master, reorder the RUV
so that it is the first in the list.
https://fedorahosted.org/389/ticket/48325
Reviewed by: nhosoi(Thanks!)
(cherry picked from commit b896840d270a540698f35a4aac4f7a91742952b0)
diff --git a/ldap/servers/plugins/replication/repl5_replica_config.c b/ldap/servers/plugins/replication/repl5_replica_config.c
index e85ae3e..4d7135c 100644
--- a/ldap/servers/plugins/replication/repl5_replica_config.c
+++ b/ldap/servers/plugins/replication/repl5_replica_config.c
@@ -1003,6 +1003,7 @@ replica_config_change_type_and_id (Replica *r, const char *new_type,
csngen_rewrite_rid(gen, rid);
if(purl && type == REPLICA_TYPE_UPDATABLE){
ruv_add_replica(ruv, rid, purl);
+ ruv_move_local_supplier_to_first(ruv, rid);
replica_reset_csn_pl(r);
}
ruv_delete_replica(ruv, oldrid);
ldap/servers/plugins/replication/repl5_replica_config.c | 1 +
1 file changed, 1 insertion(+)
New commits:
commit b896840d270a540698f35a4aac4f7a91742952b0
Author: Mark Reynolds <mreynolds(a)redhat.com>
Date: Fri Nov 6 14:41:36 2015 -0500
Ticket 48325 - Replica promotion leaves RUV out of order
Bug Description: When promoting a consumer to a master the new RUV
element is appended to the RUV. However, when trying
to replicate from the newly promoted replica the
remote replica checks the first element in the RUV
and sees that its the same replica ID, and aborts the
replication session. Essentailly this completely
breaks replication between the two servers, and can
actually corrupt other RUVs on other replicas.
Fix Description: When promoting a replica to a master, reorder the RUV
so that it is the first in the list.
https://fedorahosted.org/389/ticket/48325
Reviewed by: nhosoi(Thanks!)
diff --git a/ldap/servers/plugins/replication/repl5_replica_config.c b/ldap/servers/plugins/replication/repl5_replica_config.c
index e85ae3e..4d7135c 100644
--- a/ldap/servers/plugins/replication/repl5_replica_config.c
+++ b/ldap/servers/plugins/replication/repl5_replica_config.c
@@ -1003,6 +1003,7 @@ replica_config_change_type_and_id (Replica *r, const char *new_type,
csngen_rewrite_rid(gen, rid);
if(purl && type == REPLICA_TYPE_UPDATABLE){
ruv_add_replica(ruv, rid, purl);
+ ruv_move_local_supplier_to_first(ruv, rid);
replica_reset_csn_pl(r);
}
ruv_delete_replica(ruv, oldrid);
ldap/servers/slapd/daemon.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
New commits:
commit ab8ed9a5ebb0d15b55d7525ed1d5dbeebd8c7563
Author: Noriko Hosoi <nhosoi(a)redhat.com>
Date: Thu Nov 5 13:08:56 2015 -0800
Ticket #48339 - Share nsslapd-threadnumber in the case nunc-stans is enabled, as well.
Description: When nunc-stans is enabled, instead of getting the
thread number from the environment variable MAX_THREADS, use the
value of config parameter nsslapd-threadnumber.
https://fedorahosted.org/389/ticket/48339
Reviewed by rmeggins(a)redhat.com (Thank you, Rich!!)
diff --git a/ldap/servers/slapd/daemon.c b/ldap/servers/slapd/daemon.c
index 82099bc..90f0523 100644
--- a/ldap/servers/slapd/daemon.c
+++ b/ldap/servers/slapd/daemon.c
@@ -1199,10 +1199,7 @@ void slapd_daemon( daemon_ports_t *ports )
#ifdef ENABLE_NUNC_STANS
if (enable_nunc_stans && !g_get_shutdown()) {
int ii;
- PRInt32 maxthreads = 3;
- if (getenv("MAX_THREADS")) {
- maxthreads = atoi(getenv("MAX_THREADS"));
- }
+ PRInt32 maxthreads = (PRInt32)config_get_threadnumber();
/* Set the nunc-stans thread pool config */
ns_thrpool_config_init(&tp_config);
ldap/servers/slapd/back-ldbm/ldbm_delete.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit 55434d308b4e459ba3a169eff94568312dba767c
Author: Thierry Bordaz <tbordaz(a)redhat.com>
Date: Tue Nov 3 15:59:54 2015 +0100
Ticket 47976: deadlock in mep delete post op
Bug Description:
When deleting the original entry, some DB pages are acquired in write.
The deadlock occurs because when reading the parent entry of the MEP entry
MEP plugin requires read access to one of the page acquired by the deletion of the original entry.
The read access can be granted if it is using the parent txn.
This bug requires that the parent entry of the MEP entry is not found in the entry cache, so
it requires database access
Fix Description:
Fix ldbm_delete, so that it reads id2entry db with parent txn
https://fedorahosted.org/389/ticket/47976
Reviewed by: Ludwig Krispenz, Rich Megginson (Thanks you !!)
Platforms tested: F17
Flag Day: no
Doc impact: no
diff --git a/ldap/servers/slapd/back-ldbm/ldbm_delete.c b/ldap/servers/slapd/back-ldbm/ldbm_delete.c
index f31d545..100a71d 100644
--- a/ldap/servers/slapd/back-ldbm/ldbm_delete.c
+++ b/ldap/servers/slapd/back-ldbm/ldbm_delete.c
@@ -477,7 +477,7 @@ ldbm_back_delete( Slapi_PBlock *pb )
* the parent. If we fail to lock the entry, just try again.
*/
while(1){
- parent = id2entry(be, pid ,NULL, &retval);
+ parent = id2entry(be, pid ,&txn, &retval);
if (parent && (cache_retry = cache_lock_entry(&inst->inst_cache, parent))) {
/* Failed to obtain parent entry's entry lock */
if(cache_retry == RETRY_CACHE_LOCK &&