Plugin: Jetty Web Server 2.0 - Page 3

ranger · #41 06-02-2010, 05:08 PM

Thanks for adding the apps page.
Running the latest version and have 3 options on the "apps" page, bmt, sage, and sagex. BMT and sage work fine, but "sagex" produces the error below. I am not really sure what should be there, so it may be something I don't have fully installed / configured.

Code:

HTTP ERROR 404

Problem accessing /sagex/. Reason:

    No Sage Handler Specified.
Powered by Jetty://

lotusvball · #42 06-02-2010, 06:13 PM

Quote:

Originally Posted by jreichen

Did you do this?

Nope.....

jreichen · #43 06-03-2010, 07:49 AM

Quote:

Originally Posted by ranger

Thanks for adding the apps page.
Running the latest version and have 3 options on the "apps" page, bmt, sage, and sagex. BMT and sage work fine, but "sagex" produces the error below. I am not really sure what should be there, so it may be something I don't have fully installed / configured.

Code:

HTTP ERROR 404

Problem accessing /sagex/. Reason:

    No Sage Handler Specified.
Powered by Jetty://

That's what sagex returns if nothing more than the context path is specified in the url. Sagex is not really meant to be an end user app but I think it will return a help page if you add /api to the end of the URL.

The "apps" page doesn't know anything specific about webapps. Each app needs to be updated to tell it what page to go to. For example, the web ui needs to go to /sage/Home, not just /sage. I hope to get to that soon. I notified other developers of this requirement in the first post of this thread so other plugins should be adopting this as well.

jreichen · #44 06-03-2010, 07:52 AM

Quote:

Originally Posted by lotusvball

Nope.....

Try deleting the directories from /jetty/webapps while Sage is shut down. It should only need to be done once. After that Jetty 2.0.1 will be able to clean them up on its own.

lotusvball · #45 06-03-2010, 08:43 AM

Quote:

Originally Posted by jreichen

Try deleting the directories from /jetty/webapps while Sage is shut down. It should only need to be done once. After that Jetty 2.0.1 will be able to clean them up on its own.

Thanks, it worked. I had to wait a few minutes while it recreated the directories, but all is well now.

peternm22 · #46 06-07-2010, 07:26 PM

I was wondering if there was a way to have: http://<server>:<port> redirect to a certain Jetty app instead of a 404 page? So instead of typing http://<server>:<port>/sage/ , I could just type http://<server>:<port> and it would forward me to http://<server>:<port>/sage/.

The web interface is my most used Jetty app, so it would be handy to be automatically redirected there.

Thanks.

robogeek · #47 06-07-2010, 09:45 PM

Quote:

Originally Posted by peternm22

I was wondering if there was a way to have: http://<server>:<port> redirect to a certain Jetty app instead of a 404 page? So instead of typing http://<server>:<port>/sage/ , I could just type http://<server>:<port> and it would forward me to http://<server>:<port>/sage/.

The web interface is my most used Jetty app, so it would be handy to be automatically redirected there.

Thanks.

I think if you create an index.html with the following code:

Code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>SageTV</title>
<meta http-equiv="REFRESH" content="0;url=http://<server>:<port>/sage/"></HEAD>
<BODY>
</BODY>
</HTML>

then replace <server>:<port> with your server web address and port number, and then drop the index.html file into the jetty\static directory, that should redirect to the SageTV web server page.

peternm22 · #48 06-07-2010, 09:54 PM

Thanks, I had no idea about the "static" directory option. I managed to fashion my own cumbersome solution though, I copied a web app and context file from another app. Then I put an index.html file in it with the refresh, and set the path to "/".... it works.

Your way is much much simpler though, and I've switched to it

Thanks.

kmp14 · #49 06-09-2010, 01:13 PM

Help. I am stuck. I upgraded to the latest Sage 7. Jetty and the Sage Web UI still continued to work fine. I decided to then upgrade the Jetty to the latest via the Plugins feature in S7. It installed fine, and I am able to configure it on screen, but I cannot get to the site. I don't get a jetty error in the browser, instead, it looks like the site is not up at all.

I am not sure where to look to see if it is even really running. I do see a agex-api.log with the Warning that "NO Context Was Found".

Any tips to help me get the troubleshooting started would be appreciated!

jreichen · #50 06-09-2010, 10:55 PM

Are you able to go to http://<server>:<port>/apps?

Try turning on Sage's debug logging (in detailed setup) and increase Jetty's log level to VERBOSE (in the Jetty plugin config screen) and see if anything looks wrong. Post it here it you'd like me to review it.

Also you may have duplicate jar files if you weren't on Jetty 1.6 before installing 2.0 through the plugin manager. Please post a list of the files in your JARs folder.

tmiranda · #51 06-11-2010, 05:34 AM

John,

I'm working on a servlet that spawns a thread. I want to make sure the thread is stopped when the Servlet instance ends.

From the experiements I've done I think the servlet is instantized the first time it is needed (please correct me if I'm wrong) but I can't quite figure out when the instance ends. What are the guidelines for that? Does the instance live util Sage or Jetty stops or can the instance end before then? And more importantly, how can I catch the fact that the instance is ending so I can tell the spawned thread to stop?

Thanks,

Tom

jreichen · #52 06-11-2010, 10:16 PM

There's a lot to cover so I'll try to keep this from getting too long and give you some pointers you can research.

Normal Java objects have no reliable way of knowing when they're being cleaned up. However, objects that implement the Servlet interface are a bit different. The Servlet interface has a destroy() method that is called by the Java web server when a servlet's lifecycle is ending. There's also an init() method for when it's being initialized. I'd recommend reading about servlet lifecycles.

The servlet can be loaded either when the server starts or the first time it needs to handle a request. Check out the <load-at-startup> setting in web.xml.

AFAIK, in Jetty the servlet will be destroyed either when:

The web application is stopped, uninstalled (context file is removed) or restarted (context file timestamp is updated).
Jetty is shut down (which stops the web app)
Sage is shut down (also stops the web app)

Be careful when stopping a thread, don't use the Thread object's stop() method as that's known to cause problems and has been deprecated. Basically you want to let the run() method exit normally in order to let the thread die. This is another area I'd suggest reading up on as I'm a little rusty on it. If you have further questions I'll try to answer them.

Use caution with threading in servlets. One instance of a servlet services all requests. Each request runs on a new thread (or a reused thread in a pool) so the use of instance variables is generally discouraged but can be used if locking or synchronization is used correctly.

Jason

tmiranda · #53 06-12-2010, 04:01 AM

Jason,

I understood it all up to this point:

Quote:

Originally Posted by jreichen

One instance of a servlet services all requests. Each request runs on a new thread (or a reused thread in a pool) so the use of instance variables is generally discouraged but can be used if locking or synchronization is used correctly

Isn't an instance and a thread essentially the same thing: one instance = one thread?

You warn about threading in a servlet, how else do you get things done that take a long time (several minutes)? I did not see any other way other than to start a thread to handle the work so the servlet could go on it's way and handle the next request. if I do not start a thread the servlet would be unavailable for a long time.

Why are instance variables discouraged, I thought that would be a preferred way of doing things? Should I make all of the variables that I want to keep track of over the life of the servlet static?

I'm missing a key piece here for sure.

PS. Sorry for calling you John, I was thinking JRKiwi

jreichen · #54 06-12-2010, 09:21 AM

Quote:

Originally Posted by tmiranda

Isn't an instance and a thread essentially the same thing: one instance = one thread?

They aren't the same. Java methods are reentrant, meaning more than one thread can execute in them at one time. Method parameters and variables that are defined in a method are both on the stack so they're not shared by multiple threads. Instance variables belong to the object so multiple threads may access them at the same time. Static variables belong to the class and can also be accessed by multiple threads at the same time. For example:

Code:

public class MyExample
{
    // this is available to any thread executing in
    // one of this object's methods
    private Object obj;

    // each thread executing within this method has
    // its own copy of s and methodObj
    public void myMethod(String s)
    {
        Object methodObj;
        // method logic...
    }
}

Quote:

Originally Posted by tmiranda

You warn about threading in a servlet, how else do you get things done that take a long time (several minutes)? I did not see any other way other than to start a thread to handle the work so the servlet could go on it's way and handle the next request. if I do not start a thread the servlet would be unavailable for a long time.

Since multiple threads can execute in a method concurrently, one request will not block another - unless the server is using a thread pool and all threads are busy servicing client requests. For Sage webapps I don't worry about large numbers of simultaneous requests since that's not likely to happen. There might be a few at a time but not hundreds or thousands like large websites would have.

Quote:

Originally Posted by tmiranda

Why are instance variables discouraged, I thought that would be a preferred way of doing things? Should I make all of the variables that I want to keep track of over the life of the servlet static?

It can be done if necessary but it's generally advised to avoid it if possible because multiple threads can access them at once and ensuring thread safety can be difficult. If possible use variables declared in the method rather than instance or static variables. If you need to save something across requests then you'll need to use some form of object sharing along with Java's synchronization or lock mechanisms to ensure thread safety. See the Java EE Tutorial for more info about sharing data.

As I'm sure you've noticed, threading can become quite a complex topic. I would start by writing your logic without creating your own threads. Let the web server do the hard work for you.

tmiranda · #55 06-12-2010, 09:34 AM

OK, lots of things to think about.

You say to let the web server do the hard work and not mess with threads. I must be missing the big picture somewhere because the way I understand it in a servlet you HAVE to start a thread to do work that will take a long time because the servlet can only process one request at a time.

If the servlet is busy downloading a file for several minutes it will be unavailable to take new requests until the file download is completed. This is just does not seem right, what am I missing?

Slugger · #56 06-12-2010, 01:52 PM

Quote:

Originally Posted by tmiranda

If the servlet is busy downloading a file for several minutes it will be unavailable to take new requests until the file download is completed. This is just does not seem right, what am I missing?

A servlet instance does not handle the incoming connections itself, instead there's usually a pool of socket listeners (or equivalents). These are the things that handle connections. Each incoming connection to Jetty that is destined for your servlet simply uses the single instance of your servlet object to process the request. This is why your servlet methods (doPost(), doGet(), etc.) all accept an HttpServletRequest and an HttpServletResponse as args - that's the encapsulation of the network "stuff" that's going on. And that's why your servlet instance can be accessed by multiple threads simultaneously. And it's also why if your servlet has instance or static vars then they must be synchronized.

The fact that a request is in your servlet will not block other requests from accessing your servlet - unless you synchronize - which is why it's very undesirable to synchronize in your servlet - it will kill the liveliness/concurrency of your web apps. With that said, in an environment like Jetty for SageTV, synchronization, though not desirable, probably isn't a big deal should your design call for it (because the max request load/max concurrent request load is so tiny - for most use cases).

tmiranda · #57 06-12-2010, 02:44 PM

OK, I was under the impression that there was NEVER more than one instance of the servlet. So I CAN have one instance of the servlet busy downloading a file and jetty will create another instance to handle any new request that come in while the file is downloading.

That actually makes my life a lot easier

Thank you Slugger and Jason.

GKusnick · #58 06-12-2010, 02:59 PM

Quote:

Originally Posted by tmiranda

OK, I was under the impression that there was NEVER more than one instance of the servlet. So I CAN have one instance of the servlet busy downloading a file and jetty will create another instance to handle any new request that come in while the file is downloading.

No, that's not what they're saying. Your servlet class will be instantiated just once. But that one instance can receive ansynchronous method calls from multiple threads to handle multiple asynchronous requests. The Request and Response objects will exist in multiple instances, but your servlet object will not.

That does not mean you need to create any additional threads; that's done automatically by Jetty. But you do need to be prepared to handle method calls from multiple threads in a thread-safe manner.

tmiranda · #59 06-12-2010, 04:38 PM

OK, so I'm back where I started.

One instance that has to handle multiple requests, possibly more than one at a time.

Half my problem is that I do not know all of the correct Java/OO terminology.

Slugger · #60 06-12-2010, 10:18 PM

To simplify:

Each request to Jetty generates a unique HttpServletRequest and HttpServletResponse object (how those are built, be it a pool, etc. is irrelevant). Those two objects are passed to your servlet in its own thread. So your servlet will be used in all active request threads simultaneously and there will only ever be exactly one instance of your servlet, which is shared among all active request threads. This is the reason why if your servlet has instance or static vars then they must be synchronized.

And synchronization is not ideal in web apps with high volumes of traffic because when you synchronize then (in a high level view) only one request can be serviced at a time - the others must wait their turn. However, as I said above, in our (jetty apps for SageTV) little universe you can basically ignore this design goal/issue because at its busiest you're probably talking 2-3 simultaneous connections at once, which is not going to cause any kind of issues unless you do some kind of long computation inside a synchronized() block.

To me, a servlet should return a response to the browser in sub-second time so synchronized() blocks of code are fine (I even do it in my SJQ code quite liberally to protect against simultaneous modification of the SJQ task queue by multiple task clients), but your servlet should complete and return the response as quickly as possible otherwise users get a sense that the web site is "hung", etc. Ultimately, I guess the lesson here is that J2EE app design and implementation requires a bit of planning. I think Jason mentioned reading up on the servlet lifecycle? Couldn't agree more. The more you understand about the details of a J2EE app, the easier it becomes to identify and solve these kinds of issues up front - before they become bigger problems.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Plugin: SageTV Web Interface V2 for Jetty	jreichen	SageTV Customizations	256	02-09-2014 08:05 AM
Plugin: Jetty Starter 1.6	jreichen	SageTV Customizations	122	09-07-2012 06:48 PM
error message with web server plugin	edgley	SageTV Customizations	3	01-15-2006 11:32 AM
Sage Web Server and existing web server compatibilty?	Brent94Z	SageTV Customizations	6	01-18-2005 11:29 AM

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)