Tedious issues escaping/quoting strings for MySQL? Use hex! It's awesome!

Hiya,

Ok sure yes you 'escape' all your strings for SQL (i.e. replace `'` with \' and so on for other nonprintable).

Sometimes this is unsuitable.

Did you know you can avoid all that palarva and just pass your strings as hex?

Check it out!

For a varchar (or blob, or whatev) column, just try instead of

insert col='blah' into mytable

=

insert col=0x626c6168 into mytable

How awesome is that? Who knew?

Also, btw, you can get mysqldump to also output blobs as hex, which makes for easier parsing - see the help output

See wikipedia during january 18th blackout

Yes, yes wikipedia, we know you're all radical and cool.

Anyway, just append

?banner=none

to the end of your URL, for example;

Look it works!

kthxbye

Obscure packetization bug in Verizon cellular HTTP proxy 'Harmony'! Does your app fail on VZW cell but work on wifi?

Wow this is a fucking bug and a half;

(On iPhone, but applies to everything)

Verizon currently appears to proxy any HTTP request over any port regardless of whether you asked for it. It adds

"X-Via: Harmony proxy"

to show how much it 'helped'. Thanks, if I wanted a proxy I'd ask for one.

It does it even on non-port 80!! FFS!

It appears that anything that says HTTP/1.1 after opening a socket on any port is fair game for fuckwittery.

And, wonderfully, Harmony Proxy has a packet reassembly bug!

The client app was (inadvertently) writing the HTTP request split into two TCP packets;

The first packet was only 22 bytes long, containing the URL

The second packet was 500 or so bytes and was the rest of the header continuing from " HTTP/1.1\r\n...etc"

Hence the very first line of the HTTP req was split into two TCP packets. This is obviously rather unusual.

The proxy freaks out at this, throws away all the HTTP headers, and just generally screws the request up (although it does send it)..

So, when using socket .send() , make sure you've buffered at least the first few lines of your headers in one go.

if your stuff works over wifi, other cell networks, but not VZW, and you're using HTTP...

watch out for this. It's a bug in their proxy.

Rewriting (proxying) a TCP stream in one line

Damn unix is great...

Step 1: In a shell, set up netcat to listen on TCP 5500:
nc -l -p 5500

Step 2: In another shell/on an intermediate machine..
nc -l -p 50000 -c 'sed -u -e s/billy/freddy/g | nc localhost 5500'

Step 3: In a third shell,
nc localhost 50000

..and start typing stuff, including the word "billy"

Ok so the third shell will talk to the first shell and replace "billy" with "freddy".
Note this is bidirectional - type in first shell and it goes back to third one (without rewrite)

How handy is that? VERY!

If you need a TCP stream (e.g. gnu debugger) intercepted and rewritten slightly.. that's yer man.

Thank you beardy unix gods from 1972!

Setting Tomcat JVM heap size as a percentage of total ram

Put at start of "bin/startup.sh"

export CATALINA_OPTS="-Xmx`cat /proc/meminfo | grep MemTotal | awk '{ print $2*0.75 } '`k"


..to use 75% of your total system memory for JVM.
Add to /bin/tomcat.sh or whatev's

SSL performance of Tomcat and Apache Commons HTTP

Using latest Tomcat 6 on Java 1.6 on Centos.

1. Tomcat JSSE (standard) SSL option is much slower than the Apache Portable Runtime (APR) libaries.

SSL performance (using CURL to upload large binaries via HTTPS to localhost on a multicore box) was getting
5.3MBytes/sec using Tomcat default SSL (100% Java on one CPU), and getting >30MBytes/sec using Tomcat with APR (basically OpenSSL) and lower CPU usage.

Conclusion: Well worth the hassle installing APR for incoming (and probably outgoing) e.g. 5x faster SSL traffic, lower less Java CPU.

2. Beware using standard libraries to upload to Rackspace Files and other HTTPS-accessed key:value stores. Using Apache Commons HTTP Uploader tops out at about 2mbytes/sec on one machine compared to 5mbytes/sec using CURL or WGET from command line. This was very repeatable.

3. Speed writing from Rackspace Cloud Server to Rackspace Files using CURL (i.e. running flat-out)
(See that the different CLoud Server options have different bandwidth clamps as well as significantly faster CPU)
Uploading a 176MB object to Rackspace Files, using CURL from command line to do a PUT
"512MB machine" : 5.02MBytes/sec (very reliably - this is clamped by network)
"1GB machine" : 7.65MBytes/sec (again network bound, more expensive server)
"16GB machine" : 15MBytes/sec
CPU in these cases (for Curl) is <10% typically.
In all cases running two threads (these are multicore machines) gets exactly half the performance, indicating networtj throttle.

HOWEVER if you don't use OpenSSL for your HTTPS....

Using Apache HTTP Uploader (and most likely any 'pure'-Java SSL options that are using JSSE) only gets
"512MB machine" : 2.1MBytes/sec (this is 100% CPU on that java thread)

Conclusion:
...creating outbound HTTPS connections using Java SSL gets CPU-bound really quickly - watch for this when using JSSE-based Java SSL clients.

Read facebook images in flash

var loaderContext:LoaderContext;
loaderContext= new LoaderContext();
loaderContext.securityDomain=SecurityDomain.currentDomain;
loaderContext.checkPolicyFile = true;

then pass that as the context parameter to load()

If you're using the excellent "BulkLoader" pass it as "context" param