The blocking is necessary in order not to corrupt session state. We have as fine grained locking as possible (under the circumstances). Web applications are by nature multi-threaded. If you don't synchronize the access to certain resources (sessions) you can get bugs that are very difficult to trace.
If you need download link, there are alternatives that don't block such as shared resource. -Matej On 8/27/07, Thomas Singer <[EMAIL PROTECTED]> wrote: > > > I think the email address is quite obvious. > > I'm talking about real addresses. But as Eelco already stated, it might be > hard to list them because you are scattered over the world. I'll accept > that. > > > Ever heard of open source? Just think about it a little. You have a > product > > that a group of people spend lot of time developing and they are giving > it > > to you for free. > > Sure, I know the advantages (and disadvantages) of Open Source. I thank > you > for making Wicket freely available and try to spread good words about it > (if > possible). > > > So now just because your problem haven't been fixed in 10 > > hours, you feel "sick" about it? > > No, I just feel (a little bit!) sick, that we've found such a IMHO major > problem after having invested a couple of weeks work. > > > It blocks only if that is a component request (it blocks on pagemap). If > you > > have large files you need to use shared resources that don't block. Also > the > > block is only one pagemap only (thus one session) and it lasts only for > a > > minute. No need to restart tomcat server. > > Most likely I don't understand the reasons behind the blocking, but from a > user's point of view, a *download* never should block the application. The > timeout (from the server side!) is also not very good for raising the > website-user's trust. > > I know we are ab-using Wicket a little bit for a web*site*, but when I > think > on a web*application* like JIRA, I also can't imagine at least one usecase > (always from my user's point of view) which accepts a timeout or blocking > when downloading a larger file. > > -- > Cheers, > Tom > > > Matej Knopp wrote: > > On 8/27/07, Thomas Singer <[EMAIL PROTECTED]> wrote: > >>> Your best bet on getting quick support is to fix it yourself and send > >>> in a patch. > >> Well, if that would be possible, I would have done that or worked > around > >> it > >> myself (like done with some own components). > >> > >>> http://www.wicket-support.com/ > >> Sorry to say, but I hate websites where you can't find an address on > it. > > > > > > I think the email address is quite obvious. > > > > What Wicket core developer can provide support (e.g. because (s)he is > >> working in the mentioned companies)? Or are you "only" working in your > >> spare-time on Wicket? > > > > > > Please understand me: I had a good feeling about Wicket, but this > >> show-stopper problem makes me feel a little bit sick, because I don't > know > >> whether there are other such problems which prevent using Wicket for > our > >> website at all. > > > > > > Ever heard of open source? Just think about it a little. You have a > product > > that a group of people spend lot of time developing and they are giving > it > > to you for free. So now just because your problem haven't been fixed in > 10 > > hours, you feel "sick" about it? > > > > BTW, I still have the feeling, that if Wicket provides a feature to > download > >> something large (except normal pages), it must not block until this > file > >> is > >> downloaded. My co-worker told me (I haven't verified), that he stopped > the > >> download and this also blocked Wicket. He had to restart Tomcat! > > > > It blocks only if that is a component request (it blocks on pagemap). If > you > > have large files you need to use shared resources that don't block. Also > the > > block is only one pagemap only (thus one session) and it lasts only for > a > > minute. No need to restart tomcat server. > > > > -Matej > > > > > > -- > >> Best regards, > >> Thomas Singer > >> _____________ > >> SyntEvo GmbH > >> Brunnfeld 11 > >> 83404 Ainring > >> Germany > >> www.syntevo.com > >> > >> > >> Eelco Hillenius wrote: > >>> On 8/27/07, Thomas Singer <[EMAIL PROTECTED]> wrote: > >>>> Isn't fixing bugs the task of the Wicket developers? We don't have a > >> problem > >>>> ordering support, but I could not find information where to get it. > >>> It's unfortunate you have an urgent problem. Sorry about that. > >>> However, everyone of the development team does most of the working on > >>> Wicket, including following this very time consuming mailing list, in > >>> their spare time. > >>> > >>> Some of us joined in a support initiative: > >>> http://www.wicket-support.com/, and you might be able to get some very > >>> direct support there. For all I know they are pretty busy right now. > >>> As long as Wicket doesn't have the same number of users as Spring of > >>> JBoss, it's going to be very hard to build support that's always > >>> available. And there are the companies listed at > >>> http://cwiki.apache.org/WICKET/companies-that-provide-services.html > >>> like Gerolf said. > >>> > >>> Your best bet on getting quick support is to fix it yourself and send > >>> in a patch. This is not because we're lazy, but because we're very > >>> short on spare time. It may be easier than you think to provide a > >>> patch, and maybe you get hire a wizard programmer somewhere who knows > >>> his or her way around Wicket. > >>> > >>> Regards, > >>> > >>> Eelco > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
