While a TCP connection is a well-defined concept, “stream” is a somewhat ambiguous term, depending on context.
What you describe – closing a TCP connection while data may still be flowing – is a problem on the application layer, within the application protocol. It’s nothing you can fix on the transport layer (in TCP). However, applications and protocols above the transport layer are explicitly off-topic here. You should talk to application support or development.
Is there any logical “one to tone” relationship between TCP connection and output stream
In that context (as far as I understand), the stream is a chunk of data transferred over TCP. So yes, your stream likely has a 1:1 relationship with the TCP socket connection (in theory, you could also split a data stream over multiple TCP connections, depending on the application protocol/L7).
stream will be created only if conneciton is there) , for example lets say I don’t release the stream back as soon as data is sent to server
Here you are venturing into application land which is off topic here.
Will this mean that even if next message comes into application and since connection is active , it will not be able to send the message to server because the stream is not available ?
Again, you’re mixing layers. TCP only does what you tell it to. You need to make sure that the application provides proper control of TCP. A clean state diagram would likely help.
To me it sounds like you’re missing a got data to send – fire away handshake on the application layer and you’re expecting TCP to do that for you. It doesn’t work that way. You do need to frame data on L7 unless you generally use two transport layer connections, one for control and another, dynamic one for data (like FTP does). A single, contained connection with proper framing is usually preferred.