BewareMyPower opened a new issue, #24894:
URL: https://github.com/apache/pulsar/issues/24894

   ### Search before reporting
   
   - [x] I searched in the [issues](https://github.com/apache/pulsar/issues) 
and found nothing similar.
   
   
   ### Read release policy
   
   - [x] I understand that [unsupported 
versions](https://pulsar.apache.org/contribute/release-policy/#supported-versions)
 don't get bug fixes. I will attempt to reproduce the issue on a supported 
version of Pulsar client and Pulsar broker.
   
   
   ### User environment
   
   commit: 14b08210a02a4cd7dcffdd941a27d9fd7092a2d4
   
   ### Issue Description
   
   When I restarted a broker with only 1 producer connected, I found the close 
time was too long.
   
   Logs:
   
   ```
   2025-10-10T13:33:34,985+0000 [pulsar-service-shutdown] INFO  
ProducerIdManagerImpl - Shutdown complete: last producerId assigned 1479
   2025-10-10T13:33:39,033+0000 [pulsar-service-shutdown] INFO  PulsarService - 
Closing PulsarService
   2025-10-10T13:33:41,601+0000 [pulsar-service-shutdown] INFO  BrokerService - 
Disable broker in load manager completed in 2.555 seconds
   2025-10-10T13:33:41,673+0000 [pulsar-service-shutdown] INFO  BrokerService - 
Shutting down Pulsar Broker service
   2025-10-10T13:33:46,992+0000 [BrokerService-shutdown-phase2] INFO  
BrokerService - Continuing to second phase in shutdown.
   ```
   
   - Protocol handlers close: 4.048 s
   - Disable load manager: 2.567 s
   - Closing other tasks before starting closing `BrokerService`: 0.072 s
   - Shut down all event loops: 5.319 s
   
   The main close time come from closing event loops gracefully.
   
   ### Error messages
   
   ```text
   
   ```
   
   ### Reproducing the issue
   
   ```java
   import java.util.Optional;
   import java.util.concurrent.TimeUnit;
   import java.util.function.Supplier;
   import lombok.Cleanup;
   import org.apache.pulsar.broker.PulsarService;
   import org.apache.pulsar.broker.ServiceConfiguration;
   import org.apache.pulsar.zookeeper.LocalBookkeeperEnsemble;
   import org.testng.Assert;
   import org.testng.annotations.AfterClass;
   import org.testng.annotations.BeforeClass;
   import org.testng.annotations.Test;
   
   @Test
   public class BrokerEventLoopShutdownTest {
   
       private LocalBookkeeperEnsemble bk;
   
       @BeforeClass(alwaysRun = true)
       public void setup() throws Exception {
           bk = new LocalBookkeeperEnsemble(2, 0, () -> 0);
           bk.start();
       }
   
       @AfterClass(alwaysRun = true, timeOut = 30000)
       public void cleanup() throws Exception {
           bk.stop();
       }
   
       @Test(timeOut = 60000)
       public void testCloseOneBroker() throws Exception {
           final var clusterName = "test";
           final Supplier<ServiceConfiguration> configSupplier = () -> {
               final var config = new ServiceConfiguration();
               config.setClusterName(clusterName);
               config.setAdvertisedAddress("localhost");
               config.setBrokerServicePort(Optional.of(0));
               config.setWebServicePort(Optional.of(0));
               config.setMetadataStoreUrl("zk:127.0.0.1:" + 
bk.getZookeeperPort());
               return config;
           };
           @Cleanup final var broker0 = new PulsarService(configSupplier.get());
           @Cleanup final var broker1 = new PulsarService(configSupplier.get());
           broker0.start();
           broker1.start();
   
           final var startNs = System.nanoTime();
           broker0.close();
           final var closeTimeMs = 
TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startNs);
           Assert.assertTrue(closeTimeMs < 1000, "close time: " + closeTimeMs + 
" ms");
       }
   }
   ```
   
   Outputs:
   
   ```
   java.lang.AssertionError: close time: 5132 ms
   ```
   
   It can be reproduced by the simple test above added to `pulsar-broker`. As 
you can see, even though the `close()` method is called immediately after 
`start()`, it still take 5+ seconds to complete.
   
   ### Additional information
   
   _No response_
   
   ### Are you willing to submit a PR?
   
   - [x] I'm willing to submit a PR!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to