[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pnet-developers] DGEE is working --> problems

From: Gopal V
Subject: Re: [Pnet-developers] DGEE is working --> problems
Date: Thu, 26 Jun 2003 00:49:56 +0530
User-agent: Mutt/1.2.5i

If memory serves me right, Roberto Morales wrote:
> i work with Mono:: framework and C#, ADO, ASP, XSP server,  
> mod_mono and apache too, my team (15 programers) test and  
> reports many runtime errors, because we have a big project  
> but is other history 

Our entire effort on consists of a very small 
team in comparison .. (but it's not how many , but how much
the team can do , so .. that's also inconsequential)

We're very different from mod_mono in a few ways , for one 
our VM does not run inside Apache's memory space (ie as a 
forked child) which adds a bit of security . We run the VM
under DGEE and use it as a middleware server , which means
we can have more number of children than Apache (or in the
near future run a cluster of DGEEs for an Apache or vice versa).
Mod_DGEE only funnels the request into the middleware and
IIRC does no processing . 

DGEE is a multil-layer setup with protocol frontend (ie 
HTTP/Apache/mod_dgee) , the middleware (goldwater) and the
client VM (pnet/PnetVM) . This makes it extremely stable
and fast responding with buffering , queuing and modular

DGEE is not tied down to a particular VM or language , ie 
there is a PnetVM which is run ~4-5 (or more) instances to
serve the requests. You could develop a new VM by starting
from the the DGNullVm and merging in your VM.

The general concept of DGEE is Webservices and not ASP.NET,
which means that it is entirely using something comparable
to CodeBehind and writing all our WS code in C# (or any IL 
compatible compiler). So it's not intended to generate HTML,
though I'm sure that's perfectly possible.

Soon or perhaps by the next release of Pnet 0.6.0 , we'll be
able to run XSP in and probably we'll find some
way to remain compatible with existing ASP code. We're actually
missing fairly trivial peices of code like machine.config loading
in Pnetlib currently. I was working on getting System.Web and 
have currently a working System.Web.dll with me . But more recently 
the Portable WinForms has consumed most of my time .

> i need a little help, i find a howto, mini-howto of DGEE or 
> somebody to help me, please 

Ok, I'm not a core DGEE devel (the DGEE is a seperate project from , but I do have installed DGEE :-)

> # dgeediagnose 
>   all OK 

DGEE diagnose checks for basic stuff needed for DGEE to run ie the
IPC glue and the message queues , buffers etc... It does not test
DGEE completely.

> I try to run dgee I report the mean error 
> # dgeestart 
>  goldwater:  errorr while loading shared libraariews: 
> cannot open shared object file: no such file or directory. 
>  goldwater:  errorr while loading shared libraariews: 
> cannot open shared object file: no such file or directory. 

Ok, you might need "libtermcap-devel" for running DGEE .. and 
I use my DGEE from CVS as the CVS version is very stable and 
of course I do tweak DGEE source code. I suppose you got it from 
the debian packages ?..

The QUICKSTART in DGEE CVS will help you if you wanted to build 
DGEE from source. And I should tell you, it's worth the effort if you 
build it in situ to match the Apache version for the

Last but not least check XMLRPC calls of your clients against

which is a simple webservice (opening that up in a browser shows up
the webservice documentation). DGEE CVS should have the source code
for that which is essentially..

int Multiply(int a,int b)
   return a*b;

I'm sure that a WSDL compiler is just a few steps away from the csdgmx
but unfortunately (or fortunately !!) DGEE team is working on a remote 
admin tool. This is how it should look when it's all done .. ie if csmith 
has not taken it off (

Hope all that helps,

The difference between insanity and genius is measured by success

reply via email to

[Prev in Thread] Current Thread [Next in Thread]