TCP (layer 4) is stateful.
RPC (layer 5) is not stateful.
So long as the transport layer is ok (new session, old session, does not
matter), then the session layer will be fine.
As long as the firewall allows the creation of a new state when the Remedy
API talks back (after a state entry has expired), it should create a new
state in the firewall's state table.
I do not know that it is possible to do either of the 2 things you are
asking to do. You might be able to achieve point 2 if you disable the use
of the session pool (see the end of the email). You might try
setting connectionMaxRetries to 1 and the timeLagBetweenRetriesMillSec to
100. In the case of "connectionMaxRetries", I don't know if 0 means do not
retry or retry forever.
One thing you could do is create a rule on the firewall to not use stateful
tracking when packets originate from the MT machine and a destined to the
ARServer on a defined destination port. These types of rules are taxing
because they have to be evaluated for every packet that goes through the
firewall, but it will allow the packets to flow as needed.
You might also look at the firewall's policy on how it handles packets that
it receives that do not match a state. Does it silently drop the packets
or does it send a RST packet? If it is silently dropping the packets, I
would expect the behavior you are seeing. If it sends an RST packet, it
should tell the MT that the TCP session is not valid and it should create a
new session (the Remedy API may not work in this way though, you will have
to experiment to find out; I have not personally poked the API in this way
to find out for sure and I don't have an environment readily available to
test this scenario).
(continued from above)
arsys.xml let's you define some parameters on how the API operates:
<?xml version="1.0" encoding="UTF-8"?>
<!--
This is a sample configuration file for AR System Java API.
The values of the API configuration parameters in this sample are
the default values. To override the default values, copy or rename
this file to arsys_api.xml and change the configuration parameter
values you want to override. You can remove or comment out the
configuration parameters that you do not want to override and keep
the default values.
Configuration parameters:
catalogFile: Base filename of XML message catalog.
Do not include the file extension or the language code.
Default value: arcatalog
maxProxiesPerServer: Maximum number of proxy connections per server
Valid values: 5, 10, 20
Default value: 10
connectionMaxRetries
Valid values: 0, 1, 2
Default value: 0
timeLagBetweenRetriesMillSec
Valid values: 1000, 2000 (in milliseconds)
Default value: 1000
toStringStyle - any static ToStringStyle member of a custom class
accessible to the current process.
Valid values:
org.apache.commons.lang.builder.ToStringStyle.DEFAULT_STYLE
org.apache.commons.lang.builder.ToStringStyle.MULTI_LINE_STYLE
org.apache.commons.lang.builder.ToStringStyle.NO_FIELD_NAMES_STYLE
org.apache.commons.lang.builder.ToStringStyle.SHORT_PREFIX_STYLE
org.apache.commons.lang.builder.ToStringStyle.SIMPLE_STYLE
com.bmc.arsys.api.NoPrefixToStringStyle.NO_PREFIX_STYLE
Default value:
com.bmc.arsys.api.NoPrefixToStringStyle.NO_PREFIX_STYLE
stringizeFieldAssignments - Controls whether the FieldAssignInfo class
assignment members are stringized for easier access.
Valid values: true, false
Default value: false
stringizeSetIfQualification - Controls whether the SetFieldsFromForm
action set-if-qualification member is stringized for easier access.
Valid values: true, false
Default value: false
apiRecording - Turns on the client side api logging and produces a
command file(<username><servername><port>_arapicmd.log)
and a result output
file(<username><servername><port>_arapires.log). The value is
a bit mask to allow for combination of
features to be blended. e.g In order to have
append mode for the log files and record
only elapsed time and no result data, the value
should be set to 2+8+32 = 42.
Valid values: 0 No Logging
1 Logging ON
2 Record in append mode in the files.
4 Record start and finish Time
8 Record Elapsed Time in ms
16 Combine the command and result files into the
result file
32 Do not record result data output
64 Buffer the file output
Default value : 0
jniLoadMode - Parameter to control JNI library loading.
Valid values: 0 JNI library will never be loaded
1 JNI library will be loaded only when required
2 JNI library will always be loaded
Default value : 1
-->
<javaapi_config>
<catalogFile>arcatalog</catalogFile>
<maxProxiesPerServer>10</maxProxiesPerServer>
<connectionMaxRetries>0</connectionMaxRetries>
<timeLagBetweenRetriesMillSec>1000</timeLagBetweenRetriesMillSec>
<toStringStyle>com.bmc.arsys.api.NoPrefixToStringStyle.NO_PREFIX_STYLE</toStringStyle>
<stringizeFieldAssignments>false</stringizeFieldAssignments>
<stringizeSetIfQualification>false</stringizeSetIfQualification>
<apiRecording>0</apiRecording>
<jniLoadMode>1</jniLoadMode>
</javaapi_config>
Axton Grams
On Thu, Apr 12, 2012 at 10:12 AM, Dee <ddus...@aim.com> wrote:
> Axton,
>
> From our network admins, these points where made, in response to your post.
>
> The connections from the midtier (Websphere) server to the ARserver are
> persistent TCP connections. These connections are not stateless.
> Our firewall is doing stateful inspection on these connections.
> The firewall security policy allows all of these connections to be started.
> Connections are flushed from the firewall state tables after 1 hour of
> INACTIVITY. Not active connections are ever flushed.
> After an inactive connection has been flushed, any further packets (in
> either direction) are dropped by the firewall. No RST packets are sent to
> the session endpoints at the time of the flush or at the time of the packet
> drops. A firewall log entry is created for each of these "out-of-state"
> packet drops.
> After attempting to re-use one of the inactive/flushed connections, the
> application's session endpoint make take several minutes doing TCP retries
> of their dropped packets before they give up and start a new connection.
>
> We want to know how we can configure the AR product to either:
> 1) keep these connections active by implementing the keepalive protocol or
> 2) close the connections when the immediate unit of work is finished.
>
>
>
>
> --
> View this message in context:
> http://ars-action-request-system.1093659.n2.nabble.com/Java-API-connection-pool-question-tp7454090p7459721.html
> Sent from the ARS (Action Request System) mailing list archive at
> Nabble.com.
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
