Repository navigation
Sometimes the same image is not displayed in a picturebox. Image.FromStream #1023
Description
Ser Gar asked 2017-08-16 15:49:06 UTC
Hi!
Sometimes the image is not displayed in a picturebox, it's the same image (when i go to image url from inspector doesn't show anything), I have to reopen the page a couple of times to show it. Tested in firefox and IE.
The image is loaded like
......
var ms = new MemoryStream(BytesMainLogoMini);
return Image.FromStream(ms);
......
See attached image
Thanks in advance!
Activity
itg-assistant commentedon Jun 12, 2026
Luca answered 2017-08-16 15:55:08 UTC
Please send a small sample code. Using Image.FromStream can be tricky since the stream is kept open and the image may not be loaded at once so, depending on timing, you may have an incomplete image. It's usually better to create a new image and dispose the stream.
using (var ms = new MemoryStream...) {
return new Bitmap(Image.FromStream(ms));
}
The stream should be kept open only the case of animated gif images.
itg-assistant commentedon Jun 12, 2026
Ser Gar answered 2017-08-18 03:32:11 UTC
It seems that this is related only when I am in a place in a network where the internet provider has a kind of load balancer. I see that the requests sometimes go for one ip and sometimes for another. In these cases the images are sometimes shown or not. Does the image response [ /component.wx?sid = ... ] have any validation about the client ip?
I tried disabling enablewebsocket in default.json but no success.
Any advice to avoid that, or some way to configure something?
Thanks in advance!
itg-assistant commentedon Jun 12, 2026
Luca answered 2017-08-18 17:03:30 UTC
The component.wx request needs the instance of the component, which means that it needs the session indicated by the sid argument. When using a load balancer you need to set it to using "sticky sessions". When using WebSocket it's irrelevant since the WebSocket is already a "sticky" connection. But the http requests (images or data loads) may get rerouted, so you need t he sticky session mode.
Load balances do that in several ways: they can use a cookie or use the IP, or a combination of IP and UserAgent or other info to identify a request source.
http://wisej.com/docs/html/LoadBalancing.htm
The docs don't mention this requirement, will add.
itg-assistant commentedon Jun 12, 2026
Ser Gar answered 2017-08-18 17:29:36 UTC
In this case, load balancer doesn't exists in server/website
Client/browser is in [subnetwork/lan/private ip].
Public ip addresses (of client) are exposed only by internet provider (has a load balancer)
Client/browser requests goes for dinamic public ISP address.
Issue not happens if I use for example a VPN windows app in client.
For example client/browser internal private ip is 192.168.0.55, when open a wisej app, maybe wisejapp in server would see a 189.216.40.55 remote client or some another time would see 189.216.40.100 remote client
See attached image
What is the keyword and posible values for sticky sessions? Is in default.json?
Thanks in advance!
itg-assistant commentedon Jun 12, 2026
Luca answered 2017-08-18 17:34:39 UTC
Sticky session is a load balancer setting, it cannot be controlled by the web application since the redirection occurs before the app is reached. What load balancer are you using?
itg-assistant commentedon Jun 12, 2026
Luca answered 2017-08-18 17:36:21 UTC
The image came in late, I see that you have only 1 wisej app server and the load balancer front end may come in with different IPs. In this case try to add “validateClient”:false in Default.json.
itg-assistant commentedon Jun 12, 2026
Ser Gar answered 2017-08-18 17:39:26 UTC
I don’t know since is something of ISP internet provider specific. The issue is in client/browser and ISP architecture network, not the server.
itg-assistant commentedon Jun 12, 2026
Ser Gar answered 2017-08-18 17:50:50 UTC
Great I’ll try it. Now I see that could be due to “fingerprint client”, (and different IP addresses used of the same client)
itg-assistant commentedon Jun 12, 2026
Ser Gar answered 2017-08-18 18:13:18 UTC
it would be great if some way to optionally exclude only client ip validation from validatClient to preserve that fingerprint feature partially.