Pil0tXia opened a new pull request, #4344:
URL: https://github.com/apache/eventmesh/pull/4344

   <!--
   ### Contribution Checklist
   
     - Name the pull request in the form "[ISSUE #XXXX] Title of the pull 
request", 
       where *XXXX* should be replaced by the actual issue number.
       Skip *[ISSUE #XXXX]* if there is no associated github issue for this 
pull request.
   
     - Fill out the template below to describe the changes contributed by the 
pull request. 
       That will give reviewers the context they need to do the review.
     
     - Each pull request should address only one issue. 
       Please do not mix up code from multiple issues.
     
     - Each commit in the pull request should have a meaningful commit message.
   
     - Once all items of the checklist are addressed, remove the above text and 
this checklist, 
       leaving only the filled out template below.
   
   (The sections below can be removed for hotfixes of typos)
   -->
   
   <!--
   (If this PR fixes a GitHub issue, please add `Fixes #<XXX>` or `Closes 
#<XXX>`.)
   -->
   
   Fixes #4341.
   
   ### Feature Description
   
   When creating a new WebHookConfig, the `writeToFile` method is invoked to 
create a file and write data. The `fileWatchRegister` can monitor file 
creation, modification, and deletion. It calls the `cacheInit` method during 
creation and modification events to store the WebHookConfig in 
`cacheWebHookConfig`.
   
   ### Bug Phenomenon
   
   Under normal circumstances, when copying the `webhook.github.eventmesh.all` 
configuration file, both ENTRY_CREATE and ENTRY_MODIFY events are generated as 
expected:
   
   ![Expected 
Behavior](https://github.com/apache/eventmesh/assets/41445332/efdda6e1-f9b4-4ff5-a1b5-8f9c77309197)
   
   The bug occurs when calling the `insertWebHookConfig` endpoint for the first 
time to create a WebHookConfig. Only the ENTRY_CREATE event is captured 
(abnormal; expected behavior is to have both events):
   
   ![Bug 
Behavior](https://github.com/apache/eventmesh/assets/41445332/55fd606c-69d5-4a25-b6e1-49c425a6b0ec)
   
   At this point, the file is empty, and the `cacheInit` method writes null to 
`cacheWebHookConfig`:
   
   ![Empty 
Cache](https://github.com/apache/eventmesh/assets/41445332/b4a8a37a-2841-42c3-a009-af5b96788f89)
   
   ![Null 
Cache](https://github.com/apache/eventmesh/assets/41445332/b567799b-2a3d-4bd5-9124-2f67b76f5bb4)
   
   However, the loop ends after one iteration, and `fileWatchRegister` does not 
call the `cacheInit` method again after the file has been written with 
WebHookConfig data. Consequently, `cacheWebHookConfig` does not have a valid 
value, and using the `queryWebHookConfigById` endpoint will not retrieve the 
WebHookConfig.
   
   ![Cache 
Issue](https://github.com/apache/eventmesh/assets/41445332/4e824843-2233-4328-a2db-9cc2f14bf21b)
   
   ### Initial Solution
   
   I resolved this bug by adding a slight delay after capturing the file event:
   
   ```java
   try {
       assert service != null;
       key = service.take();
       Thread.sleep(1000);
   } catch (InterruptedException e) {
       log.error("Interrupted", e);
   }
   ```
   
   With this delay, both ENTRY_CREATE and ENTRY_MODIFY events are captured. The 
`for (final WatchEvent<?> event : key.pollEvents())` loop iterates twice, 
allowing complete file data reading and the correct creation of WebHookConfig. 
This behavior is correct and matches expectations.
   
   ### Bug Cause
   
   The bug arises when the JVM retrieves file system events faster than file 
write speed. In such cases, the obtained file events and data are incomplete. 
When the JVM retrieves file system events slower than file write speed, the 
events and data are complete.
   
   In other words, when `fileWatchRegister` captures a file creation event, 
without adding a delay, `key.pollEvents()` will return only an ENTRY_CREATE 
event, not waiting long enough for the file's content to be fully written to 
disk.
   
   File write speed is beyond control, and a fixed delay isn't a robust 
solution. Interestingly, I found that this bug doesn't fully reproduce on a 
different machine.
   
   ### Better Solution
   
   My code should be more robust. A better solution is to ensure the file is 
fully created and written before executing actions. Therefore, I listen to the 
"ENTRY_MODIFY" event of the file rather than performing `cacheInit(file)` in 
the "ENTRY_CREATE" event. This approach provides more certainty in waiting for 
complete file writes.
   
   ### Documentation
   
   - Does this pull request introduce a new feature? (yes / no)
   - If yes, how is the feature documented? (not applicable / docs / JavaDocs / 
not documented)
   - If a feature is not applicable for documentation, explain why?
   - If a feature is not documented yet in this PR, please create a followup 
issue for adding the documentation
   


-- 
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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to