checked the logs and removed the logs unused..xml and rb timing 18hr..need to discuss with Bessem

Configured the parameter value as true in nep-server-config.xml and RB triggered

checked the logs rleated monitors added the monitoring logs and released the patch with confirmation property in config file as true

• Investigate the issue

logs shared for RB issue in AP circle

checked the logs dont have monitoring logs checked for the params requested logs again and checked

checked the logs , analysed with Bessem the sample case added monitoring logs and found sample cases that taking time.

logs shared for AP circle for RB issue

checked the hazelcast error shared by telco discussed with bessem searching for relatedconfig in code

checked the logs for parts taking time. ...rb running not upto monitoring logs

checking the logs of 6,7,8 september calculating time taking part in ran route build discussed with Bessem

• Investigate the issue

• Investigate the issue

checked the other RB process parts thats taking time and shared the full analysis to Bessem and discussed same with bessem

i have enabled the parameter "<parameter name="nep.npt.Enable_Dimension" value="false" />"
for AP circle RB isses

log analysis of server .45 and .177

we have shared memory details like RAM ,CPU details from AP circle to Abir .

we have shared logs from AP circle for The RB execution is in progress since October 11 and is still running. The total runtime has reached approximately 38 hours

after apply patch 3.7.71.495 on AP circle prod and monitored logs but still RB process was running since last 38 hrs .

The RAM and CPU have been upgraded in the AP circle.

i have shared the logs from AP circle for RB issues to priyasha

i have shared the AI logs of after and before rollback patch to bessem

The RB process is currently taking around 37 hours to complete and is blocking the next cycle. This has been escalated to the development team to analyse the root cause of the delay.

shared logs from AP circle for RB process is taking more time to completed .

shared AP logs for RB issues

Router Builder Monitoring in AP Circle

Monitored the Router Builder process in the AP circle along with the MS team.

During the activity, the application crashed.

Restarted the application and validated the services.

Shared all findings and observations with the respective teams.

monitor the RB process on the AP server. It is now completing in just 1 hour and 30 minutes, whereas previously it used to take around 37 hours. The logs have been shared with the development team to verify if any data is missing.

The NEP 534 build patch has been deployed on the DL and AP circles to improve the RB process. However, even after deployment, the RB process is still taking 46 hours to complete in the AP circle, and 24 hours in the DL circle. review the logs during the RB process and share them with the development team for further analysis of the delay issue.

discussion with L2 for logs and L3

XML IMPORT AND RB TRIGGER MANUALLY TO CHECK PATCH 536

monitor the rb logs in and share the ovservation with dev team

PATCH 536 TESTING

TESTING PROCESS, XML import RB triggered and logs validated on test server

patch 540 testing

i have shared RB logs from .37 and .177 test servers

check the rb late issue in AP circle and share the observation with dev

Build 3.7.71.534 PATCH AND TESTING

configure the AS clone schema on test server and restarted the nep application

NEP_AIRTEL - Build 3.7.71.543 - Successful deployed on .45 and configured RJ DB.

NEP_AIRTEL - Build 3.7.71.543 - Successful deployed on all prod servers

shared logs from AP circles

internal discussion with l2 and l3 team and validating the RB result and logs

configure the AS clone schema on test server and restarted the nep application for RB testing

• adding logs

RB triggered after patch applied

Patch has been deployed on all test server and DB has been configured

Patch has been deployed on test servers and Db configured as well

Raised the RB issue in the UE circle, which has been pending for the last one month, and shared the relevant logs with the Dev team. Requested them to review and resolve the issue on priority.

NEP_AIRTEL
3.7.71.550 patch has been deployed on all test vms and also RJ db configured on .45 test.

Memory statistics from SAR files for the AP server were analyzed for the requested period. Peak memory utilization was observed during the RB execution window, which ran from 10-Jan-2026 20:08 to 12-Jan-2026 21:46. Relevant server logs and SAR data highlighting the high-memory usage duration have been shared with the Dev team for analysis and ongoing fixes.

i have shared serverlogs from 45 after triggered full RB .

NEP_AIRTEL - Build 3.7.71.550 - Successful deployed on .45 .

Updated the values in nep-server-config.xml as per the development team’s request and reconfigured the clone DB on the respective test servers.

server log from L2 and call with L3

i shared logs from AP cirlcle

configure the RJ clone schema on .45 test server and restarted the nep application for RB testing

TESTING FOR PATCH 550

shared logs

i have shared logs

i have run RB on .37 then monitored logs and shared on mail

configure the AS clone schema on .177 test server and restarted the nep application for RB testing

i have configured HP DB on .37 and restarted the services then run RB .

i have shared logs from AP circle for delay RB import process .

i have create tables for Rb process from 37 and 177 then shared on mail

i have shared rb logs from 37 and 177 test serevrs .

Configured AS clone schema on test server, validated setup, and restarted NEP application for smooth operation.

TRIGGER RB, REPORT EXTRACT AND CALL WITH L3

Configured HP clone schema on test server, validated setup, and restarted NEP application for smooth operation.

configure the DL clone schema on test server and restarted the nep application

call with L2 L3 for patch 554 on prod and validation of same

The DL clone schema has been successfully configured on the test server, and the NEP application has been restarted to ensure that all changes are properly applied and functioning as expected.

The AS clone schema has been successfully configured on the test server, and the NEP application has been restarted to ensure that all changes are properly applied and functioning as expected.