No data under windows server 2016 / citrix

[blackfoxoh]

Hi
we have a device which is sending repeatingly a textstring on COM-Port. We wanted to switch to purejavacomm as an easy replacement for original sun comm-api which doesn't support 64bit JVM on windows.
It works on Win7 x64, it works on Win10 x64 but we don't get it to work with the following environment: Windows Server 2016, served to the client-device by a citrix session having the COM-Port from the device mapped to citrix-session - I call this just "citrix" further on.
In this citrix-session the old configuration (32bit JVM with sun comm api) works fine. The only thing which doesn't work is the combination of "citrix" with x64 JVM and purejavacomm.

following is how we use the COMM-API:

serialPort = (SerialPort) portId.open(appname, timeoutForPortOpen);
serialPort.setSerialPortParams(9600, SerialPort.DATABITS_7, SerialPort.STOPBITS_1, SerialPort.PARITY_EVEN); 
serialPort.addEventListener(this);
serialPort.notifyOnDataAvailable(true);
BufferedReader in = new BufferedReader(new InputStreamReader(serialPort.getInputStream())); 

and then we work with the serialportevents:

   public void serialEvent(SerialPortEvent event) {
      if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) {
          String line = in.readLine();
          // work with the String read..
      }
   }

I've tried to debug the problem but didn't came to a final conclusion... The "run()"-method defined in the constructor of PureJavaSerialPort is getting executed regularly but the value for "boolean read" evaluates to false as m_DataAvailableNotified is true (line 1182).
When I debug I've seen that the read()-method inside PureJavaSerialPort.getInputStream() is getting executed several times until the first line is read - but never afterwards. This meens when debugging I am able to receive the value from com-port once but then never again. Without debugging even the first time there is no value read - weired....
This beeing said I guess this might have to do with a timing issue?!? But I have no clue how to solve this.
Can anybody help or advice how to dig down further?

regards
Ralf

[nyholku]

My first idea is to eliminate Citrix from the equation, try to run this without Citrix so that you know if the problem persists or is related to Citrix. In my limited experience and based on rumours/hearsay from co-workers Citrix can be a lot of problems when it comes to peripherals.

[blackfoxoh]

thank you for the fast response. This is what we already tryed to do (but sorry, I didn't point this out clearly):

• works on windows 10 (which should be the same codebase as windows server 2016 according to our admins - no chance to connect the COM device directly to server 2016).
• the COM-Port itself works within citrix when using the old 32bit JVM and the original sun implementation of the COM API. The problem is we need to migrate to 64Bit JVM and therefore have to switch the COM-API...

[nyholku]

So PJC works on Windows 10 with 64bit JVM?

"which should be the same codebase as windows server 2016 according to our admins - no chance to connect the COM device directly to server 2016)."

Well, 'should' is not same as 'is' and codebase is a loose description, either the code is the same or not so saying 'codebase should be the same' sounds like some critical detail can be different. I infer that you cannot physically access the server, but what you could do is that you could install the same Windows server in local machine and try it there.

Just a thought.

[blackfoxoh]

according to my first test: yes, windows 10 with 64bit JVM works. In a second test there was something a little strange.

Finally I didn't see a chance to get this working with a current project-deadline coming up. I therefore switched to a RXTX-fork which provided a 64bit dll and voila - it worked out of the box like a charm.
I'd liked the fact to not having to deal with extra native code but that isn't a real problem in our usecase. None the less, thank you for your efforts in providing PJC and in trying to help me with this problem.

As a conclusion this means there might be a bug in PJC regarding this context but so far I can't tell you where exactly the problem is. I therefore leave it to you if you want to close this issue or keep it open.