I have a servlet program for counting numbers, I want to control it through an html interface.
by pressing the start button the program must start running and by pressing pause button the servlet program must be paused and by clicking on the restart button it must restart again. by the way i used thread. My problem is that each time I should click one button and send its value to the servlet, and when I'm getting the buttons values inside the servlet a NullPointerException is occur... any help ??
I wouldn't use a Thread for that purpose and in general is not usually a good idea to create threads in servlets.
Say we count one number per millisecond meaning: it will give me the time between one click and another in milliseconds.
One work around could be:
Click on start = save the start time in the session.
click on stop = to get the count we do currentTime-StartTime (saved in session)
Now if you really must use Threads be sure then to create it using another class.
One suggestion might be create a ThreadManager class and store it in the session (use a listener for this) and then start it in that session object.
Even better store the ThreadManager inside the servletContext and have a way to create your thread per session.
To create Threads favor the Executor classes instead of the Thread classes.
Also make sure you stop your threads since having threads created by us inside a web container may prevent it from stoping entirely.
If you provide some code I can help you further.
Good luck, have fun.
Related
I have a small IDE for a modeling language I wrote, implemented in PyQt/PySide, and am trying to implement a code navigator that let's you jump to different sections in the file being edited.
The current implementation is: (1) connect to QPlainTextEditor.textChanged, (2) any time a change is made, (sloppily) parse the file and update the navigator pane
It seems to work OK, but I'm worried this could cause major performance issues for large files on slower systems, in particular if more stuff is connected to textChanged in the future.
My question: Has anybody here implemented a delayed reaction to events, so that multiple events (i.e. keystrokes) within a short period only trigger a single update (say once per second)? And is there a proper QT way of doing this?
Thanks,
Michael
You can try using timers if you want some "delay".
There would be 2 ways to use them (with different results).
One is only parse after no input has been done for a certain amount of time
NOTE: I only know C++ Qt but I assume the same things are valid for pyqt so this is kind of "pseudocode" I hope you get the concept though.
QTimer timer; //somewhere
timer.setSingleShot(true); //only fire once
connect(timer,QTimer::timeout(),OnTimerDone(...);
OnTextChanged(...)
{
timer.start(500); //wait 500ms
}
OnTimerDone(...)
{
DoStuff(...);
}
This will restart the timer every input, so when you call that and the timer is not done the timeout signal is not emitted. When no input is done for an amount of time the timer timeouts and you parse the file.
The second option would be to have a periodic timer running (singleShot(false)).
Just start the timer for like each second. and timeout will be called once a second. You can combine that with a variable which you set to true when the input changes and to false when the file is parsed. So you avoid parsing when nothing has changed.
In C++Qt you won't have to worry about multi-threading because the slot gets called in the GUI thread. I assume it is the same for python but you should probably check this.
I'm writing some BDD tests using Cucumber, Selenium and Xunit for a legacy ASP.Net application. The way the pages are designed, every "click" leads to a new page being fetched from the server. If I have to automate the tests for a particular page, should I have a line similar to the following after every "click"?
WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(timeout));
wait.Until(...); //Wait until something about the page is true
I'm not sure if Selenium would wait implicitly for page loads without my explicitly having to state this all the time. What is the recommended pattern to handle this scenario?
It's cumbersome to always have an idea of "some element" so that I can put it in the Until method and that leads to brittle tests. The ASP.Net pages are littered with lots of dynamic controls and a whole slew of page refreshes which makes the test code quite unreadable.
My Proposed Solution: Write an extension method that does the waiting implicitly and that takes a parameter of an element-id to wait on. But I'm just refactoring the above problem into a more manageable place. I still have a wait be explicitly performed. Is there no way to eliminate it? Does selenium have some obvious default that would handle this case without the need for such an extension method or is this really a natural way of doing it?
If you want your tests be reliable and wait only the exactly needed time interval - then yes, Explicit Waits with WebDriverWait is a perfect solution. And, it's actually a very "natural" solution - think about how you, as a user, define that the page loaded - it's usually when you see the desired content, correct? When you look at the loading page, you are constantly reevaluating the state of the page, checking whether the desired content appeared or not. Explicit Waits follow the same logic - by default, every 500 ms it checks if the expected condition is true or not, but no more than X seconds you've configured when instantiating the
WebDriverWait.
If you need to use wait.until() calls often and want to follow the DRY principle, think about applying the "Extracting Method" or other refactoring methods.
You can set the implicit wait which would be applied on every element search, or introduce hardcoded "artificial" delays, but that's not going to be reliable and would be time-wasteful - you'll end up waiting more than needed and having occasional test failures.
when using FlexPrintJob, after calling start(), a OS system print interface will appear, and at the same time Flex code execution will be paused, and it will remain paused until user finished interaction with the OS print dialog. the problem is I do have data from server, and the connection will time out within certain period, so is there any walk around to not pause the Flex code execution while OS print dialog is popped up. Thanks.
From the doc for FlexPrintJob:
You use the FlexPrintJob class to print a dynamically rendered document that you format specifically for printing.
This makes me wonder if you couldn't (essentially) fork off a second page from the browser that contains your print job and do the printing from there. This would leave your original page still running. In my flex apps I do this via PHP (create additional pages for printing and such). Example here.
Otherwise: you should finish all the server data d/l before starting the print job to avoid this issue.
Flex is only just recently starting to add multi-threading. It's adding worker threads of a sort but this won't help what you're asking for.
A while ago I wrote a little RAII class to wrap the setOverrideCursor() and restoreOverrideCursor() methods on QApplication. Constructing this class would set the cursor and the destructor would restore it. Since the override cursor is a stack, this worked quite well, as in:
{
CursorSentry sentry;
// code that takes some time to process
}
Later on, I found that in some cases, the processing code would sometimes take a perceptible time to process (say more than half a second) and other times it would be near instantaneous (because of caching). It is difficult to determine before hand which case will happen, so it still always sets the wait cursor by making a CursorSentry object. But this could cause an unpleasant "flicker" where the cursor would quickly turn from the wait cursor to the normal cursor.
So I thought I'd be smart and I added a separate thread to manage the cursor override. Now, when a CursorSentry is made, it puts in a request to the cursor thread to go to the wait state. When it is destroyed it tells the thread to return to the normal state. If the CursorSentry lives longer than some amount of time (50 milliseconds), then the cursor change is processed and the override cursor is set. Otherwise, the change request is discarded.
The problem is, the cursor thread can't technically change the cursor because it's not the GUI thread. In most cases, it does happen to work, but sometimes, if I'm really unlucky, the call to change the cursor happens when the GUI thread gets mixed in with some other X11 calls, and the whole application gets deadlocked. This usually only happens if the GUI thread finishes processing at nearly the exact moment the cursor thread decides to set the override cursor.
So, does anyone know of a safe way to set the override cursor from a non-GUI thread. Keep in mind that most of the time, the GUI thread is going to be busy processing stuff (that's why the wait cursor is needed after all), so I can't just put an event into the GUI thread queue, because it won't be processed until its too late. Also, it is impractical to move the processing I'm talking about to a separate thread, because this is happening during a paint event and it needs to do GUI work when its done (figuring out what to draw).
Any other ideas for adding a delay to setting the override cursor would be good, too.
I don't think there is any other way besides a Signal-Slot connection going to the GUI thread followed by a qApp->processEvents() call, but like you said, this would probably not work well when the GUI thread is tied up.
The documentation for QCoreApplication::processEvents also has some recommended usages with long event processing:
This function overloads processEvents(). Processes pending events for
the calling thread for maxtime milliseconds or until there are no more
events to process, whichever is shorter.
You can call this function
occasionally when you program is busy doing a long operation (e.g.
copying a file).
Calling this function processes events only for the
calling thread.
If possible break up the long calls in the paint event and have it periodically check to see how long it has been taking. And in any of those checks, have it set the override cursor then from in the GUI Thread.
Often a QProgressBar can go a long way to convey the same information to the user.
Another option that could help quite a bit would be to render outside of the GUI thread onto a QImage buffer and then post it to the GUI when it is done.
I have an application which makes use of 20 different classes. The program execution starts in mainwindow. I start a progress dialog. I will make use of different classes for different purposes. After each function call which the execution goes to the particular class and does the required and come back to the mainwindow class, I will update the progress dialog. Now, the issue is the progress dialog freezes when the execution goes away from the mainwindow class. The cancel button is unable to accessed and so, the execution could not be stopped at the required time.
mainclass::mainclass()
{
ProgressDialog->exec();
x->add();
updateProgressDialog();
y->do();
updateProgressDialog();
zz->bring();
updateProgressDialog();
}
// x, y, z are three different classes.
This is how the execution goes. As soon as I enter the function in the main class, I will start the progress dialog. and call functions from different classes. The functions take considerable amount of time. I have invoked a thread to do the execution part, but I am unable to cancel the progress diaolog. I want the program execution to be stopped as and when the cancel button is pressed on the proggress dialog.
Please let me know how to get away with this issue. Hope I am clear here.
Without knowing exactly what calculations are being preformed in your threads its hard to isolate the problem. Maybe this can help: Keeping the GUI Responsive
Excerpt from: Performing Long Operations (by: Witold Wysota)
During long calculations (regardless of any usage of signals and slots) all event processing gets halted. As a result, the GUI is not refreshed, user input is not processed, network activity stops and timers don't fire—the application looks like it's frozen and, in fact, the part of it not related to the time-intensive task is frozen.
The functions you are calling are not processing the Qt events loop. You are using a modal progress bar, since you are calling exec(). This means that Qt only gets control at the times where you update the dialog.
The only way that I know of to work around this is to code the dialog as modeless, but you will also have to provide an opportunity for the events loop to process.
This is explained in a fair amount of detail in the Qt docs: QProgressDialog