-
Notifications
You must be signed in to change notification settings - Fork 13
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
NGAS subscription does not check if subscriber ID already taken before creating new entry #50
Comments
@smclay thanks for reporting this. In the email exchanged we had about this I mentioned that simply we should check for the presence of the subscriber ID on the database and act differently depending on that result (i.e., succeed?). But now that I think about it a bit more, we should probably have the full picture before deciding how to proceed with this one. The deeper problem I remember you are having is that your logfiles are getting flooded with these messages. This means there is a counterpart to this server that is trying to create this subscription without ever giving up. That counterpart is probably this: ngas/src/ngamsServer/ngamsServer/ngamsSrvUtils.py Lines 138 to 141 in 8fa1c39
This check sits inside a loop that won't finish until all subscriptions are successfully made. Subscription creation is currently successful only if a new subscription is effectively added to the database. The question is then what to do if a subscription with the same ID comes in. Here are some options:
I don't find options 1 and 2 too attractive because they declare a success even when a new subscription was not created, which I see as a bit of a contradiction in the semantics of the command; option 1 in particular is too simplistic, as it assumes too much. And if we go for option 3 or 4 we'd need to change the code I quoted above to take into account the new return code and adjust itself. Thoughts? There are probably other alternatives I haven't thought of. |
@rtobar I tried to look at the subscriber side logs but unfortunately they have already been deleted. I am unsure but I believe when the subscriber shuts down it sends an UNSUBSCRIBE command to the subscription publisher. Is that correct? Therefore in the event of a crash or messy shutdown the subscription entry will probably not be removed. On restarting the subscriber it will send a new SUBSCRIBE command which should result in an identical request to the entry already stored in the database. I think this is probably the most likely scenario for duplicate requests which should be quite harmless. Therefore I think I agree that options 3 and 4 are better solutions. The subscriber can log a warning when option 3 occurs. In the event of option 4, I would suggest a notification email is sent to alert the NGAS administrator. If the administrator is expecting data to flow but the subscription is rejected it is probably better to inform them so they can act on it otherwise they may not notice and the problem could go undetected for hours or days. |
This change is the core of #50: it checks if a subscription for the given ID exists or not before attempting insertion. If one exists, the server replies to the client with different HTTP codes depending on whether the subscription is identical to the one the client is trying to add or not. In both cases the NGAS status object still reports SUCCESS though, but we might want to change that. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
This change is the core of #50: it checks if a subscription for the given ID exists or not before attempting insertion. If one exists, the server replies to the client with different HTTP codes depending on whether the subscription is identical to the one the client is trying to add or not. In both cases the NGAS status object still reports SUCCESS though, but we might want to change that. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
This change is the core of #50: it checks if a subscription for the given ID exists or not before attempting insertion. If one exists, the server replies to the client with different HTTP codes depending on whether the subscription is identical to the one the client is trying to add or not. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
@smclay I've pushed a few changes to the Could you give these changes a go? I've added unit tests for the changes in |
@rtobar thanks for the update. I will build new packages and deploy over the weekend. Hopefully I will have some test results next week. |
@rtobar I have carried out tests. For the most part it is working well. If the subscription already exists I get the following log messages from the subscriber host...
There appears to be two bugs. The log message "151 Different subscription with ID '%s' already exists, giving up" has not been formatted properly and there is a On the publisher side we get the following log messages...
I also receive an email from the subscriber...
There is a typo 'fit' -> 'fix' in the email message. |
@rtobar I noticed that shutting down the subscriber removes the subscriptions from the |
@smclay thanks for the detailed report. I've addressed all the points you mentioned (typo in email, unformatted log statement, |
@rtobar I tested your latest changes today. Everything looks good...
I think we can now close this issue. Thank you for the improvements. |
Thanks @smclay for double-checking the new changes, I've just merged the new |
It would appear that when NGAS receives a request for a new subscription it does not check if the subsriber ID is already in use before attempting to create a new entry in the NGAS_SUBSCRIBERS table...
The text was updated successfully, but these errors were encountered: