Re: MultiThreading issues with Wicket.
Hi, We were also plagued by these EOF errors since upgrade to Wicket 6 from 1.4. In the old Wicket the errors (which are not errors - it's an expected behavior when a user cancels navigation) were not reported in such aggressive manner, with long stack traces. How is it possible to hide these errors or better convert them to a one-line WARN messages? Where is the best place to catch them? Regards, Andrew -- Andrew Schetinin On Sat, Jan 4, 2014 at 11:50 AM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, On Sat, Jan 4, 2014 at 1:06 AM, eaglei22 jchojnack...@gmail.com wrote:
Re: MultiThreading issues with Wicket.
You can extend your logging library and check for this specific exception and convert it to one line... (too much work, imo). You can also add custom IRequestCycleListener and catch the error in #onException() and do something else. Martin Grigorov Wicket Training and Consulting On Sat, Jan 18, 2014 at 12:07 PM, Andrew Schetinin ascheti...@gmail.comwrote: Hi, We were also plagued by these EOF errors since upgrade to Wicket 6 from 1.4. In the old Wicket the errors (which are not errors - it's an expected behavior when a user cancels navigation) were not reported in such aggressive manner, with long stack traces. How is it possible to hide these errors or better convert them to a one-line WARN messages? Where is the best place to catch them? Regards, Andrew -- Andrew Schetinin On Sat, Jan 4, 2014 at 11:50 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, On Sat, Jan 4, 2014 at 1:06 AM, eaglei22 jchojnack...@gmail.com wrote:
Re: MultiThreading issues with Wicket.
Hi, On Sat, Jan 4, 2014 at 1:06 AM, eaglei22 jchojnack...@gmail.com wrote: Here is the errors I get: Jan 03 17:04:20 WARN RequestCycleExtra- Jan 03 17:04:20 WARN RequestCycleExtra-Handling the following exception org.eclipse.jetty.io.RuntimeIOException: org.eclipse.jetty.io.EofException at org.eclipse.jetty.io.UncheckedPrintWriter.setError(UncheckedPrintWriter.java:107) This error usually means that the client (the browser) has closed the connection before the server had chance to write the response back to it. It could be caused by many things: - manual: just press ESC key while the server is doing something for a longer time. This will tell the browser to close the connection - IE sometimes switches the compat modes for some reason and this often causes any background connections (like Ajax, image loading, script loading) to be restarted. I.e. the original connection is closed so the first request cannot finish - ... at org.eclipse.jetty.io.UncheckedPrintWriter.write(UncheckedPrintWriter.java:280) at org.eclipse.jetty.io.UncheckedPrintWriter.write(UncheckedPrintWriter.java:295) at org.apache.wicket.protocol.http.servlet.ServletWebResponse.sendRedirect(ServletWebResponse.java:251) at org.apache.wicket.protocol.http.HeaderBufferingWebResponse.sendRedirect(HeaderBufferingWebResponse.java:117) at org.apache.wicket.request.handler.render.WebPageRenderer.redirectTo(WebPageRenderer.java:157) at org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:300) at org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:165) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:861) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:310) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:233) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1323) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:474) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:517) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:247) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:151) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:114) at org.eclipse.jetty.server.Server.handle(Server.java:341) at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:589) at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1065) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:823) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:220) at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:515) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529) at java.lang.Thread.run(Thread.java:662) Caused
Re: MultiThreading issues with Wicket.
I seem to be able to avoid this by limiting the amount of rows I print to the screen from the ListView. I turned it into a PageableListView and put a max of 200 per page, and the problem went away. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/MultiThreading-issues-with-Wicket-tp4663325p4663438.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: MultiThreading issues with Wicket.
As per the API: Exception invoked when when stale link has been clicked. The page should then be rerendered with an explanatory error message. Read more about the Sateless Links http://wicket.apache.org/guide/guide/chapter9.html#chapter9_5 And about Page Versions: http://wicket.apache.org/guide/guide/chapter7.html Or provide us with a quickstart so we can see what's going on. Or the full stack trace at least. On Fri, Jan 3, 2014 at 10:13 AM, eaglei22 jchojnack...@gmail.com wrote: I seem to be able to avoid this by limiting the amount of rows I print to the screen from the ListView. I turned it into a PageableListView and put a max of 200 per page, and the problem went away. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/MultiThreading-issues-with-Wicket-tp4663325p4663438.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: MultiThreading issues with Wicket.
Here is the errors I get: Jan 03 17:04:20 WARN RequestCycleExtra- Jan 03 17:04:20 WARN RequestCycleExtra-Handling the following exception org.eclipse.jetty.io.RuntimeIOException: org.eclipse.jetty.io.EofException at org.eclipse.jetty.io.UncheckedPrintWriter.setError(UncheckedPrintWriter.java:107) at org.eclipse.jetty.io.UncheckedPrintWriter.write(UncheckedPrintWriter.java:280) at org.eclipse.jetty.io.UncheckedPrintWriter.write(UncheckedPrintWriter.java:295) at org.apache.wicket.protocol.http.servlet.ServletWebResponse.sendRedirect(ServletWebResponse.java:251) at org.apache.wicket.protocol.http.HeaderBufferingWebResponse.sendRedirect(HeaderBufferingWebResponse.java:117) at org.apache.wicket.request.handler.render.WebPageRenderer.redirectTo(WebPageRenderer.java:157) at org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:300) at org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:165) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:861) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:310) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:233) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1323) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:474) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:517) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:247) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:151) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:114) at org.eclipse.jetty.server.Server.handle(Server.java:341) at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:589) at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1065) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:823) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:220) at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:515) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529) at java.lang.Thread.run(Thread.java:662) Caused by: org.eclipse.jetty.io.EofException at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:149) at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:96) at java.io.ByteArrayOutputStream.writeTo(ByteArrayOutputStream.java:109) at org.eclipse.jetty.server.HttpWriter.write(HttpWriter.java:283) at org.eclipse.jetty.server.HttpWriter.write(HttpWriter.java:107) at org.eclipse.jetty.io.UncheckedPrintWriter.write(UncheckedPrintWriter.java:271) ... 40 more Jan 03 17:04:20 WARN RequestCycleExtra- Jan 03 17:04:20 ERROR DefaultExceptionMapper-Unexpected error occurred org.eclipse.jetty.io.RuntimeIOException: org.eclipse.jetty.io.EofException at
Re: MultiThreading issues with Wicket.
Looks like your Jetty is calling the Wicket filter that in turn crashes because of an EOF Exception. How about a quick start? On Fri, Jan 3, 2014 at 6:06 PM, eaglei22 jchojnack...@gmail.com wrote: Here is the errors I get: Jan 03 17:04:20 WARN RequestCycleExtra- Jan 03 17:04:20 WARN RequestCycleExtra-Handling the following exception org.eclipse.jetty.io.RuntimeIOException: org.eclipse.jetty.io.EofException at org.eclipse.jetty.io.UncheckedPrintWriter.setError(UncheckedPrintWriter.java:107) at org.eclipse.jetty.io.UncheckedPrintWriter.write(UncheckedPrintWriter.java:280) at org.eclipse.jetty.io.UncheckedPrintWriter.write(UncheckedPrintWriter.java:295) at org.apache.wicket.protocol.http.servlet.ServletWebResponse.sendRedirect(ServletWebResponse.java:251) at org.apache.wicket.protocol.http.HeaderBufferingWebResponse.sendRedirect(HeaderBufferingWebResponse.java:117) at org.apache.wicket.request.handler.render.WebPageRenderer.redirectTo(WebPageRenderer.java:157) at org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:300) at org.apache.wicket.core.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:165) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:861) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:310) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.executeExceptionRequestHandler(RequestCycle.java:319) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:233) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1323) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:474) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:517) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:934) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:404) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:869) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:247) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:151) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:114) at org.eclipse.jetty.server.Server.handle(Server.java:341) at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:589) at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1065) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:823) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:220) at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:515) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529) at java.lang.Thread.run(Thread.java:662) Caused by: org.eclipse.jetty.io.EofException at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:149) at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:96) at java.io.ByteArrayOutputStream.writeTo(ByteArrayOutputStream.java:109) at org.eclipse.jetty.server.HttpWriter.write(HttpWriter.java:283) at org.eclipse.jetty.server.HttpWriter.write(HttpWriter.java:107) at
Re: MultiThreading issues with Wicket.
Following the example for multi-threading, I still randomly get:
SSAID: Access6
count: 1213
SSAID: Access6
java.io.IOException: Read error
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:220)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at java.io.BufferedReader.fill(BufferedReader.java:136)
at java.io.BufferedReader.readLine(BufferedReader.java:299)
at java.io.BufferedReader.readLine(BufferedReader.java:362)
at com.boeing.wicket.BulkLoadPage.processLine(BulkLoadPage.java:557)
at com.boeing.wicket.BulkLoadPage.access$0(BulkLoadPage.java:533)
at
com.boeing.wicket.BulkLoadPage$BatchLoaderProcessingThread.run(BulkLoadPage.java:1316)
at java.lang.Thread.run(Thread.java:662)
Jan 02 10:18:10 ERROR BulkLoadPage-java.io.IOException: Read error
as you can see the count is an integer to keep track of the lines, and it is
always random.. one run it can be 1213, the next 303...
here is my thread:
class BatchLoaderProcessingThread extends Thread
{
BufferedReader buffReader2;
public BatchLoaderProcessingThread(BufferedReader buffReader2)
{
this.buffReader2 = buffReader2;
}
@Override
public void run()
{
if(buffReader2 == null)
{
System.out.println(Inside thread, is null);
}
processLine(buffReader2);
loaderFinished();
}
public void cancelThread()
{
cancelLoaderThread = true;
}
}
and it gets stuck here on the buffReadr.readLine())
while((strLine = buffReadr.readLine()) != null (!cancelLoaderThread
!cancelDeleterThread))
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/MultiThreading-issues-with-Wicket-tp4663325p4663387.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: MultiThreading issues with Wicket.
I have temporarily fixed it by first loading the lines into a string ArrayList and just read from that list.. I don't really see any latency issues, so maybe this can be considered a good alternative? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/MultiThreading-issues-with-Wicket-tp4663325p4663389.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: MultiThreading issues with Wicket.
I don't think that's a good idea since ArrayList is not thread-safe :) http://docs.oracle.com/javase/7/docs/api/java/util/ArrayList.html *Note that this implementation is not synchronized.* If multiple threads access an ArrayList instance concurrently, and at least one of the threads modifies the list structurally, it *must* be synchronized externally. (A structural modification is any operation that adds or deletes one or more elements, or explicitly resizes the backing array; merely setting the value of an element is not a structural modification.) This is typically accomplished by synchronizing on some object that naturally encapsulates the list. If no such object exists, the list should be wrapped using the Collections.synchronizedListhttp://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#synchronizedList(java.util.List)method. This is best done at creation time, to prevent accidental unsynchronized access to the list: List list = Collections.synchronizedList(new ArrayList(...)); On Thu, Jan 2, 2014 at 11:43 AM, eaglei22 jchojnack...@gmail.com wrote: I have temporarily fixed it by first loading the lines into a string ArrayList and just read from that list.. I don't really see any latency issues, so maybe this can be considered a good alternative? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/MultiThreading-issues-with-Wicket-tp4663325p4663389.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: MultiThreading issues with Wicket.
Great catch Paul. I have made the changes reccommended. However, I read the
file into the arrayList using the main thread, and then use the worker
thread for processing. I don't think the ArrayList is being modified during
this time, but just incase something is happening beyond my knowledge under
the hood that will need this or in the future I will be modifying the
contents of the Array, I have made the neccessary changes as you suggested.
The only thing I noticed is after my worker thread finishes, my
AbstractAjaxTimerBehavior in the main thread seems to take about 10 seconds
or so before it performs a component update on the List, even though I have
it set to 1.
I don't get any errors anymore though, and the whole list does get processed
now.
here is my settings for AbstractAjaxTimerBehavior:
resultsUpdateBehavior = new
AbstractAjaxTimerBehavior(Duration.seconds(1))
{
/**
*
*/
private static final long serialVersionUID =
-4790160167650215915L;
@Override
public void onTimer(AjaxRequestTarget target)
{
if (!loaderIsRunning !deleterIsRunning)
{
target.add(loaderListContainer);
resultsUpdateBehavior.stop(target);
target.add(progress);
// progressUpdateBehavior.stop(target);
}
else
{
target.add(loaderListContainer);
target.add(progress);
}
}
};
add(resultsUpdateBehavior);
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/MultiThreading-issues-with-Wicket-tp4663325p4663394.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: MultiThreading issues with Wicket.
Your main thread must be the request cycle's worker thread that wicket
has for your syncronized on the page.
If something takes more than 1 sec as you would expect ti to, it must mean
that whatever you're doing on the page is running your CPU high keeping it
bussy long enough for the 10 secs.
In other words, you must be doing something wrong.
Here's an example of how to detach a thread from your Wicket page:
public class DictionaryMappingPage extends AdminPage {
...
// Background thread's status
private TaskStatus taskStatus = new TaskStatus();
// Progress bar that will replace the button
private ProgressBar progressBar = new ProgressBar(progress, new
ModelInteger(0));
public DictionaryMappingPage() {
...
// timer that will be started on the button press
final AjaxSelfUpdatingTimerBehavior updatingTimerBehavior = new
AjaxSelfUpdatingTimerBehavior(Duration.seconds(1)) {
private static final long serialVersionUID = 1L;
@Override
protected void onPostProcessTarget(final AjaxRequestTarget
target) {
// Progress bar is deterministic, so hack around it to make
it look non-deterministic (we don't know how long this will take)
if(progressBar.getModelObject() = 90) {
progressBar.setModelObject(0);
}
progressBar.forward(target, 10);
if (taskStatus.isDone()) {
stop(target);
if (taskStatus.getError() == null) {
info(ResourceKeyHelper.resourceValue(dictionary.mapping.export.success));
ajaxDownload.initiate(target);
} else {
log.debug(taskStatus.getError().getLocalizedMessage(),
taskStatus.getError());
error(ResourceKeyHelper.resourceValue(taskStatus.getFeedbackKey()));
}
// Toggle visibility of components on the page (button
and progress bar)
exportButton.setEnabled(true);
exportButton.setVisible(true);
progressBar.setVisible(false);
MyPageUtils.refreshComp(target, exportButton);
MyPageUtils.refreshComp(target, progressBar);
MyPageUtils.refreshFeedback(target, exportButton);
} else {
if(exportButton.isEnabled()) {
stop(target);
}
}
}
};
// Adds the behaviour somewhere on the page, title in this case
pageTitle.add(updatingTimerBehavior);
...
FormVoid exportForm = ...
add(exportForm);
// Default page state
progressBar.setVisible(false);
progressBar.setOutputMarkupId(true);
progressBar.setOutputMarkupPlaceholderTag(true);
exportForm.add(progressBar);
// There we go...
exportButton = new AjaxButton(exportButton, new
ResourceModel(dictionary.mapping.export.file.button)) {
private static final long serialVersionUID = 1L;
@Override
protected void onSubmit(AjaxRequestTarget target, Form? form)
{
// User selected the Export button, toggle hide the button
and show the progress bar (they are overlayed)
setEnabled(false);
setVisible(false);
progressBar.setVisible(true);
progressBar.setModelObject(0);
// Let's keep track of the background task
taskStatus = new TaskStatus(taskStatus.getError(),
taskStatus.getFeedbackKey());
// Start the timer event that will update the UI each
second via Ajax
updatingTimerBehavior.restart(target);
// We have a thread pool at the application level to share for background
tasks
ConsoleApplication.THREAD_POOL.submit(new Runnable() {
// This is our Runnable detached from the page, updatingTimerBehavior will
keep refreshing the page
public void run() {
try {
// Inside working thread, perform your background tasks here
} finally {
taskStatus.setDone(true);
}
}
});
MyPageUtils.refreshComp(target, this);
MyPageUtils.refreshComp(target, progressBar);
}
};
exportButton.setOutputMarkupId(true);
exportButton.setOutputMarkupPlaceholderTag(true);
exportButton.add(buttonStyle);
exportForm.add(exportButton);
...
}
...
/**
* Lightweight implementation of a background task's state as it
integrates with the UI.
*
* TODO: If we start using more than one background task we might as
well switch to using wicket-progressbar.
* @see a href=https://github.com/wicketstuff/core/wiki/Progressbar
wicket-progressbar/a
*/
private class TaskStatus
Re: MultiThreading issues with Wicket.
And for your curiosity, the THREAD_POOL is nothing but an ExecutorService
inside the WebApplication:
/**
* Cashed thread pool used for background tasks that are outside of the
Quartz scheduler.
* TODO: We might be better off using a spring service
*/
public static final ExecutorService THREAD_POOL =
Executors.newCachedThreadPool();
As per the JavaDoc, this is not the best solution but is working so far for
the single button we have.
Once we'll add a second use-case I'm planning on switching it to a Spring
service so we can inject the pool itself.
On Thu, Jan 2, 2014 at 3:15 PM, Paul Bors p...@bors.ws wrote:
Your main thread must be the request cycle's worker thread that wicket
has for your syncronized on the page.
If something takes more than 1 sec as you would expect ti to, it must mean
that whatever you're doing on the page is running your CPU high keeping it
bussy long enough for the 10 secs.
In other words, you must be doing something wrong.
Here's an example of how to detach a thread from your Wicket page:
public class DictionaryMappingPage extends AdminPage {
...
// Background thread's status
private TaskStatus taskStatus = new TaskStatus();
// Progress bar that will replace the button
private ProgressBar progressBar = new ProgressBar(progress, new
ModelInteger(0));
public DictionaryMappingPage() {
...
// timer that will be started on the button press
final AjaxSelfUpdatingTimerBehavior updatingTimerBehavior = new
AjaxSelfUpdatingTimerBehavior(Duration.seconds(1)) {
private static final long serialVersionUID = 1L;
@Override
protected void onPostProcessTarget(final AjaxRequestTarget
target) {
// Progress bar is deterministic, so hack around it to
make it look non-deterministic (we don't know how long this will take)
if(progressBar.getModelObject() = 90) {
progressBar.setModelObject(0);
}
progressBar.forward(target, 10);
if (taskStatus.isDone()) {
stop(target);
if (taskStatus.getError() == null) {
info(ResourceKeyHelper.resourceValue(dictionary.mapping.export.success));
ajaxDownload.initiate(target);
} else {
log.debug(taskStatus.getError().getLocalizedMessage(),
taskStatus.getError());
error(ResourceKeyHelper.resourceValue(taskStatus.getFeedbackKey()));
}
// Toggle visibility of components on the page (button
and progress bar)
exportButton.setEnabled(true);
exportButton.setVisible(true);
progressBar.setVisible(false);
MyPageUtils.refreshComp(target, exportButton);
MyPageUtils.refreshComp(target, progressBar);
MyPageUtils.refreshFeedback(target, exportButton);
} else {
if(exportButton.isEnabled()) {
stop(target);
}
}
}
};
// Adds the behaviour somewhere on the page, title in this case
pageTitle.add(updatingTimerBehavior);
...
FormVoid exportForm = ...
add(exportForm);
// Default page state
progressBar.setVisible(false);
progressBar.setOutputMarkupId(true);
progressBar.setOutputMarkupPlaceholderTag(true);
exportForm.add(progressBar);
// There we go...
exportButton = new AjaxButton(exportButton, new
ResourceModel(dictionary.mapping.export.file.button)) {
private static final long serialVersionUID = 1L;
@Override
protected void onSubmit(AjaxRequestTarget target, Form?
form) {
// User selected the Export button, toggle hide the button
and show the progress bar (they are overlayed)
setEnabled(false);
setVisible(false);
progressBar.setVisible(true);
progressBar.setModelObject(0);
// Let's keep track of the background task
taskStatus = new TaskStatus(taskStatus.getError(),
taskStatus.getFeedbackKey());
// Start the timer event that will update the UI each
second via Ajax
updatingTimerBehavior.restart(target);
// We have a thread pool at the application level to share for background
tasks
ConsoleApplication.THREAD_POOL.submit(new Runnable() {
// This is our Runnable detached from the page, updatingTimerBehavior will
keep refreshing the page
public void run() {
try {
// Inside working thread, perform your background tasks here
} finally {
taskStatus.setDone(true);
}
Re: MultiThreading issues with Wicket.
Thanks Paul I really appreciate your time and efforts to assist me in this issue. I have implemented your reccommendations and I was still getting the same issues (This seems to only be with the larger file as well) and I thought it was the AjaxSelfUpdatingTimer but instead it looks like the page was just refreshing due to a stalePageException: count: 15469 SSAID: Access6 Stopped, total line size = 15469.0 Stopped, total line size = 15469.0 Jan 02 16:54:37 WARN RequestCycleExtra- Jan 02 16:54:37 WARN RequestCycleExtra-Handling the following exception org.apache.wicket.core.request.mapper.StalePageException Jan 02 16:54:37 WARN RequestCycleExtra- I seem to get this when I try to load upload the same file again after the first instance has finished. I am going to try and run a file that takes a bit longer to process to see if I still get the same errors. At the moment the file finishes processing at about a second, I do add a printline inside my timer method and it shows it has stopped well before the actual repaint of the table, so this is what makes me thing the actual final repaint is due to the StalePageException. This exception only occurs though on the consol when I try to upload a new file, or click on any of the buttons on the page. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/MultiThreading-issues-with-Wicket-tp4663325p4663397.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: MultiThreading issues with Wicket.
Awesome resources to look over. Thanks Paul! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/MultiThreading-issues-with-Wicket-tp4663325p4663355.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: MultiThreading issues with Wicket.
Wicket sometimes makes things easier for us that we forget what's under the hood :) Remember that most of your implementation is already thread safe and synced on the Page. Read more about the request cycle in the free guide at: http://wicket.apache.org/guide/guide/chapter8.html So you want to perform a long running operation in a separate thread? Try this post: http://javathoughts.capesugarbird.com/2008/04/spawning-thread-for-lengthy-operation.html Have a great day, Paul Bors On Dec 30, 2013, at 6:32 PM, eaglei22 jchojnack...@gmail.com wrote: Hello, I am having an issue when using a worker thread to process a csv file. I have asked the same question here: http://stackoverflow.com/questions/20747605/requestcycle-goes-null-when-using-a-separate-thread and I wanted to post here as I feel there are not many Wicket programmers there. The main issue seems to be when I process a large csv file I get a read error. But if I process a smaller one I do not. Here is the stack trace: java.io.IOException: Read error at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:220) at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.read1(BufferedReader.java:185) at java.io.BufferedReader.read(BufferedReader.java:261) at java.io.BufferedReader.fill(BufferedReader.java:136) Dec 30 13:14:31 ERROR BulkLoadPage-java.io.IOException: Read error at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) at au.com.bytecode.opencsv.CSVReader.getNextLine(CSVReader.java:266) at au.com.bytecode.opencsv.CSVReader.readNext(CSVReader.java:233) at com..wicket.BulkLoadPage.processLine(BulkLoadPage.java:547) at com..wicket.BulkLoadPage.access$0(BulkLoadPage.java:532) at com..wicket.BulkLoadPage$BatchLoaderProcessingThread.run(BulkLoadPage.java:1294) at java.lang.Thread.run(Thread.java:662) I basically have a listView that is being updated by the main thread using AjaxSelfUpdatingTimer - set to update every 1 second. The worker thread which is an inner runnable class uses the methods of the main class, and updates the arrayList which is also stored in the main class and used by the listView. I was originally getting a requestCycle error, which seemed to be resolved by commenting out my feedbackPanel error message inside my catch. That error seemed to be produced from a read error produced by the reference to the CSVReader. The file being read in contains many lines. I believe around 15k. Every line has the same data which I copied and pasted just to test a large file. The file seems to work fine when it is less than 2k.. so I am thinking maybe it is a sychronization issue or some issue with data interleaving. I had designed this page not knowing there would be issues with larger files using a thread.. there is a lot of functionality and there is no issues with a small file as stated.. just larger ones. The only job of the thread is to call a method from the main thread. That method loops through and processes the CSV file, and when that ends.. the thread dies. Should I be using local variables in the thread? Or what are some steps I can take to troubleshooting this error? Or is there a better way I should approach this to having a worker thread process results while the main thread uses a listView to display results. A dataView was reccommended and I will try that as well, but I am not sure if I can use a worker thread with that or not. Thank you. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/MultiThreading-issues-with-Wicket-tp4663325.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
