You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by eaglei22 <jc...@gmail.com> on 2013/12/31 00:32:56 UTC
MultiThreading issues with Wicket.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: MultiThreading issues with Wicket.
Posted by Paul Bors <pa...@bors.ws>.
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 <jc...@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
>
> 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
>
> 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 WARN RequestCycleExtra-Handling the following exception
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/MultiThreading-issues-with-Wicket-tp4663325p4663453.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: MultiThreading issues with Wicket.
Posted by Martin Grigorov <mg...@apache.org>.
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 <as...@gmail.com>wrote:
> 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 <mgrigorov@apache.org
> >wrote:
>
> > Hi,
> >
> >
> > On Sat, Jan 4, 2014 at 1:06 AM, eaglei22 <jc...@gmail.com> wrote:
> >
> >
>
Re: MultiThreading issues with Wicket.
Posted by Andrew Schetinin <as...@gmail.com>.
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 <mg...@apache.org>wrote:
> Hi,
>
>
> On Sat, Jan 4, 2014 at 1:06 AM, eaglei22 <jc...@gmail.com> wrote:
>
>
Re: MultiThreading issues with Wicket.
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Sat, Jan 4, 2014 at 1:06 AM, eaglei22 <jc...@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 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
>
> 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 WARN RequestCycleExtra-Handling the following exception
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/MultiThreading-issues-with-Wicket-tp4663325p4663453.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: MultiThreading issues with Wicket.
Posted by eaglei22 <jc...@gmail.com>.
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
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 WARN RequestCycleExtra-Handling the following exception
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/MultiThreading-issues-with-Wicket-tp4663325p4663453.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: MultiThreading issues with Wicket.
Posted by Paul Bors <pa...@bors.ws>.
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 <jc...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: MultiThreading issues with Wicket.
Posted by eaglei22 <jc...@gmail.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: MultiThreading issues with Wicket.
Posted by eaglei22 <jc...@gmail.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: MultiThreading issues with Wicket.
Posted by Paul Bors <pa...@bors.ws>.
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 <pa...@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
> Model<Integer>(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);
> ...
> Form<Void> 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 implements IClusterable {
> private static final long serialVersionUID = 1L;
> private String feedbackKey;
> private boolean done;
> private Throwable error;
> public TaskStatus() { }
> public TaskStatus(Throwable error, String feedbackKey) {
> setError(error);
> setFeedbackKey(feedbackKey);
> }
> public String getFeedbackKey() {
> return feedbackKey;
> }
> public void setFeedbackKey(String feedbackKey) {
> this.feedbackKey = feedbackKey;
> }
> public boolean isDone() {
> return done;
> }
> public void setDone(boolean done) {
> this.done = done;
> }
> public Throwable getError() {
> return error;
> }
> public void setError(Throwable error) {
> this.error = error;
> }
> }
> }
>
>
>
> On Thu, Jan 2, 2014 at 2:40 PM, eaglei22 <jc...@gmail.com> wrote:
>
>> 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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
Re: MultiThreading issues with Wicket.
Posted by Paul Bors <pa...@bors.ws>.
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
Model<Integer>(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);
...
Form<Void> 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 implements IClusterable {
private static final long serialVersionUID = 1L;
private String feedbackKey;
private boolean done;
private Throwable error;
public TaskStatus() { }
public TaskStatus(Throwable error, String feedbackKey) {
setError(error);
setFeedbackKey(feedbackKey);
}
public String getFeedbackKey() {
return feedbackKey;
}
public void setFeedbackKey(String feedbackKey) {
this.feedbackKey = feedbackKey;
}
public boolean isDone() {
return done;
}
public void setDone(boolean done) {
this.done = done;
}
public Throwable getError() {
return error;
}
public void setError(Throwable error) {
this.error = error;
}
}
}
On Thu, Jan 2, 2014 at 2:40 PM, eaglei22 <jc...@gmail.com> wrote:
> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: MultiThreading issues with Wicket.
Posted by eaglei22 <jc...@gmail.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: MultiThreading issues with Wicket.
Posted by Paul Bors <pa...@bors.ws>.
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.synchronizedList<http://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 <jc...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: MultiThreading issues with Wicket.
Posted by eaglei22 <jc...@gmail.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: MultiThreading issues with Wicket.
Posted by eaglei22 <jc...@gmail.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: MultiThreading issues with Wicket.
Posted by eaglei22 <jc...@gmail.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: MultiThreading issues with Wicket.
Posted by Paul Borș <pa...@bors.ws>.
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 <jc...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org