J.H.B. Oosterlaar

Ranch Hand
+ Follow
since Sep 12, 2002
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by J.H.B. Oosterlaar

Hi,
Is there a way to restart or re-initialize the ServletContext/webapplication from within the Servlet itself?
Thanks and cheers,
Jeroen
18 years ago
Hi,
I just want a confirmation/explaination on the buffering of requests. We are developing a system that we want to sequentially handle requests. Various customers make use of the Servlet, where the sequentiality only matters for one customer.
First we wrote a Servlet that was directly instantiated. All requests were handled by this Servlet in sequential order. No matter what customer the request belonged to.
Now we came up with the following idea and tested it:
The Servlet is a dispatching Servlet, that dispatches request handling for a specific customer. It contains a table of handlers (that are instantiated at initialization to ensure sequential processing per customer) for each customer. When a request comes in with a parameter for the customer identifier, the Servlet uses that key to pass the request on to the specific handler.
In other words:
- The Servlet is a dispatcher containing a table of handlers.
- Each handler belongs to a customer and is instantiated at Servlet initialization.
- The Servlet does not handle requests sequential.
- The specific handler handles requests sequential.
Requests for customer A does not have to wait for requests for customer B. Requests for customer A do wait for eachother.
A requesttimeschema could look something like this:
CUSTOMER | TIMESTAMP
-----------------------------------
A | 15
A | 15
B | 16
A | 17
B | 20
B | 21
A | 18
A | 19
B | 40
The timestamps are in chronological order for each customer.
We tested this and it worked, but can anyone of you explain or confirm this? In our first situation buffering of request took place before the Servlet itself, now it seems that the buffering takes place before a certain handler, without bothering the other handlers.
Thanks in advance!
Jeroen Oosterlaar
18 years ago
Hi,
We just found out that Thread management and URL decoding don't go hand in hand.
What is the setup?
A Servlet enqueue requestinformation (such as the referrer-url) as a JavaBean. A concurrent Thread dequeues the beans and processes the contained information including the decoding of the referrer-url.
What is the critical situation?
The refferer-url can be NULL. The decoding of a NULL value, does not throw an fatal exception. Only when catching all exceptions, an exception is caught about the NULL value. But again, there is not fatal exception.
What are the consequences?
When this happens within the Thread, the Thread is simply being killed. Without any exception or other notice. The buffer keeps growing and growing, because of the fact that the dequeueing Thread doesn't exsist anymore.
Do you know why this happens? I really don't get it. It doesn't make sense, or does it?
Thanks in advance.
Cheers,
Jeroen
Well, it's not that I need to know the exact time of arrival. The time of arrival at the Servlet is important.
The situation is as follows: the HTTP requests comes in. The Servlet handles the requests sequential and puts some information retrieved from the request in a bean and enqueues the bean in a queue. Another process running besides the Servlet dequeues the queue and handles the beans: storing the information in the database. This way requests can be handled quickly, without having to wait for storage with its business logic.
Well, the points is that the other process' business logic retrieves the last request of a certain group from the database to check some things with its current handled request. If the request handles was to be concurrent, then I could never be sure, that there wouldn't be a older request still coming. I need to be sure requests of a certain group follow eachother in order of arrival.
18 years ago
Hi,
I need to process request data on the FIFO (first in first out) basis. The only way to be sure that the requests are handled in order of arrival, is to process the requests sequentially.
A pre-instantiated Servlet has a global action object that handles the request. The service method call a perform() method of that action, giving the request and response contexts as arguments. This way each request is handled sequentially. The action object stores the handled request as a bean in a queue. Another concurrent process dequeues for further processing. This concurrent process needs the queue elements in order of arrival.
I want to know whether this is acceptable or not. I don't see any other solution.
Thanks in advance!
Jeroen
18 years ago
Hi,
This is the simple representation of the situation: a producer (Servlet) produces queue elements and enqueues the elements (the queue is a Singleton datastructure). A consumer dequeues the elements for processing. The produces could produce elements all the time (in a very extreme situation), and should always be able to enqueue.
The consumer is a Thread that is always running. When the queue is empty, it calls yield(), if not it dequeues the first element and processes it.
What I need to know, is it a normal Java situation, that the consumerthread is always running? The proces of enqueue and dequeue has to be asynchrone, so a consumer proces is needed to handle elements independantly.
Thanks in advance!
Jeroen
Thanks, I found out myself. Threads aren't even possible. Say I develop my own dispatcher. My actions are extensions of Thread. When I pass the request object to that action, it cannot be used anymore. The reference is lost. Thanks for the comments.
18 years ago
Hi,
I was thinking. The Action dispatching is not multithreaded. In other words: the Action does nog extends Thread nor does it implements Runnable.
What is the reason for this? When there are many client requests, there will be a waitbuffer, won't there be? Request are handled after eachother.
Could anyone explain this? We are developing a dispatcher that dispatches jobs to actions that need to be Threads, because they extract data from the database. In order to not slowing down other requests, we made it an extension of Thread.
Thanks and cheers,
Jeroen Oosterlaar
18 years ago
Hi,
I don't know how to classify (session, entity, etc.) the following beans:
*. A bean that acts as a manager. It has a method "void addData(...". It keeps its own buffer of data. When the buffer reaches its limit, the manager writes its buffer to the database. This bean has to be called by more clients. Every client has the same reference. The writing of the buffer should be asynchron.
*. The bufferelements. This is a bean with getters and setters. These beans are stored in the buffer from the manager.
Is this a good setup for an EJB environment within the EJB container, or should we handle it totally different.
Thanks and cheers!
Jeroen
Hi,
The situation: We have a Servlet that receives HTTP requests. These requests need to be stored in a database. To prevent the Servlet from waiting on the write action, we want the writing to be a asynchronic process.
The (possible) solution: We use a EJB container which contains beans. A message-driven-bean is used to 'transfer' the HTTP request data (the Servlet calls the message-driven-bean). The message-driven-bean passes the data (probably a bean also), to the buffering entity bean. After a buffering limit has been reached, the buffer is written to the database.
QUESTION 1: How should we approach this enitity bean? Just a bean that has its own buffer (Vector for instance)? Or do we need to define the entity bean by it's unique element. The entity bean represents an element from the buffer, so there is no actual buffer. We prefer the first option, since there is some business logic involved on the database storage (testing, etc.). The buffer is filled, when the limit has been reached, it instantiates a Thread that does the actual storing, so that the buffering itself can continue.
Continue: When the Servlet is first instantiated, it needs to know a maximum value from the database. We don't want to make another database connection around the EJB container, so we want to do this through the EJB container.
QUESTION 2: We need an EJB that retrieves the needed value from the database and can be called by the Servlet, so that this Servlet can get the value. This EJB does not need to exsist for a long period. It only has to be instantiated when the Servlet calls it. What kind of bean do we have to use? We really want it to be inside the EJB container.
Thanks in advance!
Jeroen Oosterlaar
P.S. Is this a good way of solving the storage? Or would the use of Thread in the Servlet container be sufficient?
Well, when running the client, I get not a single "classnotfound". Only the bounding goes wrong.
But you say that the bean was deployed correctly. I doubt that. When I deploy a completely empty jar file in the directory, it gives exactly the same message. How is this possible? Older versions of JBoss gave errors. And why don't I get the output from ejbCreate()? This method is invoked on deployment, right?
18 years ago
Hi,
I've a EJB setup using the instructions on the JBoss website. The method do() simply prints out a message to the standard output. Besides the do() method there are also bean methods like ejbCreate(), ejbRemove(), etc. Within these methods I have printed out their method names (System.out.println("ejbCreate()") . When I deploy the jarfile JBoss say:

I expect there would be the method outputs here, but they aren't printed.
Second, when I run my example program, it gives a:

My ejb-jar.xml:

My jboss.xml:

Compilation goes well. But I can't invoke the EJB and the deployment doesn't seem to go well, because there is no output... the bean is not actually deployed?
Please help.
Thanks,
Jeroen
[ March 12, 2003: Message edited by: J.H.B. Oosterlaar ]
[ March 12, 2003: Message edited by: J.H.B. Oosterlaar ]
18 years ago
Problem solved . After I did some research, I found that since Struts 1.1 beta 2, there is a tag attribute that sets XHTML output.
For those who are interested:
http://jakarta.apache.org/struts/faqs/kickstart.html#xhtml
18 years ago

Originally posted by Syamsul Hussin:
hi, i dont understand about the throws modifier. for example, why do i have to throw java.lang.InterruptedException if i want to use thread in the method body?, why cant i use try and catch statement before i use thread in my code and try to catch the exception instead?


You don't have to throw the InterruptedException, you can simply catch it within the method. I don't know what makes you believe otherwise. For example:

Jeroen Oosterlaar
18 years ago
Hi,
I've have a question regarding the Struts output not being strict HTML or XHTML. For example the following Struts tag:

When requesting the JSP, the converted output is something like:

The tag does not follow the conventions. It should be:

The W3C gives notice of not being validated for Strict HTML nor XHTML.
How is it possible that a standard like Struts does not follow these conventions? Is there a way to set the output to these conventions (without rewriting the output handler of course )? Or is there a "plugin" written for it?
Thanks in advance and cheers,
Jeroen Oosterlaar
18 years ago