I have 3 VSE's running in my server.
I have a virtual service with port 40101 and basepath in VSE1. I am not able to run a virtual service with same port and different base path in 3rd VSE. But i am able to run the virtual service with same port and different basepath in VSE1.
That would be correct.
One process can hold a port open. In your case it's a virtual service running in VSE1. I'll assume you're running HTTP virtual services, so it's the HTTP bit that's holding the port open.
If you have another process, for example on VSE3, it cannot open the port, because the port is already open elsewhere.
In VSE1, you can start another virtual service of the same protocol, connected to the same port. The virtual service itself is a thread (I've probably got the terminology wrong, and I'm sure someone will correct me), and the protocol support is the process.
So, a second HTTP virtual service can use the same port, as long as its in VSE1.
If you try to open a TCP virtual service on the same port, even in VSE1, you will receive a "port already open" error, because TCP and HTTP are different processes.
If you try to open a HTTP virtual service on the same port, in a different VSE, you will receive a "port already open" error, because they are different processes.
It's not a DevTest thing. Try running two different web servers on port 80, and you see the same behaviour.
Thanks Rick for your quick reply.
So i can not run two virtual services in different vse with same port. By any chance is there any way to make it work
As you are running three VSEs on a single physical box, as Rick.Brown mentioned - it is an architectural issue.
Would like to understand the issue with running both the Virtual Service on VSE1 or any other single VSE process.
I have 3 vse's in a single machine. I am aware that we can run two vs in sinlge vse with same port and the different base path there is no problem in this. But the reason I am asking is there any way to run a virtual service vse3 with the same port which is already running in vse1 ?
No, the TCP stack stops that. As Prem said, it's an architectural issue, of TCP/IP.
Well, if you chose the "bind only" option in your listen step, you can play around with your TCP options, but I've never managed to do that successfully - it's too technical in-depth networking for me.