|
| Perl for Netware - stability (or lack there of) |
 |
Tue, 07 Mar 2006 10:19:18 GMT |
I thought I would share some experiences with Perl for NetWare.
I have been working on a project with Perl for NetWare were we are
coding a medium sized application.
And I must say, that Perl for NetWare is not the best Perl
implementation I have come across.
First of all, there are several functions that just is'nt there (i.e.
flock() and syscall()) and functionality has been taken out (i.e.
IPC).
And worst of all, it destabilizes the server. Especially when you are
in a development environment, and frequently write debug information
to standard output, and load and reload Perl programs.
Time and again it will abend with issues regarding console screen
output (i.e. "Console Command Process" and "Blocked on
keyboard") or
just "Perl Main Thread".
One example, is that we have a permanent ban on writing "CLS" on the
server screens - if the server has been running for more than a day
with temporary output to the console screen, it will just do a
spontaneous abend. And that holds true for SP5 also.
And Unicode support is dodgy at best.
While locked on the NetWare platform for a while, we look forward to
moving to Linux.
So if you are looking towards Perl to do more than just contacting a
Management System, watch some files with a specific owner, report on
server status and do some household actions, then you really should
consider Java or C. Perl just won't cut it with larger projects.
(Please note that this is just my personal oppinion...)
|
| Post Reply
|
| Re: Perl for Netware - stability (or lack there of) |
 |
Wed, 08 Mar 2006 16:59:41 GMT |
Hi Allan,
I posted your message to the Perl and OS developers, and both are more than
willing to 'stabilize' Perl and/or related OS functions -- but for that we
really need your help!
Can you perhaps post simple script samples which can demonstrate these
issues? That would help a lot, and gives the developers starting points for
debugging. Also please try to make _one_ script per issue, not all-in-one.
also please post on what exact versions of Perl / LibC / OS you see these
issues.
greets, Guenter.
Allan Brehm Clausen <abc_remspam_@itq_remspam_.dk> wrote in
news:a6lq02pb97030l8ijcq67kkpc5h742rcpn@4ax.com:
> I thought I would share some experiences with Perl for NetWare.
>
> I have been working on a project with Perl for NetWare were we are
> coding a medium sized application.
> And I must say, that Perl for NetWare is not the best Perl
> implementation I have come across.
>
> First of all, there are several functions that just is'nt there (i.e.
> flock() and syscall()) and functionality has been taken out (i.e.
> IPC).
> And worst of all, it destabilizes the server. Especially when you are
> in a development environment, and frequently write debug information
> to standard output, and load and reload Perl programs.
> Time and again it will abend with issues regarding console screen
> output (i.e. "Console Command Process" and "Blocked on
keyboard") or
> just "Perl Main Thread".
> One example, is that we have a permanent ban on writing "CLS" on
the
> server screens - if the server has been running for more than a day
> with temporary output to the console screen, it will just do a
> spontaneous abend. And that holds true for SP5 also.
> And Unicode support is dodgy at best.
>
> While locked on the NetWare platform for a while, we look forward to
> moving to Linux.
>
> So if you are looking towards Perl to do more than just contacting a
> Management System, watch some files with a specific owner, report on
> server status and do some household actions, then you really should
> consider Java or C. Perl just won't cut it with larger projects.
>
> (Please note that this is just my personal oppinion...)
>
>
|
| Post Reply
|
| Re: Perl for Netware - stability (or lack there of) |
 |
Wed, 08 Mar 2006 17:33:23 GMT |
Allan Brehm Clausen wrote:
> I thought I would share some experiences with Perl for NetWare.
> I have been working on a project with Perl for NetWare were we are
> coding a medium sized application.
> And I must say, that Perl for NetWare is not the best Perl
> implementation I have come across.
> First of all, there are several functions that just is'nt there (i.e.
> flock() and syscall()) and functionality has been taken out (i.e.
> IPC).
> And worst of all, it destabilizes the server. Especially when you are
> in a development environment, and frequently write debug information
> to standard output, and load and reload Perl programs.
> Time and again it will abend with issues regarding console screen
> output (i.e. "Console Command Process" and "Blocked on
keyboard") or
> just "Perl Main Thread".
> One example, is that we have a permanent ban on writing "CLS" on
the
> server screens - if the server has been running for more than a day
> with temporary output to the console screen, it will just do a
> spontaneous abend. And that holds true for SP5 also.
> And Unicode support is dodgy at best.
I've had similar problems, nearly all of which were solved by using
ModPerl instead (some code will probably need to be improved to work
properly in a persistent environment though). It seems that ModPerl is
very stable, extremely fast (because it executes a compiled version of
your Perl scripts instead of simply interpreting them), light on CPU
utilization, etc.
My big complaint about ModPerl is all the difficulties I'm having with
sockets not working, thus I can't use DBD::PgPP. Novell is apparently
looking into this right now, and I eagerly look forward to an update
sooner than later.
> While locked on the NetWare platform for a while, we look forward to
> moving to Linux.
I'm more inclined to go for FreeBSD or OpenBSD myself, since these
Operating Systems seem to have a very good reputation for not buckling
under very heavy loads.
> So if you are looking towards Perl to do more than just contacting a
> Management System, watch some files with a specific owner, report on
> server status and do some household actions, then you really should
> consider Java or C. Perl just won't cut it with larger projects.
>
> (Please note that this is just my personal oppinion...)
Actually, Perl is excellent for larger projects, especially when you use
ModPerl and DBI -- the DBI module will cache connections, SQL statements,
as well as taking care of quoting for you automatically (if you prepare
your statements correctly), and with database-driven projects I find that
Perl generally out-performs Java and C/C++/Assembler (both of which
perform very well also).
I'm very keen to see improvements in ModPerl on NetWare, as I'm almost
ready to promote a database-driven project to production that currently
uses DBD::PgPP (this is acceptable for the short-term, but eventually I'll
need to switch to using just DBD::Pg).
Although it's fantastic that MySQL is available, it simply isn't an option
for me because it fails my reliabily tests (e.g., INSERTs don't return
"OUT OF RANGE" errors when values are too high -- the values simply
get
truncated, and to me that is totally unacceptable; I also don't like the
idea of being able to mix transactioned and non-transactioned tables in a
single query since this obviously defeats the whole purpose of having a
transactional DBMS; etc.).
(Those are just my personal opinions too.)
--
Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.inter-corporate.com/
This message originated from within a secure, reliable,
high-performance network ... a Novell NetWare network.
|
| Post Reply
|
| Re: Perl for Netware - stability (or lack there of) |
 |
Wed, 15 Mar 2006 09:19:24 GMT |
To start off with, try and run this script on the server:
use time::local;
use strict;
use fcntl;
my $counter = time() + 60;
do
{
print "PickTheSafe is writing to the screen.\n";
print "Writing more than one consecutive line to the screen - making
shure it wraps to the next one...\n";
print "\nTest\n";
print ".\n";
}while(time() < $counter);
go back to the system console within 60 seconds. Then type CLS.
The server will instantly hang.
Mostly the abend says something regarding Console Commands:
Abend 1 on P00: Server-5.70.05: Page Fault Processor Exception (Error
code 00000002)
Registers:
CS = 0060 DS = 007B ES = 007B FS = 007B GS = 007B SS = 0068
EAX = 00000000 EBX = 00000000 ECX = 0000ACA0 EDX = 0043565C
ESI = 0043565C EDI = 8CBA7000 EBP = C0378EC2 ESP = C0378474
EIP = 002D395E FLAGS = 00010246
002D395E F3AA REP STOSB
EIP in SERVER.NLM at code start +000D295Eh
Access Location: 0x8CBA7000
The violation occurred while processing the following instruction:
002D395E F3AA REP STOSB
002D3960 A1085F4300 MOV EAX,
[SERVER.NLM|SCROLLABLE_SCREEN_BUFFER_SIZE]
=0003C000
002D3965 31DB XOR EBX, EBX
002D3967 85C0 TEST EAX, EAX
002D3969 7622 JBE 002D398D
002D396B 8B869C020000 MOV EAX, [ESI+0000029C]
002D3971 C6040320 MOV [EBX+EAX], 20
002D3975 83C302 ADD EBX, 00000002
002D3978 8B869C020000 MOV EAX, [ESI+0000029C]
002D397E 8B15085F4300 MOV EDX,
[SERVER.NLM|SCROLLABLE_SCREEN_BUFFER_SIZE]
=0003C000
Running process: Console Command Process
Thread Owned by NLM: SERVER.NLM
Stack pointer: C0378E90
OS Stack limit: C0371000
Scheduling priority: 67371008
Wait state: 5050170 Blocked on keyboard
Stack: -005140FC (SERVER.NLM|scsCommandBuffer+0)
--FE0CB240 ?
-005140FC (SERVER.NLM|scsCommandBuffer+0)
--C0378EC2 ?
-005140FF (SERVER.NLM|scsCommandBuffer+3)
0027D555 (SERVER.NLM|ClearScreenHandler+11)
-0043565C (SERVER.NLM|systemConsoleScreenStructure+0)
00276D2C (SERVER.NLM|NWParseCommandEx+69C)
--00000002 (LOADER.NLM|KernelAddressSpace+2)
-0043565C (SERVER.NLM|systemConsoleScreenStructure+0)
-005140FF (SERVER.NLM|scsCommandBuffer+3)
Other times it gives this one:
Running process: Interrupt service routine (nested count 2)
Interrupted process: PERL.NLM's main thread Process
Thread Owned by NLM: PERL.NLM
Stack pointer: 8E33B4E0
OS Stack limit: 8E2BBF60
Scheduling priority: 67371008
Wait state: 3030070 Yielded CPU
Stack: 00201411 (SERVER.NLM|PerformCallOuts+105)
--00000000 (LOADER.NLM|KernelAddressSpace+0)
--00000995 (LOADER.NLM|KernelAddressSpace+995)
001137AB (LOADER.NLM|kspinlock_patch+4)
The hardware detected a problem while executing an interrupt service
routine.
Perl:
PERL.NLM
Loaded from [SYS:SYSTEM\] on 15 Mar 2006 10.14.38
(Address Space = OS)
Perl 5.8.4 - Command Line Interface
Version 5.00.05 13 September 2005
Copyright (C) 2000-01, 2004-05 Novell, Inc. All Rights Reserved.
Libc:
LIBC.NLM
Loaded from [C:\NWSERVER\] on Mar 15, 2006 10:02:20 am
(Address Space = OS)
Standard C Runtime Library for NLMs [optimized, 7]
Version 9.00.03 15 December 2005
Copyright (c) 1999-2006 by Novell, Inc. All rights reserved.
OS:
Novell Open Enterprise Server, NetWare 6.5 Support Pack Revision 05
(C) Copyright 1983-2005 Novell Inc. All Rights Reserved. Patent
Pending.
Server Version 5.70.05 December 16, 2005 Novell eDirectory Version
8.7.3.7 SMP NDS Version 10552.79 9 August 2005
Regards
Allan Brehm Clausen
On Wed, 08 Mar 2006 16:59:41 GMT, Guenter <devforums@novell.com>
wrote:
>Hi Allan,
>I posted your message to the Perl and OS developers, and both are more than
>willing to 'stabilize' Perl and/or related OS functions -- but for that we
>really need your help!
>Can you perhaps post simple script samples which can demonstrate these
>issues? That would help a lot, and gives the developers starting points for
>debugging. Also please try to make _one_ script per issue, not all-in-one.
>
>also please post on what exact versions of Perl / LibC / OS you see these
>issues.
>
>greets, Guenter.
>
>Allan Brehm Clausen <abc_remspam_@itq_remspam_.dk> wrote in
>news:a6lq02pb97030l8ijcq67kkpc5h742rcpn@4ax.com:
>
>> I thought I would share some experiences with Perl for NetWare.
>>
>> I have been working on a project with Perl for NetWare were we are
>> coding a medium sized application.
>> And I must say, that Perl for NetWare is not the best Perl
>> implementation I have come across.
>>
>> First of all, there are several functions that just is'nt there (i.e.
>> flock() and syscall()) and functionality has been taken out (i.e.
>> IPC).
>> And worst of all, it destabilizes the server. Especially when you are
>> in a development environment, and frequently write debug information
>> to standard output, and load and reload Perl programs.
>> Time and again it will abend with issues regarding console screen
>> output (i.e. "Console Command Process" and "Blocked on
keyboard") or
>> just "Perl Main Thread".
>> One example, is that we have a permanent ban on writing "CLS"
on the
>> server screens - if the server has been running for more than a day
>> with temporary output to the console screen, it will just do a
>> spontaneous abend. And that holds true for SP5 also.
>> And Unicode support is dodgy at best.
>>
>> While locked on the NetWare platform for a while, we look forward to
>> moving to Linux.
>>
>> So if you are looking towards Perl to do more than just contacting a
>> Management System, watch some files with a specific owner, report on
>> server status and do some household actions, then you really should
>> consider Java or C. Perl just won't cut it with larger projects.
>>
>> (Please note that this is just my personal oppinion...)
>>
|
| Post Reply
|
| Re: Perl for Netware - stability (or lack there of) |
 |
Wed, 15 Mar 2006 09:28:57 GMT |
On Wed, 08 Mar 2006 17:33:23 GMT, randolf@inter-corporate.com (Randolf
Richardson) wrote:
>I've had similar problems, nearly all of which were solved by using
>ModPerl instead (some code will probably need to be improved to work
>properly in a persistent environment though). It seems that ModPerl is
>very stable, extremely fast (because it executes a compiled version of
>your Perl scripts instead of simply interpreting them), light on CPU
>utilization, etc.
Thans for the tip, I will look into that.
>My big complaint about ModPerl is all the difficulties I'm having with
>sockets not working, thus I can't use DBD::PgPP. Novell is apparently
>looking into this right now, and I eagerly look forward to an update
>sooner than later.
Could you post here when/if a solution is found, please?
>> While locked on the NetWare platform for a while, we look forward to
>> moving to Linux.
>I'm more inclined to go for FreeBSD or OpenBSD myself, since these
>Operating Systems seem to have a very good reputation for not buckling
>under very heavy loads.
But I am tied in to the NSS file system through VFS, so unless there
is a successful port of NSS to FreeBSD (:-), I will have to go with
OES.
>Although it's fantastic that MySQL is available, it simply isn't an option
>for me because it fails my reliabily tests (e.g., INSERTs don't return
>"OUT OF RANGE" errors when values are too high -- the values
simply get
>truncated, and to me that is totally unacceptable; I also don't like the
>idea of being able to mix transactioned and non-transactioned tables in a
>single query since this obviously defeats the whole purpose of having a
>transactional DBMS; etc.).
We are also very pleased with the DBI module, as it seems to perform
without a hitch. Although we don't need the same kind of robustness on
the database, so MySQL suit our needs quite well.
Thanks for the elaborate comment.
Regards
Allan Brehm Clausen
|
| Post Reply
|
|
|