If the log space used is 100%, you can't shrink that file because there's nothing to shrink. Are you running log backups regularly (at least once an hour depending on your load)? If not, start doing that. That will free up space within the log for committed transactions that have been transmitted to the mirror. The first couple of times you run log backups, you may not still be able to shrink because all the most recent transactions will be at the end of the log, which is where the shrink needs to come from. But after a couple of backups you should then be able to shrink. But, let's talk about the shrink. You're only doing this because the log has grown right? You're not trying to shrink it all the time are you?
What is the status of the secondary? Is your database on the primary showing synchronizing, synchronized, or suspended? I have many times seen a database that is being mirrored shift to a suspended state if something happened to the mirror for a period of time. If that happens you have to go back into mirroring and chose resume. Unless the principle and see the secondary and synch the log, the primary will keep those transactions in the log so it can play catchup. This will cause the log on the principle to keep growing and growing and growing.