Socket timeout between application-server & VistALink

[Wasim]

Dears,

I got an error in the connection between the Tomcat & VistALink reading & writing data.

it is a socket timeout issue, i found that the default value for the socket timeout is 5000 ms, which equals to 5 seconds,
How i can change the socket-timeout value??

after tracing the source-code of vljFoundation library, i found the below:

in class VistaLinkManagedConnection

 /**
     * The time out value used (in milliseconds) when performing socket reads
     */
    private long socketTimeOut = 5000;


and, in class VistaLinkManagedConnectionFactory

/**
     * constant for socket timeout used for J2EE
     */
    private static final long J2EE_DEFAULT_SOCKET_TIMEOUT = 5000;


My question is:
Where is the place that i can modify to change the default value of socketTimeOut?


Regards,
Wasim

[Solomon Blaz]

Hi Wasim,

Had to dig a bit to figure out how best to do this...

I think you might be able to set this on the instances of VistaLinkManagedConnectionFactory using its setDefaultJ2EETimeOut() property - I believe the value is in milliseconds.

If you are using the VistaLinkConnectorConfigConnectionFactoryLocator in your vistalink-config.xml, then the relevant section is in the createManagedConnectionFactoryBeanDefinition() method, lines 44-52.  I think you could add something like:

managedConnectionFactoryBeanDefBuilder.addPropertyValue(“defaultJ2EETimeOut”, 30000);

in there and get it to work...

...or if you were feeling extra ambitious, you could add a default timeout property to the VistaLinkConnectorConfig  class and then use the value passed in so that it could ride along with the rest of the configuration info for each VistaLink Connector...

If you need to set a different timeout for each individual RPC call using VistaLink, I’d have to dig a bit more to see if that’s possible.

Hope that helps a bit,

Solomon

--
You received this message because you are subscribed to the Google Groups "VistA Emergency Room" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vista-emergency-...@googlegroups.com.
To post to this group, send email to vista-emer...@googlegroups.com.
Visit this group at http://groups.google.com/group/vista-emergency-room.
For more options, visit https://groups.google.com/groups/opt_out.

[Nancy Anthracite]

Thanks a bunch, Solomon! Joel Ivey had been trying to help me find the
VistALink experts in the VA and so far nobody has come up with an answer. I
figured you knew the EDIS code but the VistALink code was another matter, but
I should have known better. :-)

Wasim, let us know if that works.

--
Nancy Anthracite

[Wasim Naffar]

Hello Solomon,

i did exactly like what you mentioned above,

added this line under method createManagedConnectionFactoryBeanDefinition,

managedConnectionFactoryBeanDefBuilder.addPropertyValue(“defaultJ2EETimeOut”, 30000);

and after i published i got this error:

Method must not be null / Failed to convert property value of type [integer] to required type [long] for property 'defaultJ2EETimeOut'

does i need to add a setter method for this property anywhere else!! advice please,

[Wasim Naffar]

here is more error details

Name	Description
org.springframework.security.BadCredentialsException :	couldn't log in
nested exception is org.springframework.dao.DataAccessResourceFailureException :	Unable to obtain connection factory for station '100PHH'
nested exception is org.springframework.beans.factory.BeanCreationException :	Error creating bean with name 'vljConnector100PHH' Cannot resolve reference to bean 'vljManagedConnectionFactory100PHH' while setting bean property 'managedConnectionFactory'
nested exception is org.springframework.beans.factory.BeanCreationException :	Error creating bean with name 'vljManagedConnectionFactory100PHH' Initialization of bean failed
nested exception is org.springframework.beans.TypeMismatchException :	Failed to convert property value of type [java.lang.Integer] to required type [long] for property 'defaultJ2EETimeOut'
nested exception is java.lang.IllegalArgumentException :

Method must not be null

[Wasim Naffar]

here are more error details:

Name	Description
org.springframework.security.BadCredentialsException :	couldn't log in
nested exception is org.springframework.dao.DataAccessResourceFailureException :	Unable to obtain connection factory for station '100PHH'
nested exception is org.springframework.beans.factory.BeanCreationException :	Error creating bean with name 'vljConnector100PHH' Cannot resolve reference to bean 'vljManagedConnectionFactory100PHH' while setting bean property 'managedConnectionFactory'
nested exception is org.springframework.beans.factory.BeanCreationException :	Error creating bean with name 'vljManagedConnectionFactory100PHH' Initialization of bean failed

nested exception is org.springframework.beans.TypeMismatchException :	Failed to convert property value of type [java.lang.Integer] to required type [long] for property 'defaultJ2EETimeOut'
nested exception is java.lang.IllegalArgumentException :

Method must not be null

On Tue, Dec 31, 2013 at 2:16 PM, Wasim Naffar <w0795...@gmail.com> wrote:

[Solomon Blaz]

Oops, sorry I didn’t notice it was a ‘long’ instead of an ‘int’.  The java compiler will treat the symbol 30000 as an int by default, to give it a hint to treat it as a long, try:

managedConnectionFactoryBeanDefBuilder.addPropertyValue(“defaultJ2EETimeOut”, 30000L);

[Solomon Blaz]

Well, a VistALink expert I am not, I’ve just been following Ben Kenobi’s advice to “Use the Source”… :)

As far as I can tell, VistALink is what the open source community would call a “dead” project - it is not being actively maintained or developed. Combine that with several serious technical limitations and that is why our current project is using good old RPC broker for VistA communication instead of VistALink.

Cheers,
Solomon

[Sam Habiel]

Soloman,

I am rather surprised to hear about "serious technical limitations" in
VistALink. I would have said that of the broker too. Can you
elaborate?

Sam, a journeyman VISTA programmer

[Solomon Blaz]

Sam,

It’s been years since we did the analysis and report, and my memory is failing me, but it basically boiled down to VistALink not being able to do what we needed it to do to support features of CPRS…

Um, off the top of my head: it targeted WebLogic instead of being portable - the dependency on JCA made it difficult to use outside of heavyweight JEE containers - there were a lack of RPC logging/debugging tools on the VistA side - we couldn’t change verify codes when they expired - we couldn’t implement CCOW integration to get single sign-on with CPRS - the use of the station number as a unique identifier for a VistA instance caused confusion and configuration difficulties between test and production environments - and the use of the new listener port similarly created lots of configuration confusion for IRM staff used to the broker listeners - maintenance of the connector credentials for a nationally deployed application like EDIS (that’s ~120 VistA instances or something) was a combinatorial explosion and a diffusion of responsibility problem amongst support staff for repairing failing connectors when access/verify codes expired, etc etc.

I guess some of these are practical limitations rather than technical ones, but our experience has generally been that the field “gets” the broker configuration stuff a lot more than the VistALink stuff and so implementation is significantly smoother because the broker listeners are already up and running due to CPRS using them. These things would be possible to address, of course, if VistALink development hadn’t effectively stopped.

My dream for the future would be to move away from RPCs altogether and have web services (RESTful or otherwise) be the primary communication channel with VistA (assuming its not Intersystems dependent)… VistA as a first class player in web service land would open up a lot of system integration possibilities, IMHO. I believe WorldVistA has done some work in this area, yes? ;)

Anyhoo, cheers, Happy New Year,
Solomon

[Sam Habiel]

"I believe WorldVistA has done some work in this area, yes? ;)"

I am not sure of the provenance of the wink, but did you see this presentation:
https://thebes.smh101.com/filesystem/misc/M-Web-Server.pdf

and this white paper...
https://github.com/shabiel/M-Web-Server/blob/master/M-Restful-Services-White-Paper.pdf

It's my pet project. I will be finishing today hopefully the automated
installer for it. It's public so you are free to download it at any
time.

Would you mind if I take what you say about VistALink and put it up
somewhere with no attribution so that it won't come back to you? There
are a lot of people in the T4 contractor world who think the world of
VistaLink, when it's really not that good.

Sam

[Wasim Naffar]

Actually the problem isn't in converting, the problem is in the setter method of setDefaultJ2EETimeOut, as i mentioned above.

this method classifies as protected instead of public in VistaLinkManagedConnectionFactory class.
so, i changed it to be as public and the problem has gone ;)

this change is in the vljConnector-1.5.0.026.jar, i have the full source code for this jar, but i got this compilation error, because i don't have the library "gov.va.med.hds.cd.ccow"
import gov.va.med.hds.cd.ccow.ContextItemNameFactory;
import gov.va.med.hds.cd.ccow.IClinicalContextBroker;
import gov.va.med.hds.cd.ccow.IContextItemName;
import gov.va.med.hds.cd.ccow.IContextModule;
import gov.va.med.hds.cd.ccow.internal.ContextModule;

do you have any idea, where i can get this lib??

thanks in advance Solomon

[Nancy Anthracite]

Congrats to all of you for great sleuthing.

Bad news is CCOW for the VA is a very expensive application that nobody can
possibly afford. I don't know if the library is proprietary. I can put in a
FOIA request to see if we can get it, but if you can do it, you should
probably bypass it.

--
Nancy Anthracite

> >> setDefaultJ2EETimeOut()property - I believe the value is in

[Solomon Blaz]

oh, whoops, good one Wasim! public/protected would do it, yeah! :)

Yeah, CCOW is an HL7 standard for sharing context between desktop(and awkwardly, web) applications - the implementation of the standard the VA uses is a product (now owned by Caradigm) and is, as Nancy says, very expensive… Its also suspiciously difficult to find out about the Caradigm product and is smelling somewhat dead - I think the last activity on the HL7 CCOW committee was 10 years ago or so. Anyway, that’s neither here nor there.

I didn’t realize the VistALink connector JARs had CCOW code in them - I’d see what happens if you yank the whole gov.va.med.hds.cd.ccow package - there shouldn’t be anything in there you need in order to just call RPCs.

[Solomon Blaz]

Sam,

I was winking at WorldVistA generally and didn’t know you had a pet on the thread. Cool! :)

Yeah, sure you can share about VistALink, as long as I’m not being quoted directly. :) Kevin's written all this up in some document in the VA somewhere.

Don’t get me wrong, VistALink was a decent first shot at doing RPC calls from java, esp. for its time, and it does actually let you do that (with a bit of hassle), and there were some positive changes to Kernel to do n-tier applications, and I can see how there might be contractors out there without the practical experience with it who would think its good enough. One can certainly build prototypes with it. It needs some TLC if its expected to be a foundational piece of national framework, though. No longer under active development, unfortunately.

Thanks for the interesting stuff re web services - I’ll check it out if I can find some spare cycles.

Cheers,
Solomon

[Wasim Naffar]

Solomon really, I appreciate all your efforts and help.

Actually i got this compilation error in the following class
gov.va.med.vistalink.security.CallbackHandlerSwingCCOW, and this exist in the vlj-1.5.0.026 source code.
you are right Solomon;) this is not part of VistALink connector JAR,  i see this class is embedded in vljSecurity-1.5.0.026 jar not vljConnector jar. many thanks again.

currently, my changes will be in these modules:
1- tracking-server-vista,

specifically in
gov.va.med.edp.vistalink.locator package (VistaLinkConnectorConfig & VistaLinkConnectorConfigConnectionFactoryLocator classes)

2- vljConnector

specifically in
gov.va.med.vistalink.adapter.spi package (VistaLinkManagedConnectionFactory class)

Cheers,