search

ambient-weather / api-docs

AmbientWeather.net API Documentation
64 stars 41 forks source link

Can I run multiple application instances using the same app key? #12

Closed mhilbush closed 5 years ago

mhilbush commented 5 years ago

Let's say I have the following configured in my ambientweathetr.net dashboard. The keys shown below are made up (obviously) for the purposes of this example. appKey = XYZ apiKey1 = ABC apiKey2 = DEF

In my current environment, I have two instances of my app, one for production and one for test.

I'm seeing the following behavior.

The Test app id running with appKey and apiKey1. It is successfully receiving data events through the real-time api.

When I start the Production app with appKey and apiKey2, it starts to receive data events through its real-time api connection; however, the Test app stops receiving data events (sometimes immediately and sometimes after a few minutes). If I restart the Test app, it starts to receive data events again, but the Production app stops receiving data events.

Is this the way it's supposed to work? I thought the app key could be shared across multiple app instances. Or, does each instance of the app need to have its own api key AND app key?

mhilbush commented 5 years ago

Ok, I'm not sure why, but it seems to be working now. Both instances ran all night without issue.

mhilbush commented 5 years ago

I've seen this happen several more times over the past couple days. When I start the process to retrieve events on one host, I stop receiving events on the other host where the process is already running.

I don't think this is environmental on my side, since the processes are running on different hosts, in different locations, on separate networks. The only thing in common is that they share the same app key (and the same code base which you can see here).

I may request another app key so that I can run one process with one key and the other process with the other key. That will eliminate any issue with the app key being the root cause.

mhilbush commented 5 years ago

I also should note that I'm still running on dash2.ambientweather.net. I switched over to that when I was helping @owise1 test the load balancer fix. https://github.com/mhilbush/openhab2-addons/blob/ambient-weather-binding/addons/binding/org.openhab.binding.ambientweather/src/main/java/org/openhab/binding/ambientweather/internal/handler/AmbientWeatherEventListener.java#L46

mhilbush commented 5 years ago

I updated my prod instance with a second app key at 10:15 on 12/17. Prod and test now have different app and api keys (although they still share the same weather stations). I'll observe for several days to see if the problem reoccurs.

mhilbush commented 5 years ago

@ambientweather @owise1

I'm pretty sure there's a problem, and I think it might be on your end. I have no other plausible explanation for what's happening.

First, I'll summarize my configuration.

Host A is using app key A1 and api key A2 Host B is using app key B1 and api key B2

Hosts A and B are on different physical networks in different geographic locations (one is in NJ and one is in MD).

The app and api keys are contained in my ambientweather.net dashboard, which has 2 weather stations configured - a WS-1401-IP and a WS-8482. My ambient weather dashboard account is mark at hilbush dot com.

The relevant socket.io implementation on my end is located here. https://github.com/mhilbush/openhab2-addons/blob/ambient-weather-binding/addons/binding/org.openhab.binding.ambientweather/src/main/java/org/openhab/binding/ambientweather/internal/handler/AmbientWeatherEventListener.java

The above code is running on both hosts, and both hosts are receiving data events for both weather stations. All good so far.

When I stop the process on one host, the other host stops receiving data events. The other host doesn't get a disconnect. It just stops getting events permanently, until the process on that host is restarted.

Stopping the process involves sending an unsubscribe event, followed by a disconnect, as can be seen in this part of my code. Restarting the process that was stopped resumes events for that host, as it should.

This behavior is reproducible, but not 100% of the time. It's the fact that it's not reproducible 100% of the time that's a bit confounding.

I have a theory, and it's based on a few assumptions about your infrastructure.

Given the above, and assuming that both of my hosts are being serviced from the same instance... When one of my hosts unsubscribes, is it possible that the subscriptions from both hosts are being unsubscribed?

I have one more test I'm going to try. I'm going to make a change to my code that lets me subscribe/unsubscribe on demand without disconnecting. That may help narrow down whether it's the unsubscribe or the disconnect that's causing the problem.

mhilbush commented 5 years ago

I have one more test I'm going to try.

I was able to confirm that sending an unsubscribe from one host results in the event stream to the other host stopping. Again, this doesn't occur 100% of the time, and I think that has to do with where/how the subscriptions are managed on your end.

owise1 commented 5 years ago

Thanks for the sleuthing! This all makes sense. We should be able to take a look in the new year.

mhilbush commented 5 years ago

@owise1 Did you fix this? I haven't seen the issue after numerous unsubscribes over the past 2 or 3 days.

mhilbush commented 5 years ago

One other thing I wanted to mention, as it's tangentially related to this issue.

If I send a second subscribe with the same API key(s) as the first subscribe without sending an unsubscribe for the first subscribe, the API sends me multiple data events for the MAC addresses associated with the dashboard containing the API key(s).

I discovered this due to a bug in my code. While I realize this usage violates the subscribe/unsubscribe model, excessive use of this "feature" could (intentionally or unintentionally) cause a denial of service attack (i.e. repetitive subscribes until all server resources are consumed). Would it not be better to replace an existing subscribe when subsequent subscribes are received for the same API key(s)?

owise1 commented 5 years ago

@mhilbush Is the original issue still fixed for you? We didn't update any code but we did discover and fix some internal networking issues around the time you referenced.

Also, I was able to track down the problem with "multiple subscribes" that you mentioned. That will be fixed in the next deploy. thanks for your help.

mhilbush commented 5 years ago

@owise1 I've not seen this problem in almost 2 weeks. I suspect the networking change you made fixed the issue. I'll post back here if I see it again, but for now I think we can consider this resolved.

problem with "multiple subscribes" 👍