I am on a Tech support team for a University. Our students have a seminar where they all meet in a chat room once a week. The seminar is Flash content. They are required to install Flash Player to be able to get into their seminar. In the scenario of a student getting booted out of the seminar, could Flash Player be a contributing cause? Of course WiFi is normally the culprit, but I wonder if Flash Player should technically be considered for a boot out concern. If reinstalling/enabling Flash should be a troubleshooting step or if it wouldn't be something to consider at all. Thank you!!
[Moved from the non-technical Lounge Forum to the Program forum... Mod]
[Here is the list of all Adobe forums... https://forums.adobe.com/welcome]
When you ask a question you need to provide some basic information
-Forum quick start https://forums.adobe.com/docs/DOC-5601
Mac or Windows, and EXACTLY which version of the operating system?
I know that Microsoft has LOCKED Edge and Internet Explorer, so Microsoft does Flash Player updates in those programs, but I don't know if that is your problem, since you don't post any information
The specs would be any Windows machine and any Mac machine. The only constant variable is that they need Flash Player to get into their seminar. The question is whether or not Flash Player would be a troubleshooting step if they keep getting booted out of the seminar room where they are chatting with the classmates. If reinstalling Flash Player or enabling it would be a valid troubleshooting step or if that shouldn't be considered at all.
In essence, Flash Player is a language runtime environment, similar to the Java JRE. We provide a set of low-level APIs, and content and application developers write ActionScript that exercises those APIs. Under most circumstances, there's ample room for the content provider to implement reasonable retry and error handling strategies, and to give just a little context, Flash Player's networking support is robust enough to handle commercial-grade video streaming for everyone from HBO to the NFL.
In addition, in most instances, the browser is mediating all of the network access. Flash Player is asking the browser for resources on the network, and the individual browser and/or operating system is doing the heavy lifting of making connections, implementing the appropriate networking protocol, etc. As you can probably guess, this means that there are nuanced quirks specific to particular operating system and browser combinations. To put it in context, there are something like 36 variants of Flash Player that we ship, and 6-9 distinct variants that your students would most commonly be using. Our role is to smooth out the warts across all of those platforms to the extent possible so the developers can focus on building great experiences, but the specifics definitely matter when trying to understand low-level behavior in the runtime itself.
More importantly, "getting booted out of the room" doesn't tell us anything about Flash Player itself. That's a symptom of a problem in the higher level application. All I can tell you based on the information that you've provided is that "something happens", and business logic in the conferencing software returns the user to the lobby. All I that can really infer with confidence from that is that we didn't crash. To me, that indicates that the problem could probably be caught and handled by the application itself.
If I were to take a SWAG, it would be that they have a flaky backend service (e.g. they built a cloud-based backend that uses a distributed database that's configured to prefer availability over consistency, and they've used it for maintaining user state, such that critical user state evaporates depending on which node the request goes to), and/or they're not implementing a robust-enough recovery strategy to handle adverse conditions in your network environment, and should maybe catch networking exceptions and retry them over a long timeout period before declaring the failure state that leads them to return the user to the lobby.
What I am fairly confident about, is that our networking APIs provide the ability to build a robust implementation that works in real-world conditions, but before you can have a conversation about what needs to get fixed, you need to understand exactly why it fails, and you're not going to do that easily as an outside observer.
A conversation with your vendor is in order. Ideally, they already have logging that can tell you why users get booted to the lobby constantly. If not, there are facilities available (Local Shared Objects, etc.) that they could leverage to store information about fatal errors on the local machine until they start talking to the client again, at which point, they could collect them.
If, in the unlikely event that the vendor discovers an language-level issue that needs our intervention, they're in a position to have detailed information about the failure itself and the scenario that leads to the failure. Without that, we're just blindly guessing about stuff, which isn't going to get your problem solved. They're more than welcome to reach out to me directly (they can send a PM by clicking my username), and I'd be happy to get a conversation going at an engineering level.
One thing that might help you facilitate that conversation with the vendor would be to reproduce this problem on a machine running the Flash Player Debugger variant Normally, Flash Player suppresses runtime errors, but if there's an instance in the application logic where they're failing to handle an Exception like a networking failure, we might throw a runtime error dialog immediately before the user is booted from the room that could help them in chasing the problem down. Again, this doesn't point to a problem in Flash Player or ActionScript, but may be useful in helping them to understand the condition that leads to the symptom that you're complaining about