|
»
»
jruby-memcache-client project started on GitHub
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
jruby-memcache-client project started on GitHub
by Ikai Lan
::
Rate this Message:
Well, hopefully, no more! I've started a GitHub project to track my work here: http://github.com/ikai/jruby-memcache-client/tree/master Obviously, do not use this build. I'll let everyone know when the basic functionality is hammered down and usable. Ikai |
|
|
Re: jruby-memcache-client project started on GitHub
by Ikai Lan
::
Rate this Message:
Basically there's one thing might might be problematic: Marshal.dump and Marshal.load act weird. Some objects serialize using Marshal with a \222 character, which, after being stored on MemCache, on a subsequent get comes back as a weird ASCII character, and Marshal.load blows up. For this reason I'm using YAML serialization enough though YAML serialization is an order of magnitude slower. YAML deserialization is about 4 times slower. On 12/18/08 3:43 PM, "Ikai Lan" <ilan@...> wrote: If you've been following the thread about MemCache issues in production, you know that this has been bothering me. |
|
|
Re: jruby-memcache-client project started on GitHub
by manalang
::
Rate this Message:
What's wrong with the standard memcache-client? We use it in production (since last year) with JRuby/Rails 2.2.2. If it has to do with the thread safety issues, we got around it by setting the threadsafety flag to true in memcache-client.
Rich On Mon, Dec 22, 2008 at 2:34 PM, Ikai Lan <ilan@...> wrote:
|
|
|
Re: jruby-memcache-client project started on GitHub
by Ikai Lan
::
Rate this Message:
The dump is below. Our application servers completely freeze up and we end up needing to restart them. This happens to us about once every two days per server. The Ruby MemCache client implementation works pretty well in an MRI environment because you can use Timeout as a fallback, and because it was never designed for multithreading. Ikai Thread "httpSSLWorkerThread-8080-2" thread-id 86 thread-stateBLOCKEDWaiting on lock: org.jruby.util.io.ChannelStream@1a230ce Owned by: httpSSLWorkerThread-8080-0 Id: 42 at: org.jruby.util.io.ChannelStream.feof(ChannelStream.java:486) at: org.jruby.util.io.OpenFile.checkWritable(OpenFile.java:128) at: org.jruby.RubyIO.write(RubyIO.java:1004) at: org.jruby.RubyIO$i_method_1_0$RUBYINVOKER$write.call(org/jruby/RubyIO$i_method_1_0$RUBYINVOKER$write.gen) at: org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:391) at: ruby.jit.ruby.opt.local.glassfish.domains.domain1.applications.j2ee_minus_modules.polls.WEB_minus_INF.gems.gems.activesupport_minus_2_dot_2_dot_2.lib.active_support.vendor.memcache_minus_client_minus_1_dot_5_dot_1.memcache.cache_get20982185_4606416.__file__(memcache.rb:585) at: org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:286) at: org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:442) at: ruby.jit.ruby.opt.local.glassfish.domains.domain1.applications.j2ee_minus_modules.polls.WEB_minus_INF.gems.gems.activesupport_minus_2_dot_2_dot_2.lib.active_support.vendor.memcache_minus_client_minus_1_dot_5_dot_1.memcache.get7349425_4606416.rescue_1$RUBY$__rescue__(memcache.rb:236) On 12/22/08 5:24 PM, "Rich Manalang" <rich.manalang@...> wrote: What's wrong with the standard memcache-client? We use it in production (since last year) with JRuby/Rails 2.2.2. If it has to do with the thread safety issues, we got around it by setting the threadsafety flag to true in memcache-client. |
|
|
Re: jruby-memcache-client project started on GitHub
by manalang
::
Rate this Message:
Ah... I see. We haven't seen the issue yet since it's an internal app that hasn't seen the volume of traffic that yours has. Good to know though.
Rich On Mon, Dec 22, 2008 at 5:53 PM, Ikai Lan <ilan@...> wrote:
|
|
|
Re: jruby-memcache-client project started on GitHub
by straightflush@gmail.com
::
Rate this Message:
What volume is considered "high volume" where this might occur ?
On Mon, Dec 22, 2008 at 9:41 PM, Rich Manalang <rich.manalang@...> wrote: Ah... I see. We haven't seen the issue yet since it's an internal app that hasn't seen the volume of traffic that yours has. Good to know though. |
|
|
Re: jruby-memcache-client project started on GitHub
by Albert Ramstedt-3
::
Rate this Message:
Thank you for this, we are using memcache-client too, and have been
experiencing issues when a memcache-node dies, and we traced back the issue to Timeout. So even in a low-volume app this might be a problem when you want to service one of your nodes. We'll be looking forward to using your memcache-client, Ikai :D. Thanks again! Albert On Tue, Dec 23, 2008 at 4:18 AM, AD <straightflush@...> wrote: > What volume is considered "high volume" where this might occur ? > > On Mon, Dec 22, 2008 at 9:41 PM, Rich Manalang <rich.manalang@...> > wrote: >> >> Ah... I see. We haven't seen the issue yet since it's an internal app >> that hasn't seen the volume of traffic that yours has. Good to know though. >> >> Rich >> >> On Mon, Dec 22, 2008 at 5:53 PM, Ikai Lan <ilan@...> wrote: >>> >>> The threadsafety option only wraps the calls in a Mutex. There's no >>> connection pooling, and all the connections use the same socket. In a high >>> traffic application, the Ruby MemCache client ends up in a state where it >>> blocks a connector thread but doesn't timeout, and the JRuby Timeout >>> implementation should not be relied on to recover from IO blocking. Enabling >>> Multithread support exacerbates this problem because all connectors threads >>> become blocked waiting for the Mutex to be released. We sent the thread >>> dumps to Sun, and Charlie and team put together a fix in 1.1.6. It seems to >>> have helped a lot but we are still seeing issues. >>> >>> The dump is below. Our application servers completely freeze up and we >>> end up needing to restart them. This happens to us about once every two days >>> per server. The Ruby MemCache client implementation works pretty well in an >>> MRI environment because you can use Timeout as a fallback, and because it >>> was never designed for multithreading. >>> >>> Ikai >>> >>> >>> Thread "httpSSLWorkerThread-8080-2" thread-id 86 >>> thread-stateBLOCKEDWaiting on lock: org.jruby.util.io.ChannelStream@1a230ce >>> Owned by: httpSSLWorkerThread-8080-0 Id: 42 at: >>> org.jruby.util.io.ChannelStream.feof(ChannelStream.java:486) >>> at: org.jruby.util.io.OpenFile.checkWritable(OpenFile.java:128) >>> at: org.jruby.RubyIO.write(RubyIO.java:1004) >>> at: >>> org.jruby.RubyIO$i_method_1_0$RUBYINVOKER$write.call(org/jruby/RubyIO$i_method_1_0$RUBYINVOKER$write.gen) >>> at: >>> org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:391) >>> at: >>> ruby.jit.ruby.opt.local.glassfish.domains.domain1.applications.j2ee_minus_modules.polls.WEB_minus_INF.gems.gems.activesupport_minus_2_dot_2_dot_2.lib.active_support.vendor.memcache_minus_client_minus_1_dot_5_dot_1.memcache.cache_get20982185_4606416.__file__(memcache.rb:585) >>> at: >>> org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:286) >>> at: >>> org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:442) >>> at: >>> ruby.jit.ruby.opt.local.glassfish.domains.domain1.applications.j2ee_minus_modules.polls.WEB_minus_INF.gems.gems.activesupport_minus_2_dot_2_dot_2.lib.active_support.vendor.memcache_minus_client_minus_1_dot_5_dot_1.memcache.get7349425_4606416.rescue_1$RUBY$__rescue__(memcache.rb:236) >>> >>> >>> On 12/22/08 5:24 PM, "Rich Manalang" <rich.manalang@...> wrote: >>> >>> What's wrong with the standard memcache-client? We use it in production >>> (since last year) with JRuby/Rails 2.2.2. If it has to do with the thread >>> safety issues, we got around it by setting the threadsafety flag to true in >>> memcache-client. >>> >>> Rich >>> >>> On Mon, Dec 22, 2008 at 2:34 PM, Ikai Lan <ilan@...> wrote: >>> >>> It's at a state where it is functional. I'm still testing it in my >>> application to see if I can find problems. I'm going to push my application >>> to staging and bang on it. >>> >>> Basically there's one thing might might be problematic: Marshal.dump and >>> Marshal.load act weird. Some objects serialize using Marshal with a \222 >>> character, which, after being stored on MemCache, on a subsequent get comes >>> back as a weird ASCII character, and Marshal.load blows up. For this reason >>> I'm using YAML serialization enough though YAML serialization is an order of >>> magnitude slower. YAML deserialization is about 4 times slower. >>> >>> >>> >>> On 12/18/08 3:43 PM, "Ikai Lan" <ilan@...> wrote: >>> >>> If you've been following the thread about MemCache issues in production, >>> you know that this has been bothering me. >>> >>> Well, hopefully, no more! I've started a GitHub project to track my work >>> here: >>> >>> http://github.com/ikai/jruby-memcache-client/tree/master >>> >>> Obviously, do not use this build. I'll let everyone know when the basic >>> functionality is hammered down and usable. >>> >>> Ikai >>> >>> >>> >>> >> > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: jruby-memcache-client project started on GitHub
by straightflush@gmail.com
::
Rate this Message:
has anyone looked at ehcache for Jruby ?
On Tue, Dec 23, 2008 at 3:26 AM, Albert Ramstedt <albert.ramstedt@...> wrote: > Thank you for this, we are using memcache-client too, and have been > experiencing issues when a memcache-node dies, and we traced back the > issue to Timeout. So even in a low-volume app this might be a problem > when you want to service one of your nodes. We'll be looking forward > to using your memcache-client, Ikai :D. Thanks again! > > Albert > > On Tue, Dec 23, 2008 at 4:18 AM, AD <straightflush@...> wrote: >> What volume is considered "high volume" where this might occur ? >> >> On Mon, Dec 22, 2008 at 9:41 PM, Rich Manalang <rich.manalang@...> >> wrote: >>> >>> Ah... I see. We haven't seen the issue yet since it's an internal app >>> that hasn't seen the volume of traffic that yours has. Good to know though. >>> >>> Rich >>> >>> On Mon, Dec 22, 2008 at 5:53 PM, Ikai Lan <ilan@...> wrote: >>>> >>>> The threadsafety option only wraps the calls in a Mutex. There's no >>>> connection pooling, and all the connections use the same socket. In a high >>>> traffic application, the Ruby MemCache client ends up in a state where it >>>> blocks a connector thread but doesn't timeout, and the JRuby Timeout >>>> implementation should not be relied on to recover from IO blocking. Enabling >>>> Multithread support exacerbates this problem because all connectors threads >>>> become blocked waiting for the Mutex to be released. We sent the thread >>>> dumps to Sun, and Charlie and team put together a fix in 1.1.6. It seems to >>>> have helped a lot but we are still seeing issues. >>>> >>>> The dump is below. Our application servers completely freeze up and we >>>> end up needing to restart them. This happens to us about once every two days >>>> per server. The Ruby MemCache client implementation works pretty well in an >>>> MRI environment because you can use Timeout as a fallback, and because it >>>> was never designed for multithreading. >>>> >>>> Ikai >>>> >>>> >>>> Thread "httpSSLWorkerThread-8080-2" thread-id 86 >>>> thread-stateBLOCKEDWaiting on lock: org.jruby.util.io.ChannelStream@1a230ce >>>> Owned by: httpSSLWorkerThread-8080-0 Id: 42 at: >>>> org.jruby.util.io.ChannelStream.feof(ChannelStream.java:486) >>>> at: org.jruby.util.io.OpenFile.checkWritable(OpenFile.java:128) >>>> at: org.jruby.RubyIO.write(RubyIO.java:1004) >>>> at: >>>> org.jruby.RubyIO$i_method_1_0$RUBYINVOKER$write.call(org/jruby/RubyIO$i_method_1_0$RUBYINVOKER$write.gen) >>>> at: >>>> org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:391) >>>> at: >>>> ruby.jit.ruby.opt.local.glassfish.domains.domain1.applications.j2ee_minus_modules.polls.WEB_minus_INF.gems.gems.activesupport_minus_2_dot_2_dot_2.lib.active_support.vendor.memcache_minus_client_minus_1_dot_5_dot_1.memcache.cache_get20982185_4606416.__file__(memcache.rb:585) >>>> at: >>>> org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:286) >>>> at: >>>> org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:442) >>>> at: >>>> ruby.jit.ruby.opt.local.glassfish.domains.domain1.applications.j2ee_minus_modules.polls.WEB_minus_INF.gems.gems.activesupport_minus_2_dot_2_dot_2.lib.active_support.vendor.memcache_minus_client_minus_1_dot_5_dot_1.memcache.get7349425_4606416.rescue_1$RUBY$__rescue__(memcache.rb:236) >>>> >>>> >>>> On 12/22/08 5:24 PM, "Rich Manalang" <rich.manalang@...> wrote: >>>> >>>> What's wrong with the standard memcache-client? We use it in production >>>> (since last year) with JRuby/Rails 2.2.2. If it has to do with the thread >>>> safety issues, we got around it by setting the threadsafety flag to true in >>>> memcache-client. >>>> >>>> Rich >>>> >>>> On Mon, Dec 22, 2008 at 2:34 PM, Ikai Lan <ilan@...> wrote: >>>> >>>> It's at a state where it is functional. I'm still testing it in my >>>> application to see if I can find problems. I'm going to push my application >>>> to staging and bang on it. >>>> >>>> Basically there's one thing might might be problematic: Marshal.dump and >>>> Marshal.load act weird. Some objects serialize using Marshal with a \222 >>>> character, which, after being stored on MemCache, on a subsequent get comes >>>> back as a weird ASCII character, and Marshal.load blows up. For this reason >>>> I'm using YAML serialization enough though YAML serialization is an order of >>>> magnitude slower. YAML deserialization is about 4 times slower. >>>> >>>> >>>> >>>> On 12/18/08 3:43 PM, "Ikai Lan" <ilan@...> wrote: >>>> >>>> If you've been following the thread about MemCache issues in production, >>>> you know that this has been bothering me. >>>> >>>> Well, hopefully, no more! I've started a GitHub project to track my work >>>> here: >>>> >>>> http://github.com/ikai/jruby-memcache-client/tree/master >>>> >>>> Obviously, do not use this build. I'll let everyone know when the basic >>>> functionality is hammered down and usable. >>>> >>>> Ikai >>>> >>>> >>>> >>>> >>> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: jruby-memcache-client project started on GitHub
by Nick Sieger-2
::
Rate this Message:
There's http://github.com/dylanz/ehcache/tree/master which I believe
Dylan got resonably complete. /Nick On Wed, Feb 11, 2009 at 10:02 PM, AD <straightflush@...> wrote: > has anyone looked at ehcache for Jruby ? > > On Tue, Dec 23, 2008 at 3:26 AM, Albert Ramstedt > <albert.ramstedt@...> wrote: >> Thank you for this, we are using memcache-client too, and have been >> experiencing issues when a memcache-node dies, and we traced back the >> issue to Timeout. So even in a low-volume app this might be a problem >> when you want to service one of your nodes. We'll be looking forward >> to using your memcache-client, Ikai :D. Thanks again! >> >> Albert >> >> On Tue, Dec 23, 2008 at 4:18 AM, AD <straightflush@...> wrote: >>> What volume is considered "high volume" where this might occur ? >>> >>> On Mon, Dec 22, 2008 at 9:41 PM, Rich Manalang <rich.manalang@...> >>> wrote: >>>> >>>> Ah... I see. We haven't seen the issue yet since it's an internal app >>>> that hasn't seen the volume of traffic that yours has. Good to know though. >>>> >>>> Rich >>>> >>>> On Mon, Dec 22, 2008 at 5:53 PM, Ikai Lan <ilan@...> wrote: >>>>> >>>>> The threadsafety option only wraps the calls in a Mutex. There's no >>>>> connection pooling, and all the connections use the same socket. In a high >>>>> traffic application, the Ruby MemCache client ends up in a state where it >>>>> blocks a connector thread but doesn't timeout, and the JRuby Timeout >>>>> implementation should not be relied on to recover from IO blocking. Enabling >>>>> Multithread support exacerbates this problem because all connectors threads >>>>> become blocked waiting for the Mutex to be released. We sent the thread >>>>> dumps to Sun, and Charlie and team put together a fix in 1.1.6. It seems to >>>>> have helped a lot but we are still seeing issues. >>>>> >>>>> The dump is below. Our application servers completely freeze up and we >>>>> end up needing to restart them. This happens to us about once every two days >>>>> per server. The Ruby MemCache client implementation works pretty well in an >>>>> MRI environment because you can use Timeout as a fallback, and because it >>>>> was never designed for multithreading. >>>>> >>>>> Ikai >>>>> >>>>> >>>>> Thread "httpSSLWorkerThread-8080-2" thread-id 86 >>>>> thread-stateBLOCKEDWaiting on lock: org.jruby.util.io.ChannelStream@1a230ce >>>>> Owned by: httpSSLWorkerThread-8080-0 Id: 42 at: >>>>> org.jruby.util.io.ChannelStream.feof(ChannelStream.java:486) >>>>> at: org.jruby.util.io.OpenFile.checkWritable(OpenFile.java:128) >>>>> at: org.jruby.RubyIO.write(RubyIO.java:1004) >>>>> at: >>>>> org.jruby.RubyIO$i_method_1_0$RUBYINVOKER$write.call(org/jruby/RubyIO$i_method_1_0$RUBYINVOKER$write.gen) >>>>> at: >>>>> org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:391) >>>>> at: >>>>> ruby.jit.ruby.opt.local.glassfish.domains.domain1.applications.j2ee_minus_modules.polls.WEB_minus_INF.gems.gems.activesupport_minus_2_dot_2_dot_2.lib.active_support.vendor.memcache_minus_client_minus_1_dot_5_dot_1.memcache.cache_get20982185_4606416.__file__(memcache.rb:585) >>>>> at: >>>>> org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:286) >>>>> at: >>>>> org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:442) >>>>> at: >>>>> ruby.jit.ruby.opt.local.glassfish.domains.domain1.applications.j2ee_minus_modules.polls.WEB_minus_INF.gems.gems.activesupport_minus_2_dot_2_dot_2.lib.active_support.vendor.memcache_minus_client_minus_1_dot_5_dot_1.memcache.get7349425_4606416.rescue_1$RUBY$__rescue__(memcache.rb:236) >>>>> >>>>> >>>>> On 12/22/08 5:24 PM, "Rich Manalang" <rich.manalang@...> wrote: >>>>> >>>>> What's wrong with the standard memcache-client? We use it in production >>>>> (since last year) with JRuby/Rails 2.2.2. If it has to do with the thread >>>>> safety issues, we got around it by setting the threadsafety flag to true in >>>>> memcache-client. >>>>> >>>>> Rich >>>>> >>>>> On Mon, Dec 22, 2008 at 2:34 PM, Ikai Lan <ilan@...> wrote: >>>>> >>>>> It's at a state where it is functional. I'm still testing it in my >>>>> application to see if I can find problems. I'm going to push my application >>>>> to staging and bang on it. >>>>> >>>>> Basically there's one thing might might be problematic: Marshal.dump and >>>>> Marshal.load act weird. Some objects serialize using Marshal with a \222 >>>>> character, which, after being stored on MemCache, on a subsequent get comes >>>>> back as a weird ASCII character, and Marshal.load blows up. For this reason >>>>> I'm using YAML serialization enough though YAML serialization is an order of >>>>> magnitude slower. YAML deserialization is about 4 times slower. >>>>> >>>>> >>>>> >>>>> On 12/18/08 3:43 PM, "Ikai Lan" <ilan@...> wrote: >>>>> >>>>> If you've been following the thread about MemCache issues in production, >>>>> you know that this has been bothering me. >>>>> >>>>> Well, hopefully, no more! I've started a GitHub project to track my work >>>>> here: >>>>> >>>>> http://github.com/ikai/jruby-memcache-client/tree/master >>>>> >>>>> Obviously, do not use this build. I'll let everyone know when the basic >>>>> functionality is hammered down and usable. >>>>> >>>>> Ikai >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
| Free embeddable forum powered by Nabble | Forum Help |
