Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Reverse proxy not working with 1.0.3 #1

abijoshi opened this Issue May 15, 2012 · 13 comments


None yet
2 participants

On host machine HM which is in DMZ network, i fired below command:
PortFusion ] 1080 [

I want to access Port 8000 of machine M1, on M i fired below command:
PortFusion.exe 8000 M - 1080 HM [ 5010

Now when i try to access http://HM>:5010 its not working. please help me out here.

In older release i.e. 0.9.3, it works with following commands:
on HM:
PortFusionHost.exe 1080

on M:
PortFusionClient.exe 1080 HM 5010=localhost:8000


cetinsert commented May 15, 2012

o__O oh I could reproduce the problem on my own on Windows ... ok I am taking a look and hope to fix it within the next couple of hours.


cetinsert commented May 15, 2012

killThread on

killThread =<< takeMVar t -- disable patience checks
blocks on Windows on a foreign function call.


cetinsert commented May 15, 2012

The problem was already described here: http://stackoverflow.com/questions/6185189/howto-kill-a-thread-in-haskell . Seems to mainly affect Windows.

so you need to fix something or it will not work at all?


cetinsert commented May 15, 2012

^__^" Sorry for not making it clear: I am already working on a fix and of course I will fix all bugs people report!

I am busy upgrading my windows build environment at the moment and I hope to send you new Windows binaries within 3 hours.

I will then develop a test environment for all operating systems to help catch such issues before they reach users in the future.


cetinsert commented May 15, 2012

Could you please try : http://portfusion.sf.net/z/PortFusion.zip and tell me if it works for you?

@ghost ghost assigned cetinsert May 15, 2012

Thanks a lot. Its working fine now and also Issue 2 is not re-producable with this.

When it will be available for download for all as i consider this as showstopper?


cetinsert commented May 15, 2012

@abijoshi please do know the zip I sent is not a complete fix! You are right about it being a showstopper on Windows and I hope to finalize a complete fix by tomorrow afternoon and make a Windows only new release.

I am happy to hear the prototype helpes solve both issues though :)


cetinsert commented May 15, 2012

After I rewrote (-✖-), I run into a new issue with (!<@) on

c <- (r !<@) -- wait for connection
blocks exceptions thrown from the new (-✖-).

I posted a question on stackoverflow: http://stackoverflow.com/questions/10608602/can-a-haskell-or-haskell-os-thread-waiting-on-network-socket-accept-not-be-kille and discovered a quick fix.

With the two sides of (|<>|) now able to kill each other equally well on Windows as on all other operating systems, I consider the issue technically fixed.

Source code updates and new Windows binaries will be made available tomorrow by noon.
Linux, Mac OS X and FreeBSD remain unaffected and no new binaries will be made for these three.


cetinsert commented May 16, 2012

Ok here is the final fix I have just uploaded: http://portfusion.sf.net/z/PortFusion2.zip

Could you please test and confirm it as working?

I will make a new Windows binary release as soon as I hear from you.

CORSIS PortFusion    ( ]-[ayabusa 1.0.4 )
(c) 2012 Cetin Sert. All rights reserved.

Windows - x86 [Wed May 16 02:02:18 2012]

has same version but different date from the first link.

The entire issue can be summed up as GHC/Haskell on Windows being quite unique in terms of interruptibility of most socket operations.

What hit us pretty bad was System.IO.hGetBufSome and Network.Socket.accept:

If you have any suggestions concerning how to indicate by version numbers or release name that 1.0.3 required a fix on only Windows and a fix is released without alerting users on other operating systems, I am more than all ears listening!

Hi cetinsert,
It's also working fine.


why not released yet?


cetinsert commented May 16, 2012

I was too sleepy to think how best to release it. I just made a release and consider this issue solved.

I am really thankful to have received your bug report!

@cetinsert cetinsert closed this May 16, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment