Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 00:36
    wontruefree edited #10283
  • 00:36
    wontruefree opened #10283
  • 00:04
    straight-shoota labeled #10282
  • 00:04
    straight-shoota labeled #10282
  • 00:04
    straight-shoota opened #10282
  • Jan 22 23:54
    wontruefree opened #10281
  • Jan 22 22:35
    bcardiff synchronize #10256
  • Jan 22 21:18
    bcardiff synchronize #10256
  • Jan 22 21:17
    bcardiff closed #10269
  • Jan 22 18:59
    bcardiff closed #10280
  • Jan 22 17:20
    bcardiff labeled #10280
  • Jan 22 17:20
    bcardiff milestoned #10280
  • Jan 22 17:20
    bcardiff opened #10280
  • Jan 22 15:55
    straight-shoota closed #6709
  • Jan 22 14:38
    straight-shoota edited #10210
  • Jan 22 14:38
    straight-shoota labeled #10279
  • Jan 22 14:38
    straight-shoota labeled #10279
  • Jan 22 14:38
    straight-shoota opened #10279
  • Jan 22 14:08
    straight-shoota milestoned #10269
  • Jan 22 13:56
    straight-shoota labeled #10278
From IRC (bridge bot)
@FromIRC
<DeBot> @oprypin: #=> nil - https://carc.in/#/r/a6bz
<oprypin> ok what
<straight-shoota> yeah, that really doesn't make sense because you can't call them
<straight-shoota> #10097
<DeBot> crystal-lang/crystal#10097 (Disallow top-level def super and def previous_def)
<oprypin> i'm trying to find what difference it makes the fact that lexer.cr has :⁠super but doesnt have :⁠previous_def
<straight-shoota> yeah, probably not much
From IRC (bridge bot)
@FromIRC
<oprypin> i dont even know what forall is
<oprypin> never mentioned in lexer.cr
<oprypin> what's lexer.cr even used for? lol
From IRC (bridge bot)
@FromIRC
<straight-shoota> all work done by parser
<straight-shoota> =)
Ed
@drum445
I've found a potential problem with the DB driver, I'm hosting a kemal app and the connection is handled using the standard DB.open. The problem is if the app is unused for many hours (overnight) the first request will throw a connection lost error so I've had to add a manual retry
has anyone else experienced this? Not a big deal to add a manual retry, but shouldn't the driver deal with long open connections
From IRC (bridge bot)
@FromIRC
<straight-shoota> @drum445 I'd figure this behaviour depends on the exact driver you're using
Ed
@drum445
mysql
am I right in thinking my kemal app should have a global db connection which uses DB.open, instead of calling DB.open per request?
From IRC (bridge bot)
@FromIRC
<straight-shoota> yes, totally
<straight-shoota> DB manages connections for you
Ed
@drum445
perfect, so I have a static class that looks like this (I think you may have suggested this a long time ago)
class DBHelper
  class_getter maria : DB::Database { puts "Maria init"; DB.open "mysql://root:password@localhost/test#{CONFIG}" }
end
Then my controllers that need a DB, simple use DBHelper.maria - does that sound correct?
From IRC (bridge bot)
@FromIRC
<straight-shoota> yeah
<straight-shoota> from what I understand, this works correctly for you in general?
Ed
@drum445
It works great, the only problem I've seen is when the app is unused for a while, then the first request after a long time will throw a connection error
the ones after that work, but the first one fails - to fix this I added a test query before returning the DB.open instance
From IRC (bridge bot)
@FromIRC
<straight-shoota> so it appears the pools gives you timed out connections after long time of no use
Ed
@drum445
correct
so my DBHelper class runs this @@maria_con.not_nil!.query "select 'a' 'a' from dual" { |rs| } and if it fails it reconnects before returning the DB.open instance
From IRC (bridge bot)
@FromIRC
<straight-shoota> so you do an entire new DB.open on failure?
Ed
@drum445
Yeah, I can't see any way round it
From IRC (bridge bot)
@FromIRC
<straight-shoota> yeah, there probably isn't
Ed
@drum445
cool, for now running my test query before returning the instance seems reasonable then?
From IRC (bridge bot)
@FromIRC
<straight-shoota> hm, actually DB::Pool has some retry logic that should automatically fall back to making a new connection
<straight-shoota> not sure, why that doesn't work four you
<straight-shoota> that method should implicitly be called when you execute a statement on a pool connection
Ed
@drum445
That's what I thought too from looking at the logic here: https://crystal-lang.org/reference/database/connection_pool.html
I think the problem is the pool is completely dead during that first request
From IRC (bridge bot)
@FromIRC
<straight-shoota> that shouldn't matter
<straight-shoota> if the pool has no idle connections, it establishes a new one
Ed
@drum445
intersting
          # a ConnectionRefused means a new connection
          # was intended to be created
          # nothing to due but to retry soon
I wonder if that is being hit
From IRC (bridge bot)
@FromIRC
<straight-shoota> how exactly do you run your SQL queries?
rukkiddo
@rukkiddo
do you try to connect in each query, or you try to manage the same connection
From IRC (bridge bot)
@FromIRC
<straight-shoota> and do you have a stack trace of one of those connection lost errors?
Ed
@drum445
  def find_by_username(username)
    DBHelper.maria.query("SELECT id, username, password, status, updated_at FROM users where username = ?", username) do |rs|
      rs.each do
        return rs_to_user(rs)
      end
    end

    return nil
  end
is one example
Don't think I do have the trace anymore