Before this I had them deployed using apache22 and Phusion Passenger (without RVM). This set up wasn’t working well for me. I’m not saying it’s the wrong way to go (I’m also not going to say a zillion rails users can’t be wrong) but it wasn’t performing well for me and it wasn’t really my style. I’ve been using apache forever, and piling more and more crap on top of it was just getting frustrating. It really just wasn’t built for this.

So I start to hear about all these young httpds like lighttpd, nginx, and cherokee. I poked around a bit, and I decided cherokee’s graphical configuration interface sounded nice for a change. At this point I should inform you that I did not at all download or look much into lighttpd or nginx. They could be just as good for this, but that’s another blog entry on another blog.

Mongrel or Unicorn or Thin or WEBrick or…

One of the first things you need to decide is which back end you want to run. Cherokee needs to know about these processes as this is how it’ll speak to your app (see the cherokee section below). By default, rails (and almost any rack app) uses WEBrick. WEBrick is great for development, but it’s pure ruby and pretty slow. I don’t think you want it serving up your production sites. Historically, a mongrel cluster has been the method of choice for deploying rails. However, mongrel doesn’t run on ruby-1.9 which is what I use to deploy. Thin is a great little server that combines mongrel’s parser with EventMachine (a fast event-based code system) with rack. Thin can run just about any kind of rack app (rack, rails2, rails3, ramaze, probably more) and is really easy to use. However, cherokee isn’t great at maintaining a thin cluster for you. If one of your instances dies, you’re going to end up handing someone a 502 error at least once. I personally decided to go with unicorn. Unicorn can’t really handle being a front-facing server because it has no KeepAlive support. It acknowledges this, and expects you to use nginx (or in our case, cherokee) in front of it. The great thing about unicorn is that it spawns a management process and then a cluster of workers. The management process does the listening, and decides which worker is best suited to handle your request. If any of the workers die, or need to be killed, the management process will restart them. This means you only need one information source in cherokee (since it manages its own workers it only needs one port, whereas something like thin will need a separate port and thus a separate information source per server in a cluster). I ended up going with unicorn for my big production rails apps with 2-4 workers, and a single thin instance for small sinatra apps that don’t get a lot of load.

When it comes down to it, this decision is up to you. If you like thin be prepared to juggle as many information sources in cherokee as you have thin servers per cluster. Also be prepared for 502 errors while cherokee spawns thin if it’s not running. Once spawned, thin will stay running even if cherokee exits (not the case with unicorn, which will exit if cherokee exits or restarts). I don’t have personal experience with mongrel, but it probably goes something along the same path as thin. WEBrick… well… I guess if that’s how you roll.

Cherokee and RVM

Cherokee was the relatively easy part. Aside from the fact that the neat wizards it uses to add virtual servers don’t usually work right (it seems to assume you’re using rails-2.2 from the ancient times), the process is pretty simple. You can use the rails wizard to get started. After that, go to the information sources it creates. Here is where you need to tweak. It creates three by default. Depending on which back end you decided on earlier, you’ll have to tweak these to your pleasure. Most important is the spawning command. This is the command cherokee executes if it can’t find the interpreter running where it’s supposed to be. First, however, each information source has to have an environment. You can inherit the environment from cherokee (probably not what you want) or you can set up a fresh one. Since we’re using RVM we’re going to need bash, because RVM is written in bash shell script. One of the maddening things that happened to me was that I was executing the right commands without realizing there was no PATH and so RVM couldn’t work because bash couldn’t be found. So if nothing else, create an environment variable named PATH with some value along the lines of:

/bin:/usr/bin:/usr/local/bin:/usr/local/www/.rvm/bin

You should change that last bit there to the location of the RVM installation you’re using. Other pertinent environment variables might be things such as RAILS_ENV and RACK_ENV (for “production”, “development”, etc).

The starting point and probably most intensive part of this is RVM. RVM is a set of shell scripts and environment trickery that allows you to install and manage multiple versions of ruby. In addition to this it allows you to separate gems into “gemsets” which are unique to each version of ruby you have managed. The gemsets allow you to install a fresh set of gems for each gemset. This was why I was determined to use RVM with my deployment. I don’t really need multiple versions of ruby itself, but doing that would work just fine with how I did things as well. I installed a limited set of gems that appear in all gemsets (the “global” gemset) such as rake and bundler and thin and unicorn. After that, each app has its own gemset with its own local version of rails, rack, and whatever else it needs. This keeps things nicely partitioned and even acts as a sandbox to some degree (to really get sandboxing, bundler offers just superb possibilities).

However, RVM also proved to be the most difficult part of this setup to get working properly. When you’re working with RVM in your shell you have environment variables and your shell loads RVM’s magic into itself when you first start the shell. Of course, cherokee isn’t going to execute your ~/.profile when it runs the interpreter for requests. So how do you get RVM’s magic in there? RVM provides a set of “wrappers” that set up all of its environment and magic. These are in ~/.rvm/wrappers/ by default. So in cherokee’s information source you need to set up PATH as described above. After that, it’s really just a matter of perfecting your spawn command. I use unicorn, which only requires a single information source, and my RVM is installed in /usr/local/www/.rvm/, so my spawn command looks something like:

/usr/local/www/.rvm/wrappers/ruby-1.9.2-p180@NameOfApp/ruby /usr/local/www/.rvm/gems/ruby-1.9.2-p180@global/bin/unicorn_rails -c /usr/local/www/NameOfApp/unicorn.conf -E production

Wow, that’s a mess. Unfortunately they’re probably all going to be pretty messy like this. So let’s break that down:

/path/to/rvm/wrapper/ruby-version@gemset/ruby /path/to/backend --args

The first command is your ruby executable. Since cherokee doesn’t know about RVM, in order to allow RVM to set up its magic you have to execute a bash script in the wrappers/ directory. This script sets up the necessary magic for the gemset you selected (in this case, NameOfApp) and executes the ruby binary with those gems. The second part is the back end you’re using. In my case, I execute unicorn_rails which I’ve installed as a gem in the global gemset (which appears in all gemsets for that ruby version) and pass it a configuration file that tells it what app it’s serving and how to serve it. Let’s say you’re using the default rails server:

/path/to/rvm/wrapper/ruby-version@gemset/ruby /path/to/rails_app/script/server -p port

This is a little easier, right? In rails-2.3.x (use rails server or script/rails server for rails-3) this would probably launch WEBrick listening on the port that your cherokee information source is expecting (cherokee asks us not to pass any flags to make the server daemonize as cherokee takes care to route the input/output/error streams to useful places and manages other aspects that forking would break). The bit that makes others installed as a gem ugly looking is that you have to find the binary they installed and you have to figure out how to tell them “go in /path/to/rails_app and run that app in there.” With unicorn, you can tell it that (and much more) with a unicorn.conf (that doesn’t need to be in the same directory as the app). With thin, you can tell it that with a configuration file that thin can output using thin config or you can simply run thin start -c /path/to/rails_app. While mine in particular is kind of ugly, it isn’t as complex as it appears.

Once you figure out the right spawning command, and the RVM scripts can figure out everything they need to run from PATH, you should be good to go. Depending on what back end you’re using, the first time you try to visit the app’s address you might get a 502 error from cherokee while it launches the spawning process (typically happens with thin but not with unicorn, and sometimes with script/server) so if you get a 502 try refreshing the page immediately.

Troubleshooting

A lot can go wrong. I think probably just about all of it went wrong for me at some point.

502 Bad Gateway

This is the error cherokee tosses out if it can’t get one of your information sources on the phone. This can be because they’re all busy, but more likely if you’re reading this it’s because your spawn command is broken. The best way to investigate this is to set up an error log in the virtual server using the information source that isn’t working. Cherokee will log the output from the spawn command here. If you see something like ruby not found it’s because you’ve gotten the first part of your spawn command wrong. First off, use full paths. Don’t assume ruby-1.9.2-p180@NameOfApp is in the PATH you set. Sometimes even if it is, it still won’t run right without a full path. If you see something like env: bash not found it’s because something or another wasn’t found in your PATH. Make sure the PATH you set includes anything ruby, RVM, or your back end needs to run.

Another chance is that your spawn command is right but the app you’re trying to run is having an error. Maybe you’re missing a gem, or there’s a syntax error, or any other ruby-level error that’d cause a backtrace in ruby. You can examine your back end or app logs to find this. Another good way to make sure that your app runs fine is running an equivalent of the spawn command in your shell. Try thin start in an app you’re running with thin. If it’s a ruby backtrace you’ll see it here. Same goes for unicorn_rails or script/server. Generally, if your app runs in your development environment and it doesn’t run here, it’s because you forgot something like a gem or other dependency. Also make sure you’re using the right ruby/gemset in RVM. Running the back end by hand before allowing cherokee to spawn it automatically is always a good idea.

504 Gateway Timeout

This usually happens because, while cherokee can get one of your information sources on the phone, it doesn’t answer in a timely fashion. This can be because you’re getting slammed and they’re just running slowly, or more likely because one of the back end processes is attempting to process a request that’s taking a while. This can be anything from something CPU-intensive to something database-intensive. Examine your SQL queries. check your back end or app logs. For me, this is most often a network or database issue.

The End

I hope this helps. If not, and you’re using cherokee, RVM, and rack apps, my contact information is all over this blog. Feel free to get in touch.

Comcast’s argument goes along the lines of a peering dispute. Level 3 is sending much more traffic to Comcast’s network than Comcast is sending to Level 3′s network, thus Level 3 must pay (let’s ignore that this is Comcast’s very business model: their customers are allotted much more download bandwidth than upload bandwidth, but Comcast feigns surprise). This happened just a few years ago when Cogent was passing much more traffic onto Level 3′s network than Level 3 was onto Cogent’s network. Cogent refused to pay up, and Level 3 terminated their peering arrangement. The case of Level 3 vs Cogent was right, and the case of Comcast vs Level 3 is wrong, and here’s why.

The Simple Explanation

Comcast is wrong, because Level 3 isn’t sending traffic over Comcast’s network in order to reach a destination on the other side of Comcast’s network (called transmit traffic). Level 3 is delivering Netflix content from its network directly to Comcast customers, because Comcast customers have asked for this content (“I want to watch this movie, stream it to my face please”). Comcast’s subscribers are paying Comcast for this. What Comcast is doing is turning around and making Level 3 pay for the same thing again. They are double-dipping, just as they have in the past. When it was Level 3 vs Cogent, Cogent was transmitting traffic over Level 3′s network to another end point. They were using Level 3 to cut their own costs because, at the time, Level 3 was directly peering with Cogent’s end destination, and it was saving Cogent money while costing Level 3 money. This is not the same thing. Level 3 is delivering traffic directly to Comcast, not using Comcast’s network to transmit traffic to a different end point. Comcast’s customers are paying Comcast to deliver this content to them, and the people that are doing the actual delivering shouldn’t only not have to pay Comcast, they should actually be getting paid by Comcast. You pay the UPS driver, not the other way around.

The Not-As-Simple Explanation

It’s a little more complicated than that.

The way the Internet works is that you buy access from your ISP (e.g. Comcast), they in turn (perhaps through some number of additional intermediaries) buy access to the Internet’s core backbone from a Tier 1 provider (like Level 3). If you were a big enough network, you could “peer” without paying anything (since there was no particular reason for one network to pay the other or vice versa so long as they exchange roughly the same amount of traffic in both directions). The way it worked in the Old Days was that content providers (like Netflix) would always be uploading more than they download, so the rule of thumb became that if you upload too much data without downloading, you can’t peer for free. This rule of thumb existed to distinguish content providers from ISPs and make them pay. It is unheard of for a backbone provider to pay an ISP. ISPs like Comcast always used to have approximately symmetrical load to their uplink providers: their customers would download more than they upload, which means they would have “surplus” upload bandwidth “for free” which they could sell to local content providers. Selling to content providers like this is efficient because otherwise the surplus upload bandwidth is lost (“use it or lose it”).

Some of these content providers in modern times turned into content delivery networks (CDNs) like Akamai. The CDNs kind of messed with the model. Instead of buying Comcast’s surplus upload bandwidth to the backbone, they connected to Comcast’s network directly to serve content only to Comcast’s customers. In other words, they evened out Comcast’s uplink to Level 3 not by increasing upload traffic as was the traditional model, but by decreasing download traffic from the backbone. This still works.

So now what’s happening with Level 3? Netflix is moving from Akamai to a data center operated by Level 3 which is only connected to Comcast through Level 3′s backbone. What this does from Comcast’s perspective is both deprive them of the money Akamai was paying them and give them a huge amount of “free” upload bandwidth. What Comcast is then supposed to do is shop this surplus bandwidth around to content providers; or, sell Comcast Business customers higher upload rates (or just about anything else) They’re supposed to sell it, because they can sell it most efficiently; there is a pipe going into Comcast which is only full in one direction and the only way to fill it is to put something which uploads a lot on the Comcast side.

Comcast apparently doesn’t want to do that. I can really only think of two possible reasons for this. First, there is so much upload bandwidth that no one would possibly want to buy it. I find this to be pretty unfathomable. Supply and demand says that if the price is right, someone will pay. Second, Comcast is double-dipping and trying to sell access to their customers as a scarce resource; in other words they’re trying to force Level 3 to pay more for the bandwidth than it would sell for on the open market, because buying it from Comcast is the only way to get access to Comcast’s customers. Comcast has a monopoly on its customers (who already pay them, mind you).

As for Cogent, they were sending traffic over Level 3′s network to third party networks. That is, they weren’t delivering traffic to Level 3 customers, they were delivering content to people Level 3 isn’t getting paid by, while not paying Level 3 themselves. So Cogent was making money, and Level 3 was losing money. In Comcast’s case, Level 3 is delivering content to Comcast customers, who are paying Comcast for that content.

Level 3 has no monopoly on access to third party networks; there are other backbone providers. Comcast has a monopoly over access to Comcast customers. This is the main difference.

Why You Should Care

The people that are calling this a net neutrality issue aren’t far off: Comcast isn’t filtering based on content; it’s actually much worse than that: Comcast is charging content providers in order to allow them to send their content to Comcast’s customers. This is absurd. If this is allowed to continue (which all of the ISPs are hoping for judging by Time Warner’s recent endorsement of the Comcast/Level 3 deal) then you’ll only be able to get Netflix from Sprint, and you’ll only be able to get Hulu on Comcast, and you’ll only be able to get to YouTube from, well, whomever YouTube decides to pay. Because ISPs are so large they have the only pipe leading to tens of millions of people and they’ve decided they should be able to charge the rest of the world to send those people the content those people want to see, which is in fact the very reason those people pay those ISPs to begin with.

So Why Pay Comcast?

Level 3 is alleging they agreed to the deal under duress, and are complaining about it now because now is the only time they reasonably could. If they had said “suck it” and disconnected from Comcast, any traffic that Level 3 needs to send to Comcast customers (namely Netflix, which they have a contracted obligation to do) would have to be transmitted over one of Level 3′s peers, and then routed to Comcast.

Ignore that Comcast would march over to the new peer and demand the same thing they’ve demanded from Level 3. Ignore that Level 3 would undoubtedly have to pay quite a bit of money to this peer to transmit their Netflix traffic to Comcast’s customers. Doing this would seriously degrade the quality of the video Level 3 is transmitting because now it has to take (at minimum) one more step between Level 3 and the customers that are paying both Comcast and Netflix for high quality video. You can bet that Comcast knew they couldn’t say “blow us” without violating their contract with Netflix.

Not-A-Car Analogy

Say you rent a DSL line from the telephone company, but (because you’re currently free to do so) you use an ISP that is not the telephone company. You’re assigned a bandwidth of 1000Kbps downstream and 256Kbps upstream. You download 200GiB per month, and you upload 50GiB per month from the ISP (which doesn’t own your line). In this case, your ISP is sending your line far more traffic than you’re sending back to their lines. Under Comcast’s new logic, the ISP should be paying you in this situation. You own the line, it costs you money for them to send data to you (never mind you’ve requested it, just like Comcast’s customers), and it’s not balanced because you’re not costing them the same amount.

Does this make any sense at all to any sane person? Of course it doesn’t. The ISP would laugh your invoice all the way to the trash.

Until recently, pharmacologists did not fully understand APAP’s mechanism. That is, exactly how does it relieve pain and reduce fevers? Considering the only other non-opioid analgesics consist entirely of the non-steriodal anti-inflammatory drugs (NSAIDs) such as ibuprofen and naproxen, APAP’s mechanism was assumed to be a similar one. NSAIDs work by inhibiting enzymes called cyclooxygenase (COX) which produce chemical messengers called prostiglandins which set off inflammation and pain. While NSAIDs markedly reduce inflammation, there is almost little to no inflammation reduction with APAP usage. Why is this?

There are two varieties of cyclooxygenase: COX-1 and COX-2. Most NSAIDs inhibit both of these types equally. COX-1 inhibition has the unwanted side-effect of reducing protective liners in the stomach which can lead to gastric bleeding (indeed, the number one problem with NSAID use). However, inhibition of COX-2 does not produce this effect. Due to this, a number of drugs were developed that selectively inhibit COX-2 while leaving COX-1 alone, and these drugs were called “COX-2 inhibitors” with drug name suffixes of “coxib,” for “COX inhibitor.” Examples of such drugs include valdecoxib, rofecoxib, and celecoxib. A number of these drugs were developed and were very well-regarded by pain management physicians and chronic pain patients alike for their excellent ability to lower pain and inflammation without marked side-effects and even alleviated the need for opioid use (or at least reduced it). Unfortunately some of these drugs were abruptly removed from the United States market and, aside from celecoxib, no new COX-2 inhibitors have been approved or remain on the US market.

So where am I going with this? As APAP’s mechanism becomes more clear, recent findings have suggested that APAP is strongly selective of COX-2 (so much for the need to remove them from the market). So while APAP does indeed inhibit COX like the NSAIDs, there is strong evidence that APAP works through at least two pathways. The first one is well-researched and well-understood (COX inhibition), and the second pathway is what we’re interested in. So what exactly is going on here?

Recent research suggests that APAP may earn its analgesic and antipyretic properties by indirectly activating the endogenous cannabinoid system. The same way that opioids activate our own natural pain-relief system that endorphins and other natural ligands use, the body also has a natural cannaboinoid system which is responsible for the effects of tetrahydrocannabinol, or THC, which is the main active ingredient found in marijuana. Just like morphine binds to opioid receptors (mu, kappa, delta, and others), drugs like marijuana bind to the cannabinoid receptors CB1 and CB2. A well-known natural opioid is endorphin. There are also natural cannabinoids, and the one floating around our brains is called anandamide. The entire purpose of the endogenous cannabinoid system has yet to be fully elucidated, but we will explore some of the regulatory functions they serve below.

When you take APAP, it is metabolized by the body into a number of different chemicals. Some are active, some are inactive. One particular metabolite is taken in by an enzyme in the body called fatty acid amide hydrolase (or FAAH), which converts it into a metabolite called AM404. AM404 is versatile. It’s effect is as an analgesic and an antipyretic (sound familiar?). AM404 inhibits FAAH, which also metabolizes anandamide (the natural cannabinoid). The net effect is that anandamide uptake is inhibited, and levels of anandamide in the brain increase. AM404 also directly inhibits the formation of COX-1, COX-2, and prostaglandins (sound even more familiar?). AM404 also activates a receptor called TRPV1, which is also where the substance capsaicin (the substance that makes hot peppers hot) binds. TRPV1 is responsible for pain transmission and thermoregulatory actions. When activated, TRPV1 enhances and modulates pain transmission, and also tells the body to cool itself down. However, when TRPV1 is bound to for long periods of time it “shuts down,” preventing it from functioning, thus reducing pain.

So let’s take a step back. We’ve got a lot of things going on. Thanks to AM404–which is introduced by acetaminophen–we have the following things going on:

1. AM404 inhibits FAAH–which metabolizes anandamide–resulting in an increase of anadamide.
2. Anadamide binds to cannabinoid CB1 and CB2, and also activates the TRPV1 receptor. Each of these actions are known to inhibit pain on their own.
3. AM404 also activates the TRPV1 receptor.
4. AM404 also inhibits cyclooxygenase and prostagladins.

All of these processes are working to reduce pain (and fever). So, what does this really matter? By investigating these processes we can create novel analgesic drugs that aim to inhibit FAAH in the same way AM404 does (APAP’s use itself is limited due to its toxicity at higher doses) and giving rise to this exact process. We can also make drugs to target TRPV1, and in fact there are already several in advanced testing phases (both agonists and antagonists are being explored, but I’d personally be interested in a partial agonist–can we activate and overload it without causing the burning sensations?).

Let’s remember, this started by looking closely at the metabolism and mechanism of a drug almost everyone worldwide knows of and has made use of: acetaminophen. First we found out that APAP is most likely a highly selective COX-2 inhibitor, and so that trash about taking Bextra and Vioxx off the market was just that: trash. More importantly–if you’ve managed to follow along–you’ve almost certainly deduced that because acetaminophen introduces AM404, and AM404 causes activations in the endocannabinoid system, and in this fashion acetaminophen acts as a pro-drug for a cannabimimetic metabolite (AM404 itself), this means that Tylenol and Panadol and hugely popular drugs containing acetaminophen are activating the endocannabinoid system–like marijuana–in order to produce it’s primary effect of analgesia. Tylenol’s pain-relieving action involves activation of the endogenous cannabinoid system.

And marijuana is illegal?

According to various medical texts, the brain is not designed to be in pain for a long period of time. In fact, the nervous system in general is not designed to send “pain signals” for very long at all. As such, when chronic pain happens often times the neurons that send these signals “learn” to get better at sending them, in the way that your brain learns for memories. A common myth is that people exposed to pain frequently have a higher “pain tolerance,” when in fact the opposite is true. The more often you’re exposed to pain, the more adept your nervous system becomes at sending pain signals. If the same neurons send the same signals for long enough, something called neuronal plasticity happens: in laymen’s terms, those neurons physically change themselves to permanently transmit pain. There is no definitive way to tell when something like this has happened to someone, but it’s a good bet that when all interventional procedures such as disconnecting the nerves themselves (rhizotomy) still fail to provide pain relief, you have this situation. This is bad. There is no way to reverse this process. Your body is now in constant pain. In medical terminology:

Under persistent activation nociceptive transmission to the dorsal horn may induce a wind up phenomenon. This induces pathological changes that lower the threshold for pain signals to be transmitted. In addition it may generate nonnociceptive nerve fibers to respond to pain signals. Nonnociceptive nerve fibers may also be able to generate and transmit pain signals. In chronic pain this process is difficult to reverse or eradicate once established.

Being in constant pain is not only–you know, painful–but it also wreaks havoc on your body. People with high-intensity chronic pain have significantly reduced ability to perform attention-demanding tasks. Pain appears to strongly capture the attention of people with chronic pain; tests assessing the ability to attend show poorer performance than pain-free people on all tests demanding attention. The exception is found with tasks that are highly demanding of attention, where performance between the two groups is equivalent. In experimental testing, two-thirds of individuals with chronic pain demonstrate clinically significant impairment of attention independent of age, education, medication and sleep disruption. Individuals with the highest levels of pain showed greatest disruption of memory traces, suggesting that pain diminishes working memory.

Now that I’ve gotten some of that out of the way, I have another story about physical medication side effects. Last week I was at work. I work some two hours from my home. Right before leaving, I went to use the bathroom but found it difficult to urinate. I didn’t really give this much thought because I’ve had a “shy bladder” for close to a decade. It’s always been stressful and difficult for me to give urine samples for job applications or other reasons. I left work and when I got home a few hours later, I was still unable to urinate. This worried me. Since I usually get home late I tried a few more times and went to bed. When I got up in the morning and got to work I found myself still unable to urinate. At this point I was still leaning toward a shy bladder and figured that if I drank enough I could sort of force it out. This is the technique I use to give urine samples. A few hours later I was very much surprised to find that this didn’t work.

After consuming a large amount of fluids I felt as if my bladder were going to burst and I was in quite a large amount of pain and discomfort. I immediately ran to the bathroom where I was still totally unable to urinate. I realized at this point I had an emergency condition on my hands and tried to convince my carpool to start heading home immediately. By the time they had gathered their things I realized there was no way I was going to make it two hours back home, and decided to run to the hospital across the street from work.

Upon walking into the ER I told the triage nurse I hadn’t urinated for 22 hours and I was in severe discomfort. After a quick sign in with a list of medications and allergies I was rushed off to a room where she quickly (and not as horrifyingly painfully as last time) inserted a Foley catheter where she promptly drained close to 950mL of urine (a normal liquor bottle is 750mL). I felt much better. After a discussion with the physician about the possible causes he was leaning toward my pain medication, as opioids are a frequent cause (but individually rare (less than 10%) side effect) of urinary retention. After a urine analysis (I didn’t have trouble giving a sample this time–it came out of a tube), blood work, and a couple of non-contrast abdominal and pelvic CT scans all came back normal I was told the most likely culprit was the “vast amount of narcotic medications” and advised it would be best the catheter stayed in a few days. I was not entirely happy with that verdict. As I limped out of the ER (and when you’re a male with a tube up your penis, you limp) I was picked up by my carpool and taken home. After a few days of being told my PCP wouldn’t take out a catheter in the office and to go to the ER I realized I could either spend five hours at the bottom of the ER triage or I could take it out myself. I cut the injection port and let the balloon deflate and gently removed it without issue. Within a few hours (and since) I have been urinating just fine.

This story is obviously personal and represents a few things. The physician determined my situation was a side effect of my pain medication and so informed me in such a way as to say “maybe you shouldn’t be taking those medications.” Well, doc, I’d love to not take these medications but without them I can’t function due to Intractable Pain. Maybe if I was on Disability or some other form of I-don’t-work income I could try it and see what happens, but I have a job and a family to support with that job. So firstly it represents bias against people on pain medications, once again. This is a psychological (or maybe even social) side effect of pain medications. Friends and family may shy away from you because you’re on “narcotics” or worse, assume you’re an addict because you’re dependent. I’ve written extensively on how these differ, but the laypeople just fail to understand. There have even been episodes of Intervention-style shows on television wherein a chronic pain patient was accused by a weeping family of abusing their medications and being an addict. A lot of times on these shows it’s true: they’re quite obviously addicts; however, more than once I’ve seen a pain patient taking their medications as prescribed and enduring their side effects only to have this taken as “addiction.” What’s worse is that I’ve seen these legitimate patients forced into rehab more than once because of a bias against medication.

We are sick people. We are sick people with a serious disease. We have pain that’s caused by a disease or is a disease in and of itself. We take medication for that disease, and we withstand the side effects of both that medication and that disease. My only problem is that some of those side effects are man-made, and in a reasonable and educated world should be put to rest. Educate yourselves.

Some time ago, it was noticed that NMDA receptor antagonists (dissociative anesthetics) like ketamine, phencyclidine, and dextromethorphan have the side-effect of reducing the amount of tolerance formed to opioid analgesics. This has far-reaching implications because if you can mediate opioid tolerance, you can control the amount of opioid needed for pain relief.

The NMDA receptor both induces and maintains persistent enhancements of the excitability of neurons to prolonged stimulation, or “wind-up.” Wind-up is a key spinal mechanism requiring activation of the NMDA receptor that both amplifies and prolongs certain types of pain. As a result, wind-up may be one of the events underlying prolonged or chronic pain. Evidence from animal studies indicates that this mechanism is involved in the induction and maintenance of certain types of pain, most notably inflammatory and neuropathic.

Neuropathic pains are at least partly mediated by the NMDA receptor, which may relate to changes in opioid sensitivity. All opioids reduce, or with high doses block the input that causes certain types of pain, probably via activation of the presynaptic opioid receptors to prevent the release of primary afferent transmitters and so prevent pain input from actually activating the neurons that make you feel pain. However, if the pain continues, wind-up overcomes the inhibitions of input and the neurons commence firing, causing pain. As wind-up increases the activity of neurons, a higher dose of opioid will be required to block the increased excitability. Thus, at moderate doses, opioids delay wind-up without inhibiting the process itself. In contrast, NMDA antagonists abolish wind-up. Thus, threshold doses of morphine combined with low doses of NMDA antagonists are able to elicit dramatic inhibitory effects, a synergism that suggests low probability of side effects. Importantly, in a model of neuropathic pain where morphine is inoperative, the co-application of an NMDA antagonist restored the ability of morphine to inhibit the response.

All that medical speak translates to this: the pain input that’s prolonged and intensified by NMDA receptors can be delayed by opioids, but not inhibited. However, NMDA antagonists (mentioned above) completely turn off the prolongation and intensification, allowing opioids to take away that pain. Basically stated, it amounts to the aforementioned. Adding a mild NMDA receptor antagonist (in extremely sub-anesthetic doses) to an opioid enhances the effects of the opioid, allowing smaller amounts of opioid, and thus fewer side-effects.

At least there’s one good use for dextromethorphan.