Hello everyone,
I am currently attempting to use two server uplinks within the same notebook; however, I have encountered an issue where only one uplink is working while the other shutdown. Please assist me, How to enable both uplinks simultaneously within a single environment notebook. Thank you for your support.
It looks like the connect method doesn’t allow to set a different port number or whatever else is required for the two connections not to step on each other toes.
Have you tried creating 2 virtual machines?
Hi @stefano.menci , thanks for your reply,
Yeah creating two VM will work, but I’m wondering if there is any way I can do it with single VM ?
As I understand it, the Anvil Uplink library has a global variable representing the current connection. A global variable can have only one value (connection) at a time – per running Python instance. So the solution is to have more than one Python script running at a time, one script per connection.
Hi Phil,
I know the case is closed. Still, I wonder if you could clarify your point for me. What exactly has to run multiple times? I thought anvil frontend was able to distribute calls to different uplink endpoints that run in separate python instances (on different machines). They each have to maintain there own db-connections. Is this correct/still correct? If not, how do you scale the backend?
Please calm my nerves!
Thanks, Franz
Yes. (They don’t have to be on different machines, by the way. Just in different running instances of Python. For example, if you have 4 CPUs, you might assign 3 of them to different instances.)
As I understand it, the OP was trying to make multiple, simultaneous Anvil connections work in the same running Python instance, which the uplink library does not support. Currently, no Python program can connect to two Anvil apps at the same time. (That would certainly help with some database migrations, but it’s not currently available.)
My point was that this is not supported, so if he wants multiple connections, then each connection will have to be in a different running instance of Python, i.e., a different script, or different running instance of a script.
Phil,
Thanks for clarifying this. Most helpful!
Franz