Direct ssh to a server via proxy using putty/plink on Windows

1. Make sure seamless ssh keys are setup to your bastion server for your username
1. Not covered here
2. See: http://www.ualberta.ca/CNS/RESEARCH/LinuxClusters/pka-putty.html
2. Session -> Host Name -> mytargetserver.mydomain.com
3. Connection -> Proxy
1. Proxy Type -> Local
2. Telnet command, or local proxy command 
1. c:/program files (x86)/putty/plink.exe myproxy.mydomain.com -l myusername -agent -nc %host:%port
1. adjust this path to plink.exe to match your local setup
1. hint: install the complete putty install package, not just putty
4. Tunnels
1.   L8081 mytargetserver.mydomain.com:8081

Hint: always hit "Save", no matter what you do, or however inconvenient it was designed to be.

Another example: plink -L 127.0.0.1:1433:mysqlserver.com:1433 admin@google.com -i myprivkeyfile

Taken: http://mikelococo.com/2008/01/multihop-ssh/

Confluence: Lock wait timeout exceeded; try restarting transaction

WARNING! Atlassian themselves recommend STRONGLY against this procedure. If any action, take the action that shows you which table is locking, DO NOT DELETE anything unless you are 100% confident you can reverse your deletions. DO NOT DELETE, DO NOT DELETE!

Seeing this?

2013-05-14 16:39:55,581 ERROR [QuartzScheduler_Worker-1] [sf.hibernate.util.JDBCExceptionReporter] logExceptions Lock wait timeout exceeded; try restarting transaction
2013-05-14 16:39:55,581 ERROR [QuartzScheduler_Worker-1] [sf.hibernate.impl.SessionImpl] execute Could not synchronize database state with session


The first is actually reported from MySQL itself, the second from Hibernate, which wraps databases for Java apps.

If you are desperate, try deleting all rows from mysql's crowd.cwd_membership table after backing it up, worked for me, syncs started working again in under 16ms.

1. mysqldump crowd | bzip2 -c > /mnt/dump_crowd_`date +%Y%m%d`.sql.bz2
2. mysql crowd -e 'delete from cwd_membership'

If that doesn't help, try deleting old users from any confluence groups that are still in your LDAP dir, be brutal. While your at it, delete old users period from LDAP.

To spot the problem table, this might help, if another table is your problem:

1. watch "mysql -e 'show processlist'"
2. Then, run LDAP sync update via admin web GUI, and watch to see which table is locking

Other things you might be seeing in your logs if you have this issue:

"batch failed falling back to individual processing java.lang.RuntimeException: could not flush session"

"Error occurred while refreshing the cache for directory"
"synchroniseCache full synchronisation for directory [ XXXX ] starting"
"could not insert: [com.atlassian.crowd.embedded.hibernate2.HibernateMembership#YYYYY]"
"Lock wait timeout exceeded; try restarting transaction"
"Could not synchronize database state with session"
"could not flush session"