Re: [WDSCI-L] Active jobs timing out

[Mark Phippard <MarkP@xxxxxxxxxxxxxxx>]

Don,

Yes, I was playing with that yesterday.  Biggest problem I see currently 
is that it is not possible to set the SocketProperties with the JDBC 
driver.  I reported it on the JTOpen forum.  I think the only way it could 
be done via JDBC is if they added some new JDBC properties.

http://www-912.ibm.com/j_dir/JTOpen.nsf/2bd4742db2e03c7b862568230070dbd3/97819fa9c41abaad86256f0e00530a79?OpenDocument

My only other concern was that since I have no idea how to recreate the 
problem I do not have any way to know if setting these properties will 
make a difference.  Basically, the same problem you have. 

The more I have thought about, I wonder if this problem would only happen 
for people that have a proxy server.  That is the only TCP/IP technology I 
can think of where a 3rd party would be involved in the socket connection 
and could close it.  Normally, proxy servers have some configuration that 
allow you to specify systems or IP addresses to bypass with the proxy 
(assuming it is all on the same network).

So to Gregg or anyone else with these problems, can you help?  Do you have 
a proxy server on your network, or something else that could be involved 
in the TCP/IP connection.  Neither OS/400 nor JT400 have any settings that 
would cause it to close the connection after a period of inactivity. 
Something else must be involved at the network level.

Thanks

Mark


wdsci-l-bounces@xxxxxxxxxxxx wrote on 09/13/2004 01:59:00 PM:

> 
> 
> 
> 
> Mark,
> 
> The Toolbox's AS400 class lets you set options for the socket it uses to
> connect to the OS400 host servers:
> 
> public void setSocketProperties(SocketProperties socketProperties)
> 
> This includes a keepalive parameter and timeout parameter.  We don't
> currently set either of these in 5.1.2 but are looking into this.  I 
have
> had others report similar timeouts with the RSE but have never been able 
to
> figure out which OS/400 setting controls the timeout value in order to
> reproduce the problem and therefore know if this would solve the 
problem.
> 
> If anyone knows this value please let me know so we can fix the problem
> [and test the fix!]
> 
> Thanks.
> 
> Don Yantzi
> WebSphere Development Studio Client for iSeries
> IBM Toronto Lab
> Phone: (905) 413-4476
> IBM internal:  IBMCA(yantzi)  -  Internet: yantzi@xxxxxxxxxx
> 
> 
> 
>  
>              Mark Phippard  
>              <MarkP@softlandin  
>              g.com> To 
>              Sent by:                  Websphere Development Studio 
Client 
>              wdsci-l-bounces@m         for iSeries 
<wdsci-l@xxxxxxxxxxxx> 
>              idrange.com cc 
>  
> Subject 
>              09/10/2004 04:30          Re: [WDSCI-L] Active jobs timing  
 
>              PM                        out  
>  
>  
>              Please respond to  
>                  Websphere  
>                 Development  
>              Studio Client for  
>                   iSeries  
>  
>  
> 
> 
> 
> 
> Just a few comments, perhaps they can help or clarify.
> 
> The TurnOver jobs and the RSE jobs are not related to each other.  With
> the exception that I think we are both using JT400 as the middleware for
> the communications.  I suspect that the RSE jobs just reconnect silently
> when the connection is dropped.  As you indicated, that is also what we
> essentially plan on doing.  For us, however, it is a little more
> complicated because our jobs are interacting with the database and will
> lose their "state" when the connection drops.  RSE jobs are mostly
> stateless since they are just driving OS/400 API's.
> 
> It would be great if an IBMer on the list new what controls this 
behavior,
> but perhaps we would have better luck moving this to the JT400 forums
> since the issue is really in the middleware.
> 
> http://www-912.ibm.com/j_dir/JTOpen.nsf/By+Date?OpenView
> 
> If you run CFGTCP option 3, what is your value for TCP keep alive?  Mine
> is 120 minutes, the default.  Not sure if that is even a factor though.
> 
> Mark
> 
> 


_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services 
powered by MessageLabs. 
_____________________________________________________________________________