4DV11 Server - show stoppers (final)

I am getting private e-mails from 4D forum participants asking for more detail
on V11 bugs.

First of all, please remember that it was not ME, who started the threads on
V11 issues. I recognized the problems that others described and gave my take on
them, that's all. So why I am supposed to be such an authority is a mystery to
me.

Secondly, Dear 4D friends, I cannot/will not enter into private discussions and
start all sorts of arguments with several forum members individually. If you
don't want to participate in the discussions yourself, that's your choice, but
don't ask me to compensate for it.

Thirdly, now that we are talking anyway, I want to emphasize that I am not 'at
war' with 4D. I am merely trying, with the original posters of the V11 Server
problems, to help 4D FOCUS REAL HARD on some last critical issues that prevent
4D V11.4 from being used under full stress.

As a last contribution to the community here, I will publish the bugs that we
filed with 4D since we started to work with V11 exactly one year ago. If you
are interested you can download it here:
http://www.elgineye.com/bugdisplayer.pdf.

The following bugs from the bugdisplayer.pdf are critical and 'show stoppers'
for deployment:

A. ACI0062064 - CLIENT IS CHOKING. The client 'choking', that I reported about
many times, can easily become so bad that objects simple fail to draw on the
screen. I will return half drawn screen dumps for your information.

B. ACI0061854 - SERVER UNRESPONSIVE.

The server can still become unresponsive as reported last year. All clients are
locked. There is nothing wrong with the hardware (sure). The computer can be
reached without problem. The File menu of the 4D Server application will
respond, but do nothing. Trying to Quit the server will not work. We suspect a
problem in the routines that maintain client connections, because once, when
this happened, we decided to slowly shut down the clients one after the other.
The server would become suddenly responsive again after a certain client was
disconnected. Conclusion: ONE client connection falling into a retry/error
routine, can clamp the whole server. There must be a loop without exit there.
If for whatever reason a client connections fails, it should obviously never
lock the whole server. It should only time-out the culprit client.

C. ACI0061850 - QUERY CANNOT BE COMPLETED.

In the same realm as the 'Cannot send data' error (Aci0061845), we can report
that the QUERY CANNOT BE COMPLETED error appears regularly. No pattern. Just
random. No way to isolate or demonstrate.

D. ACI0061851 - CLIENT CRAWLS (SLOWS DOWN TO A TRICKLE).

Despite all the progress, the dreadful phenomenon of 4D client dying over time
is still there. More easily detectable on Windows than on Mac. When the client
just connects, all is fine. Speed is good. Slowly but surely the client will
crawl to a halt. Sometimes (not always) a memory failure message appears. The
computer still has memory available. Users report that they get a maximum 45
minutes out of a client. Then they have to quit and restart 4D. We tried a
zillion things to see if anything influences this behaviour, at no avail.

E. ACI0061845 - CANNOT SEND DATA.

The CANNOT SEND DATA error messages (as reported in 2008) have not disappeared
in Release 4. Cannot send data can appear anywhere in the application. Not
related to a specific method, but related to communications between the server
and the client. No way to isolate this on the user/developer side. Definitely
NOT caused by any hardware or network issue (3 different sites yield the same
results while the same sites run 4D 2003 without hiccups). This is definitely
on 4D's plate, no doubt about it.

This will be my final contribution on the subject.

Hope this may help somebody.

Regards,

Harry.