4DV11 Server - show stoppers (final)

[Harry A. Bernstein M.D. ()]

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.

[Matt Houghton-Thompson]

On Tue, Jun 30, 2009 at 4:36 PM, Harry A. Bernstein
M.D.<hbmd2@...> wrote:

> B. ACI0061854 - SERVER UNRESPONSIVE.

> 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.

We have found v11 to be very sensitive to "rogue" clients.  On day 1,
we had this problem when a few 2004 clients would try to connect.  We
think a corrupt "Caches" folder may cause it too.  Most recently we
had an issue where a couple of clients on a unreliable wireless
connection were causing the same problem.  We ran wires to these
computers and the problem went away.

>
> C. ACI0061850 - QUERY CANNOT BE COMPLETED.
E. ACI0061845 - CANNOT SEND DATA.
I have seen these on our dev server with a very small cache (100-200MB)

>
> 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.

I have only seen this on a G5 (not any PowerPC, just G5s), but we do
not have any windows clients.  Have you ever seen it on an intel Mac?

> Since these issues primarily show up when an app is in real production, I
> suggest that
> all non-production forum members refrain from comment.

I'm not sure I'd go that far, but I hope those non-production members
have tested their applications under load and under load for several
hours as some of the issues being reported on the list can take hours
before showing up.
-Matt H-T.
Sweetwater Sound
**********************************************************************
Register for 4D Summit 2009 Today
Early Bird Pricing Ends August 28th - http://www.4d.com/summit

4D Internet Users Group (4D iNUG)
FAQ:  http://www.4D.com/support/faqnug.html
Archive:  http://lists.4D.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4D_Tech-Unsubscribe@...
**********************************************************************