-
Notifications
You must be signed in to change notification settings - Fork 6
Handling pingrequests #46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
# Conflicts: # pom.xml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes requested. Reviewed entire PR up to commit 3ecdb51
Reviewed 273 lines of code across 5 files in 1 minute(s) and 33 second(s).
See details
- Skipped files: 0 (please contact us to request support for these files)
- Confidence threshold:
50% - Drafted
0additional comments. - Workflow ID:
wflow_eXMs2Hr4Nvushi7L
Something look wrong? You can customize Ellipsis by editing the ellipsis.yaml for this repository.
Generated with ❤️ by ellipsis.dev
|
|
||
| public class PackageReader { | ||
| private final Map<InetAddress, Boolean> connectPackageSent = new HashMap<>(); | ||
| public final Map<InetAddress, Boolean> connectPackageSent = new HashMap<>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The 'connectPackageSent' field is public, which violates the principle of data encapsulation. Consider making this field private and provide public getter and setter methods if necessary.
| public class PingHandler { | ||
| private static final Logger logger = Logger.getLogger(PingHandler.class.getName()); | ||
|
|
||
| private PingHandler() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This class appears to be a utility class, but it can still be instantiated. Consider making the class 'final' and throw an exception from the constructor to prevent instantiation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Private constructor is fine by me, no need to throw exception :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BarbieQkiller Even if the constructor is private it's actually possible to use it with reflection. And if we look at Hibernate for example that can create instances of Entity classes or ValueObjects it doesn't care about the access modifier.
https://stackoverflow.com/questions/71824535/how-to-make-sure-instance-of-a-class-with-a-private-constructor-can-not-be-creat
That's why it can be a good practice in a bigger enterprise application to throw an exception from the private constructor in a utility class to prevent this happening without noticing.
| return bytesRead > 0 && buffer[0] == (byte) 0xC0; | ||
| } | ||
|
|
||
| public static Boolean sendPingResponse( OutputStream outputStream) throws IOException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of returning a Boolean value to indicate success or failure, consider letting this method throw an exception if the operation fails. This would be more idiomatic in Java.
Win-ther
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should probably encapsulate the connectPackageSent-map again. And is there a reason for the removal of the isCleanDisconnect() tests?
Other than this, the code looks good.
|
When running tests for this branch everything works but after merging main into this branch the following test starts failing: at org.fungover.thunder.PackageReaderTest.shouldReturnFalseIfDoubleConnectMessageIsReceived(PackageReaderTest.java:143) assertFalse(packageReader.isValidConnection(socketMock)); Fails. |
|
@fungover/java23 Do we have any activity in fixing the comments from reviewers in this PR? |
# Conflicts: # src/main/java/org/fungover/thunder/ClientHandler.java
3ecdb51 to
8a87230
Compare
| assertTrue(PingHandler.isPingRequest(new byte[]{(byte) 0xC0},1)); | ||
| } | ||
|
|
||
| // @Test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code that is disabled by comments could be removed :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the feedback! Since the tests did not work previously, they were commented out. We have now updated the tests accordingly.
| public class PingHandler { | ||
| private static final Logger logger = Logger.getLogger(PingHandler.class.getName()); | ||
|
|
||
| private PingHandler() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Private constructor is fine by me, no need to throw exception :)
altmannk
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess you did a rollback? Heads up, I tried to run ClientHandlerTest in your branch but got stuck at the second test.
| System.out.println("Received MQTT PINGREQ message from client"); | ||
| PingHandler.sendPingResponse(outputStream); | ||
| } else { | ||
| // Handle other types of messages |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this is because of a rollback?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes thank you for the feedback, ClienthHandler tests are currently not working, we commented the tests out and initiated a new issue (#60 ) for resolution
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes requested. Incremental review on commit 9cebb1c
Reviewed 115 lines of code across 2 files in 1 minute(s) and 22 second(s).
See details
- Skipped files: 0
- Confidence threshold:
50% - Drafted
0additional comments. - Workflow ID:
wflow_JoMTg7rEItBfXyvN
Something look wrong? You can customize Ellipsis by editing the ellipsis.yaml for this repository.
Generated with ❤️ by ellipsis.dev
|
|
||
| assertEquals(Collections.singletonList(socket2), clientHandler.getClients()); | ||
| } | ||
| // @Test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tests in this class have been commented out. Please uncomment them and ensure they pass with the new changes. If necessary, update the tests to reflect the changes in the code.
| } | ||
|
|
||
| private static boolean isDisconnectPackage(int bytesRead, byte[] buffer) { | ||
| public static boolean isDisconnectPackage(byte[] buffer, int bytesRead) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The order of parameters in the isDisconnectPackage method has been changed. Please ensure that all calls to this method have been updated to reflect this change.
|
| clientHandler.handleConnection(socketMock); | ||
|
|
||
| assertEquals(0, clientHandler.getClients().size()); | ||
| assertFalse(packageReader.isValidConnection(socketMock)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test should be checking the client count, not the validity of the connection. Consider revising the test to check if the client count remains 0 after an invalid client tries to connect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes requested. Incremental review on commit 0c5c87f
Reviewed 128 lines of code across 1 files in 2 minute(s) and 43 second(s).
See details
- Skipped files: 0
- Confidence threshold:
50% - Drafted
1additional comments. - Workflow ID:
wflow_VZVS3mC58YComMUy
View 1 draft comments
These comments were drafted by Ellipsis, but were filtered out of the final review. They're included here so you can see our internal thought process and help you configure your ellipsis.yaml.
Drafted 1 additional comments
Comment at src/test/java/org/fungover/thunder/ClientHandlerTest.java:44
This test could be more comprehensive. Consider first checking if the client count increases after a client is added, and then check if it decreases after the client is disconnected.
Something look wrong? You can customize Ellipsis by editing the ellipsis.yaml for this repository.
Generated with ❤️ by ellipsis.dev
Win-ther
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The function you wanted to implement works. Clients can send pinqrequests and can recieve pingresponse from the broker. But when you implemented this, you changed things in ClientHandler and ClientHandlerTest that caused our coverage in ClientHandler to go from 92% to 50%. This is probably something you should be able to change or revert so that the coverage becomes a bit better.
Rishad11
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I can tell, the code looks solid, and the tests cover essential scenarios.


Related Issue(s)
Closes #17
Proposed Changes
We have added functionality for pingrequests and pingresponse. Added class "PingHandler" with additional tests.
Summary:
This PR adds support for handling MQTT PINGREQ messages and clean disconnects by introducing a new
PingHandlerclass, updating theClientHandlerandPackageReaderclasses, and commenting out tests in theClientHandlerTestclass.Key points:
PackageReaderclass to support clean disconnects.PingHandlerclass with methods for handling MQTT PINGREQ messages.ClientHandlerto usePingHandlerfor handling PINGREQ messages.ClientHandlerTestclass.PackageReaderTestandPingHandlerTestto cover new functionality.Generated with ❤️ by ellipsis.dev
Summary:
This PR introduces a
PingHandlerclass for handling MQTT PINGREQ messages and clean disconnects, updates theClientHandlerandPackageReaderclasses, modifies theClientHandlerTestclass to cover the new functionality, and creates a new issue to address the issue with the tests in the ClientHandler class.Key points:
PingHandlerclass for handling MQTT PINGREQ messages and clean disconnects.ClientHandlerandPackageReaderclasses to support new functionality.ClientHandlerTestdue to issues.ClientHandlerTest,PackageReaderTestandPingHandlerTestto cover new functionality.Generated with ❤️ by ellipsis.dev