Hello Everybody,
Tomcat 3.2.2 is crashing on a Unix machine without writing anything in the
log files. Please help me. Is this a problem with the version itself or my
installation.
Thanks,
Chandra
-----Original Message-----
From: Brett M. Bergquist [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 24, 2001 8:09 PM
To: [EMAIL PROTECTED]
Subject: Re: Limits of Web
Exactly. In my case, instead of performing SQL on a database, I perform
SNMP on a network device. The same logic applies, however.
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 24, 2001 3:49 PM
Subject: Re: Limits of Web
>
> Brett,
> Again thanks for the reply. One more question regarding XML. When you
> send the XML request info, do you send the data as well? For example if
> the applet requests data from the server I, would then process it,
preform
> the necessary SQLs on the database and then send the data back to the
> applet as an XML document and have the applet parse it and desplay it?
>
>
>
> "Brett M.
> Bergquist" To:
[EMAIL PROTECTED]
> <brettb@mail. cc:
> com> Subject: Re: Limits of Web
>
> 09/24/01
> 01:46 PM
> Please
> respond to
> tomcat-user
>
>
>
>
>
>
> Okay for the internet. That's what we support as well as intranet. I
> wanted to make sure that my application was easy to deploy in
> an internet environment so I did not what to start using RMI or IIOP or
> something else that would not flow over a firewall, so I
> chose to use XML over HTTP. Basically, our applets create an XML document
> that describes the request data needed and then use an
> HTTP POST to pass this data to the backend servlet. The servlet processes
> the HTTP POST data, transforms it back into a XML DOM
> document. It then analyzes and processes the request. It then creates a
> XML document as the response and passes this back to the
> applet using the HTTP response. We use an early version of Sun's XML
> parser and I also modified the sample XML-RPC client and
> servlet classes for my own use to support this. It works pretty good and
> performance of creating and parsing the XML is a
> non-issue; the major processing time is taken by actually performing the
> requested service. If I had to do it over, I would
> definitely look at using the quasi standard XML-RPC protocol or maybe even
> SOAP, but I have a feeling that these are getting to
> esoteric for my taste. One other benefit of this approach was that the
> front end is loosely coupled from the backend. I could
> change the front end side, maybe having a native application or something
> similar, and the backend would be blissfully unaware. The
> XML is the binding protocol between the two.
>
> Our applications currently have about 5 to 7 tab pages with about 10 to 15
> items per page. From the time the applet starts on the
> browser to the time that it displays the data is about 1 to 2 seconds.
> This is using just Tomcat as our web server and java servlet
> engine. We started to front the backend with Apache, but the connection
> between Apache and Tomcat was flaky and we seem to get good
> enough response time with just Tomcat. It also simplifies the
> configuration quite a bit.
>
> We do one other thing that's a little interesting. We needed to send
> asynchronous updates to an alarm application. As you know, a
> web based application is primarily request/response driven. Again, I did
> not want a big configuration issue in dealing with opening
> ports on the firewall, etc. so what I did was fake out the system by
> issuing a HTTP request and I have the response never end. That
> is, the servlet side generates alarm information whenever it needs and
> sends it down the response pipe back to the client. Now this
> tacks up a TCP connection from the server to the client so it puts a
little
> stress on the server resources, but with the number of
> clients we were looking to support this was acceptable.
>
> As for the jar package, we use a tool called "cannery". You give it a
> starting Java class file and it will find an package any
> other classes that the starting class file depends on into a jar file.
> This optimizes the jar file for the applet to be as small as
> it can be. It's pretty good but it may miss classes that are needed
> through runtime reflection, in which case, you simply have to
> tell "cannery" to include those class files manually.
>
> Just another thought. I worked on a previous system that tried to do some
> other client side processing such as having a client side
> hidden component that would open up a port and listen for updates, etc.
> This involved getting into code signing using a certificate
> such as from Verisign. Each browser does this differently with different
> code signing requirements. This was a nightmare and I
> don't think you want to go there.
>
> With the solution that I came up with, the client has a one-time download
> of the Java Plugin to install into their browser. This is
> not to small, about 5Mb, but not to large either. Similar to the Flash
> plugin. We also host the Java Plugin on our own web site so
> that the client can get it from our company as apposed to Sun's web site.
> Sun has a habit of changing and removing links to the
> Java Plugin when new versions come out. We needed something a little more
> stable.
>
> Hope this helps.
>
> Brett
>
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, September 24, 2001 2:16 PM
> Subject: Re: Limits of Web
>
>
> >
> > Brett,
> > Thanks for your detailed reply. The application will be deployed in an
> > internet environment. A few more questions. Some of our applets will
> have
> > 12 - 15 tab pages each w/its own set of data. Is it feasible to get an
> > quick enough response with this type of gui? Also, what packing tool
did
> > you use to produce the Jar files? And, if can in a sentence or to,
> explain
> > how you used XML for communication between the applets and the backend?
> >
> > Thanks again
> >
> > Jeff
> >
> >
> >
> > "Brett M.
> > Bergquist" To:
> [EMAIL PROTECTED]
> > <brettb@mail. cc:
> > com> Subject: Re: Limits of Web
> >
> > 09/24/01
> > 12:45 PM
> > Please
> > respond to
> > tomcat-user
> >
> >
> >
> >
> >
> >
> > Jeff, will your application be deployed in an intranet or internet
> > environment? This might make a difference in the solutions that
> > are available. Just for your information, I faced as similar situation
> in
> > the development of a Network Management System used to
> > control and manage fiber optic communications equipment that we
> > manufacture.
> >
> > I needed a robust and complex gui with things such as greying out
fields
> > depending on the selections of other fields, validation on
> > fields as they are entered, indicating to a user a field has been
> changed,
> > etc. These needed to be done on the client side. I
> > looked at a few possibilities, namely JavaScript or Java applets. At
the
> > time Sun's Jump Start was not available. I chose to use
> > Swing based Java applets. To get around the differences in browsers, I
> > chose to use the Java Plugin to provide this stable (fairly)
> > environment. In addition, in the back end we are using Tomcat with
> > servlets, JSP pages, and XML as the communications between our
> > Java applets and the backend. I chose Java over JavaScript because of
> the
> > complexities involved in managing browser specific within
> > JavaScript and also because of the better development and debugging
> > environment I had in Java.
> >
> > Using a packaging tool that produces Jar files with the absolute minimum
> > need for the applet, we are able to keep out applet size
> > down to between 250k and 350k. Once downloaded the applets are cached,
> so
> > this is pretty much a one time hit. Our applications are
> > quite responsive and have the gui needed.
> >
> > Just to let you know what we did.
> >
> >
> >
> > ----- Original Message -----
> > From: <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, September 24, 2001 12:54 PM
> > Subject: Re: Limits of Web
> >
> >
> > >
> > > I asked for help w/technical issues not advice on how to manage
> clients.
> > > Please limit the answers to such. Nobody's trying to get sympathy or
> > pity;
> > > just trying to do our jobs.
> > >
> > >
> > >
> > > Pae Choi
> > > <paechoi@eart To:
> > [EMAIL PROTECTED]
> > > hlink.net> cc:
> > > Subject: Re: Limits of
Web
> > > 09/24/01
> > > 11:12 AM
> > > Please
> > > respond to
> > > tomcat-user
> > >
> > >
> > >
> > >
> > >
> > >
> > > Then, they need to get help by getting professionals.
> > >
> > > One would be the architect who can help you folks at least
> > > understand what is the difference between the thin and thick
> > > clients.
> > >
> > > Second would be the security speciality who can help you
> > > folks understand that the security is not a joke like anyone
> > > suddenly realized and think they can grab and use it like
> > > a plugable COTS.
> > >
> > > I've seen many folks use the terms like "client", "customer",
> > > "boss", etc just to win the battle and get some sympathy or pity.
> > > You need to know how to manage the customer expectaton
> > > as well as teach your stakeholders learn that they will not
> > > get over night whatever they want and demand just because
> > > they think they can piss around you.
> > >
> > >
> > > Pae
> > >
> > > >
> > > > When we started with this app it we did not have the skills needed
to
> > > > develop Swing applets. Now the problem appears to be the speed of
> > these
> > > > applets. They are way to slow. They also expect it to be as fast
as
> > > their
> > > > Client Server Applications. Plus the company I work for is paranoid
> > > about
> > > > security to the point of irrationality. If they ever got wind of
the
> > > > security problems involved in applets they would shut development
> down.
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
