It looks like somewhere @session['flash'] is getting set to a regular hash. That is causing the error. FlashHash when explcitly set then works...
-Tom On Fri, 16 Jun 2006, Ola Bini defenestrated me: > Wow, goodie! > > I checked that flash implementation, and it's really strange. I trried to > extract it (just taking out FlashHash and FlashNow) and using it from irb > in regular C Ruby, > and both keep and sweep result in infinite recursion. I can't really > understand how it works in Rails.. > > /O > > At 15:08 2006-06-16, you wrote: > > HEH...Well that didn't take long. StringIO.sync= was expecting > >the wrong type. Now the cool part. Cookbook is running using jdbc > >and webrick! Well that is if I comment out flash.sweep in flash.rb > >in actionpack. I will look at that next. > > > >-Tom > > > >On Fri, 16 Jun 2006, Thomas E Enebo defenestrated me: > > > >> I added your two patches to the tree where I already have Ola's fixes. > >> I gave this a run against webrick running rails and we now get an > >> java exception versus a deadlock, so things look better. I am home sick > >> today so I will investigate. I will be applying Ola's patches today > >> and I can apply the two you sent if you want. > >> > >> Here is the stack trace from webrick+rails on a simple request: > >> Exception in thread "Ruby Thread19552406" java.lang.AssertionError: > >java.lang.IllegalArgumentException: argument type mismatch > >> > >> at > >org.jruby.runtime.callback.ReflectionCallback.execute(ReflectionCallback.java:183) > >> > >> at > >org.jruby.internal.runtime.methods.CallbackMethod.internalCall(CallbackMethod.java:79) > >> > >> at > >org.jruby.internal.runtime.methods.AbstractMethod.call(AbstractMethod.java:51) > >> > >> at org.jruby.RubyObject.callMethod(RubyObject.java:362) > >> > >> at org.jruby.RubyObject.callMethod(RubyObject.java:316) > >> > >> at > >org.jruby.evaluator.EvaluateVisitor$CallNodeVisitor.execute(EvaluateVisitor.java:555) > >> > >> at > >org.jruby.evaluator.EvaluationState.executeNext(EvaluationState.java:262) > >> > >> at > >org.jruby.evaluator.EvaluationState.begin(EvaluationState.java:297) > >> > >> at org.jruby.RubyObject.eval(RubyObject.java:440) > >> > >> at > >org.jruby.internal.runtime.methods.DefaultMethod.internalCall(DefaultMethod.java:110) > >> > >> at > >org.jruby.internal.runtime.methods.AbstractMethod.call(AbstractMethod.java:51) > >> > >> at org.jruby.RubyObject.callMethod(RubyObject.java:362) > >> > >> at org.jruby.RubyObject.callMethod(RubyObject.java:316) > >> > >> at > >org.jruby.evaluator.EvaluateVisitor$CallNodeVisitor.execute(EvaluateVisitor.java:555) > >> > >> at > >org.jruby.evaluator.EvaluationState.executeNext(EvaluationState.java:262) > >> > >> at > >org.jruby.evaluator.EvaluationState.begin(EvaluationState.java:297) > >> > >> at > >org.jruby.internal.runtime.methods.EvaluateCallable.internalCall(EvaluateCallable.java:67) > >> > >> at > >org.jruby.internal.runtime.methods.AbstractCallable.call(AbstractCallable.java:64) > >> > >> at org.jruby.runtime.ThreadContext.yield(ThreadContext.java:347) > >> > >> at > >org.jruby.evaluator.EvaluateVisitor$Yield2.execute(EvaluateVisitor.java:2020) > >> > >> at > >org.jruby.evaluator.EvaluationState.executeNext(EvaluationState.java:262) > >> > >> ... > >> > >> On Fri, 16 Jun 2006, Charles O Nutter defenestrated me: > >> > >> > > >> > So we all know our friend Ola has contributed some great pieces of > >> > work over the past several months. As another JRubyist put it, "Ola > >is > >> > a f'n machine". StringIO, YAML, and Zlib are now mostly Java and > >far, > >> > far faster than they were. These contributions have made RubyGems > >far, > >> > far faster. From the original install time on this Opteron 2.6G of > >> > almost an hour (sans rdoc, mind you), we get this: > >> > real 5m35.341s > >> > user 0m36.379s > >> > sys 0m5.195s > >> > Impressive, by any measure. Ok, so I don't remember whether it was > >> > exactly an hour to install before, but it was bloody long enough to > >> > hit the drive-in for lunch. Grotesquely slow. Ola's changes alone > >> > dropped that time down to comparatively nothing. I went through the > >> > pains this evening of applying all his patches, cleaning up > >conflicts > >> > between them (since I didn't have a complete picture), and tidying > >up > >> > a few minor things. Then I ran a full Rails install. The time was > >> > impressive, no doubt about it. However, something really, really > >> > bothered me. In the time between gem download and gem install, the > >> > machine was sitting there, doing *nothing*. No network traffic, 0% > >CPU > >> > utilization. Zippo. > >> > Then it hit me. > >> > You've all heard the story about the timeout library. net/http calls > >> > net/protocol which reads in 1024-byte chunks from the stream with a > >> > timeout thread for each one. I cried about this on my blog too, > >since > >> > it seemed to be the source of a terrible performance problem. It > >turns > >> > out that once again, Java has already optimized our troubles away, > >in > >> > this case the cost of spinning up hundreds of threads. > >> > Our NIO-based IO handler had a tiny flaw when it came to Socket IO: > >it > >> > was blocking. That meant that for the last read from the stream, the > >> > last few bytes of a gem file, it would sit and wait to fill up > >> > net/protocol's 1024-byte buffer. I am no NIO expert, but channels > >> > appear to behave somewhat differently when doing File versus Socket > >> > IO. At the end of a File, the stream is empty and read(ByteBuffer) > >> > will immediately return -1. With a Socket, however, if there are not > >> > enough bytes to fill the buffer and the socket is still open, it > >will > >> > block. Such is the case here. The HTTP get of a gem seems to leave > >the > >> > channel open. I'm not sure if this is intentional in RubyGems (for > >> > retrieving multiple gems) or a bug (potentially in JRuby) but > >leaving > >> > the Socket in blocking mode resulted in that last chunk of bytes > >> > waiting until timeout kicked in. > >> > My fix (in the form of a patch to IOHandlerNIO) may or may not be > >> > correct; like I said, I'm no NIO expert. However, it seems to work > >> > well enough: > >> > Attempting local installation of 'rails' > >> > Local gem file not found: rails*.gem > >> > Attempting remote installation of 'rails' > >> > Updating Gem source index for: [1]http://gems.rubyforge.org > >> > Successfully installed rails-1.1.2 > >> > Successfully installed rake-0.7.1 > >> > Successfully installed activesupport-1.3.1 > >> > Successfully installed activerecord-1.14.2 > >> > Successfully installed actionpack-1.12.1 > >> > Successfully installed actionmailer-1.2.1 > >> > Successfully installed actionwebservice-1.1.2 > >> > real 1m3.751s > >> > user 0m53.817s > >> > sys 0m5.722s > >> > For sake of comparison, Ruby installs Rails and its dependencies in > >> > about 25 seconds on my system. It's probably safe to say that we're > >> > only 2x slower for non-rdoc gem installations, which seems pretty > >good > >> > to me. > >> > The NIO patch alone is attached, as is a complete patch with > >> > everything changed on my system, including: > >> > - All Ola's stuff (stringio, zlib, and signal) > >> > - My unrelated simplifications to Thread.critical= (not as > >> > deterministic as before but less likely or unlikely to > >> > deadlock...needs a bit more testing) > >> > - My NIO fix > >> > It will be nice to say that not only have we gotten RubyGems > >working, > >> > but it's been sped up by perhaps an order of magnitude since we > >first > >> > started. > >> > -- > >> > Charles Oliver Nutter @ [2]headius.blogspot.com > >> > JRuby Developer @ [3]jruby.sourceforge.net > >> > Application Architect @ [4]www.ventera.com > >> > > >> > References > >> > > >> > 1. http://gems.rubyforge.org/ > >> > 2. http://headius.blogspot.com/ > >> > 3. http://jruby.sourceforge.net/ > >> > 4. http://www.ventera.com/ > >> > >> > >> > >> > >> > >> > _______________________________________________ > >> > Jruby-devel mailing list > >> > Jruby-devel@lists.sourceforge.net > >> > https://lists.sourceforge.net/lists/listinfo/jruby-devel > >> > >> > >> -- > >> + http://www.tc.umn.edu/~enebo +---- mailto:[EMAIL PROTECTED] ----+ > >> | Thomas E Enebo, Protagonist | "Luck favors the prepared | > >> | | mind." -Louis Pasteur | > >> > >> > >> _______________________________________________ > >> Jruby-devel mailing list > >> Jruby-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/jruby-devel > > > >-- > >+ http://www.tc.umn.edu/~enebo +---- mailto:[EMAIL PROTECTED] ----+ > >| Thomas E Enebo, Protagonist | "Luck favors the prepared | > >| | mind." -Louis Pasteur | > > > > > >_______________________________________________ > >Jruby-devel mailing list > >Jruby-devel@lists.sourceforge.net > >https://lists.sourceforge.net/lists/listinfo/jruby-devel > > > -- + http://www.tc.umn.edu/~enebo +---- mailto:[EMAIL PROTECTED] ----+ | Thomas E Enebo, Protagonist | "Luck favors the prepared | | | mind." -Louis Pasteur | _______________________________________________ Jruby-devel mailing list Jruby-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jruby-devel
