tried at 32bit but there is same stack exception problem and i cant intercept the exception by code
How do you propose to recover from a stack overflow exception?
the first thing is to understand if the problem is just mine or if it exists
second thing is, should the obstacle be circumvented? if so in what way? and then until… until a similar problem arises?
third thing, I don’t deal with the development of the developmnet IDE , I am a banal user of the IDE, who uses an IDE to simplify his life and not to complicate it
Because the exception is occurring in the framework rather than your code?
It’s all been very interesting stress testing the Server socket but it is time to inject a bit of sanity.
Xojo makes it very easy to produce functional network apps but it is not the right tool for producing high performance servers. There is way too much latency in the framework. Whether Xojo is the right tool for you depends on what the client devices are; where the devices are physically located, the volume and throughput of data, the processing that is needed.
The rough tests I carried out suggest it’s not the number of sockets that causes a problem but the rate of new connection requests. Each connection request needs to be responded to individually and the framework simply can not keep up with 1000 connection requests within 100 milliseconds. Before writing Xojo off though you need to ask the question, how fair is the test? The short answer is, the test is not fair and it’s not practical.
There is no operational scenario which involves a single device making a 1000 TCP connection requests as fast as it possibly can, without even checking handshakes are completing. During my tests, checking completion at the client was all it took to prevent the server crashing.
In operation you may well have 500 devices coincidentally attempting to connect at the same time but between those devices and your server application there is a network topology and infrastructure imposing it’s own limits and latencies. The fact you are using Xojo tells me the budget is unlikely to stretch to a mainframe Ethernet switch with 500 ports 
At the moment you risk chasing an issue that may never occur in the real world, and if it does is much easier to solve with a firewall rule than patching applications.
If I were you I would be focussing on producing a solid code pattern that is able to service a modest number of connections totally reliably for long periods. Then start worrying about scaling up if that looks like it might be a problem.
1 Like
Wouldn’t that produce a crash of the IDE? Or does the IDE then try to blame the application 
Either way, it’s not recoverable.
my only concern is that if undetectable errors (even other types) occur and the application crashes, I lose all the buffered data
obvious that at this point I have already studied an alternative to limit the damage and it is a simple Reverse Proxy Server (in this case i will use HAProxy on pfsense ), I spread/distribute the processing horizontally, the fact remains that if the problem exists and is of the framework, xojo will still have to pay attention and if it is not solvable… give us limits beyond which xojo is not recommended…
At the moment, however, I feel like I’m the only stupid person who has this problem and it’s not nice
no the ide intercepts the error as is evident, but the problem is that the code cannot handle this error, if it could be handled (and I believe Xojo will solve the problem) I would already have a way to process the buffer first to close the application
Does your app have an unhandled exception event handler? Perhaps you could catch it there.
i use the App.UnhandledException
but the error that is raised is not intercepted by this event
Congratulation, I think you’ve found 2 bugs!
1 Like
xojo should care your issue and try to reproduce it.
if a client can not connect in time, there would be an timeout, and the client can then try to connect again.
the origin can be in xojo framework, third party librarys, driver, os or other matters.
i made a rule, if you can not find the error in few days, then it is usually not your fault.
1 Like
It cannot be. A StackOverflow occurs when you have already exhausted the memory allocated to the stack. No additional methods can be called (such as UnhandledException). On Windows, the stack size of the main thread is rather modest and cannot be changed. You can change the stack size of a Thread, but that won’t help here because all the tcp/ip communication is running on the main thread.
It does sound like there may be a problem in the Xojo framework with how it handles incoming connections. Hopefully they will take a look. Maybe they can inline some code that would otherwise be a method call.
I hope that xojo tests this problem and if it finds the bug it fixes it,
so in the future we will be less afraid to use this technology
it past 2 mounths and 2 beta release and no ipotetical solution at horizont … 
Case #76141 - uncatchable errors with TCPsocket and problem in the maximum number of listening TCPSockets
is not even Verified yet. Not assigned and not milestone set.
Do not expect a fix soon.
And no “thumbs up”, so other users seems not to have that problem.
If “errors that cannot be handled/crapped” are not a priority issue,
I fear there is a narrow view of the risk to which this issue exposes every programmer who uses xojo.
Honestly, by paying for a license, I would have expected that by reporting a xojo problem to the technical department, xojo would have some more “obligations” compared to the reports made via feedback (and related likes) even from those who do not pay for a license…
otherwise when in the licensing plans they talk about technical support or priority technical support (enterprice licenses)… what are they referring to…
what is technical support if not solving the problems that buyers encounter with the product purchased?
However, everyone sows what they reap and next time with the pipe I renew (pro) for 2 years…
I just tried a simple test of recursion. A method increments a counter and then calls itself. Under macOS, that gives a StackOverflowException at a depth of 67000 or so. I added an UnhandledExceptionHandler in which I print out a message to the System DebugLog, and then Return True.
This all works but I don’t know what state the app or its stack are in at this point.
Edit: FWIW - the app’s default window does not appear.
For what it’s worth, I left the client and server apps running in debug mode on my Mac and they ticked along for about 30 minutes until I stopped them. As noted above, I think the Mac has a larger stack and thus can avoid this sort of issue.
I added a comment to the Feedback ticket for this, but it bears repeating in a more public forum.
Stack overflow errors, by their very nature, can’t be caught and handled by your code. When the stack overflows, it means there is literally no way for the computer to run any more code, which is why your app immediately quits when this happens. Every programming language I can think of has a stack that can overflow, so this isn’t a Xojo-specific problem.
You can think of the stack as a notebook where the computer writes down what it is working on. Every time you interrupt the computer and ask it to do something new, it turns to a new page to work on it, and once it is done, it erases the page and returns to the prior page to continue what it was working on before.
As long as the notebook has a blank page available, this works out just fine, but if you interrupt the computer too many times you will reach the end of the notebook, there’s no way for the computer to keep track of what is going on, and that’s when it stops dead in its tracks and throws a stack overflow exception.
In my experience, stack overflow exceptions stem primarily from two causes:
Application not designed for realistic workload
When the application was designed, the actual workload wasn’t accurately taken into account. The code is being asked to do too many things at a time; the tasks are more complex than anticipated; the data being processed is larger than anticipated; the usage is taking the code down an unexpected path that causes the stack to grow.
Code was not engineered with stack size in mind
This usually means inappropriate usage of recursion (code that calls itself). Every time the code calls itself, a new stack frame is created, and it’s not hard at all to run into stack overflows rather quickly. Recursive code can often be restructured in such a way that it doesn’t endanger the stack like this.
1 Like