It takes time to close gateway

[yoshiteru-imamura]

There seems to be a 3 second wait on shutdown for managedchannel. Therefore, the wait time increases with the number of peers.

Is there anything I can do to shorten the shutdown time?

Can you shorten the waiting time?

Gateway.close->NetworkImpl.close->Channel.shutdown...PeerEventServiceClient.shutdown->lchannel.shutdown().awaitTermination(3,TimeUnit.SECONDS)

[bestbeforetoday]

You could try forcefully closing the Channel yourself. Get the Channel with Network.getChannel(), then call shutdown(true) on the Channel object.

[yoshiteru-imamura]

I appreciate your help. The gateway.close is now faster.

gateway.close(boolean force) or It would be even effective if you could release a version where we can select true or false in the config.properties setting.

Best regards,

[bestbeforetoday]

Good to hear that helped!

It would not be difficult to implement a configuration setting to set (or remove) the default shutdown timeout. However, this would still leave users with a (perhaps unexpected) shutdown delay by default, and having to go hunting for that setting.

An alternative might be to just change the behaviour of Gateway.close() so that it forcefully closes the underlying Channel. The difference is that it would no longer wait for any in-flight gRPC invocations to complete. I suspect any in-flight invocations are likely to be persistent event streaming connections that we don't need to wait for and, if the application is calling close(), it likely knows there are no in-flight invocations that it cares about.

What do you think about changing the Gateway.close() behaviour?

[yoshiteru-imamura]

I agree with you.

Call gateway.close() after all the processing is done. So there should be no problem in forcefully closes the underlying Channel.

It is also possible that some people may want to wait for any in-flight gRPC invocations to complete. I suppose it would be better if we could choose to force or wait.

For example, Add properties to builder's fluent interface. (forceClose=default true) Gateway.createBuilder().....forceClose(true or false) GatewayImpl.close() -> networks.values().forEach(NetworkImpl::close(forceclose)) NetworkImpl.close(boolean forceClose) -> channel.shutdown(forceClose)

Best regards,

[yoshiteru-imamura]

Hi. bestbeforetoday.

May I change the source code?

Can you please tell me the procedure for changing the source code?

[bestbeforetoday]

Can you please tell me the procedure for changing the source code?

Sorry for not getting back to you more quickly. Contributions are welcome. You will need to create your own fork and use that to create a pull request to this repository with your change. Details here:

https://docs.github.com/get-started/quickstart/contributing-to-projects

[krishan31]

@bestbeforetoday , hey we are facing one issue in our fabric network, We are using java for the fabric client part, But when we go for bulk transaction in batched we faced ### Timeout waiting for commit of transaction for some transaction.. Implementation

1. we have added commitHandler.NETWORK_SCOPE_ANYFORTX. but still getting timeout for the transactions. gateways are also changing according to User+channel.
2. In our connection profile we are using two peers who are responsible for endorsment and other connection regarding to outer world.
3. we have checked the latency it good,
4. SHould we close gateway woth every trxn and create with every txn Let us know what changes we shoudl do.

[bestbeforetoday]

@krishan31 The situation you are describing is not related to this issue. Please use Discussions for questions, or raise a separate issue for potentials bugs or feature suggestions.

You should definitely not close your Gateway instance on every transaction. Creating and using a new Gateway instance typically requires several gRPC network connections to be established, which are then all closed when you close the Gateway instance. Creating and discarding network connections on every transaction is expensive. You should aim to reuse a single Gateway instance for all interactions from a given client identity.

The newer Fabric Gateway client API (for Fabric v2.4+) dramatically improves this area by allowing you to use a single gRPC connection for all interactions with Fabric, regardless of the number of client identities you are using to transact, as described in the migration guide.

If you can use Fabric v2.4 or later, you should use the Fabric Gateway client API.