give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "PROBLEM:  Kafka does not fully support the configured setting for KAFKA_MIN_INSYNC_REPLICAS. We found a scenario where the service is not provided when 2 of the 3 KBs in the RF set are active. Refer to the attached docker compose file that we used for the network; and in particular, note that we used these recommended network settings:   * 4 kafka brokers   * KAFKA_DEFAULT_REPLICATION_FACTOR=3   * KAFKA_MIN_INSYNC_REPLICAS=2   * orderer.yaml KAFKA_VERSION is unset; (file comment says default in fabric is 0.9.0.1; note latest kafka avail is 0.11.0)    SUMMARY:  We identified which 3 KBs were in the RF set. One at a time _(in the scenario below, we chose the newly elected leader every time, but that is not required because the last one always becomes the leader anyways when the 2nd last one is stopped)_, we docker stopped each of those. Then we restarted 2 of the 3. Note: we did NOT restart the last one stopped. Even after waiting 5 minutes, invoke transactions failed due to error SERVICE_UNAVAILABLE.    In this scenario _(see detailed steps below_), it appears Kafka fails to correctly manage its ISR set as nodes are stopped. For example, when 2 KBs are running and both are in the ISR set, stopping one causes it to be removed from the ISR set - leaving only the last node in the ISR set.    _This seems wrong, because that 2nd node does still contain the latest state of the partition - and that is important knowledge to have around in case the other/last node fails and cannot recover (which is exactly the scenario we are testing, and is exactly the reason for setting min_isr to 2 instead of 1). In fact, Kafka logic could leave it in the set, and also add a separate condition when processing transactions to confirm that at least min_isr KBs in the ISR set are also running/active (instead of just counting the number in the min_isr set)._    +We observed+ that after stopping the last KB and then restarting other KBs, they cannot elect a new partition leader and cannot resume functioning. That does not happen until THAT PARTICULAR LAST NODE is restarted - even if all the rest of the nodes are restarted.    +We expected+ that the network would resume functionality after recovery of KAFKA_MIN_INSYNC_REPLICAS=2 kafka brokers of the ISR set, but this did not happen (although it did work if the very last of the stopped KB was one of the restarted nodes).    Notes: We did not see any problems when we stopped all EXCEPT one KB and then restarted one or more additional nodes.    +Steps to Reproduce+:  (Please refer to attachment for the queries for data from the KBs)    Bring up a network, and query a KB on the channel to identify:  {noformat}  the KB nodes in RF set:  {3, 1, 2}  the KB nodes in the ISR set {3, 1, 2}  the partition leader = { 1 }{noformat}   # stop 1.  Then observe: ISR set = \{2, 3} and leader = 3.   # invoke - passed   # stop 3.  Then observe: ISR set = \{2} and leader = 2.   # invoke - failed as expected, since only 1 KB in RF set remains active   # stop 2 , and wait a minute.   # start 3.  Then observe: ISR set = \{2} and leader = -1. Active KBs = \{ 3 }   # wait 2 minutes.   # start 1.  Then observe: ISR set = \{2} and leader = -1. Active KBs = \{ 3,1 }   # invoke - failed: SERVICE_UNAVAILABLE   # wait 5 minutes, retry invoke - failed   # start 2. Then observe: ISR set = \{2,3,1} and leader = 2. Active KBs = \{2,3,1}   # invoke - passed         This related test scenario passed:  with all else being equal, in step 6, start kafka2 instead of kafka3. Then the invoke in step 10 passes."
Answer: 15645.0