JMS SAF client paging directory definition ignored

Question

The paging directory definition in our ClientSAF.xml file is ignored:
          <weblogic-client-jms xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
          <persistent-store>
               <directory-path>C:\Work\newaupload\jms</directory-path>
               <synchronous-write-policy>Disabled</synchronous-write-policy>
          </persistent-store>
          <saf-agent>
          <paging-directory>C:\Work\newaupload\jms-paging</paging-directory>
          </saf-agent>
          </weblogic-client-jms>
          Instead of the directory given in the configuration, the JMS SAF client creates a directory called "paging" in the current directory. In our case, the current directory is where all the binaries are and which is not writable, i.e. the JMS client fails.
          Is something wrong with the configuration? Or is this a bug?
          Peter
          Edited by peter05 at 05/30/2008 3:30 AM

Answer 1

Hi Peter,
          For a server-side SAF with a file store, a paging directory would normally only be used internally for non-persistent messages - and I think client-side SAF would have the same behavior if it actually supports non-persistent messages in the first place.
          I don't know if the SAF client supports non-persistent - as I hadn't really thought about it -- there doesn't seem to be much purpose in it given that the purpose of SAF is store-and-forward and the "store" part implies persist messages.
          As a work-around, perhaps you can create the directory manually as read-only, then check to see if your app places any files in this directory. If it is, then your app could be creating non-persistent messages for store-and-forward, which likely isn't your intent -- non-persistent messages are not recovered on a restart, even if they are in a paging directory.
          If there must be an active paging directory for some reason, I advise (A) contacting customer support to find a way to configure it uniquely and (B), as a work-around, using an operating level linked directory or some-such to redirect the "paging" directory name out of your read-only binary directory to a better place.
          Hope this helps,
          Tom
          PS. In addition, it's a little strange to me that this directory name is hard-coded - what would happen if two SAF clients running in the same JVM attempted to use the same paging directory? Would they conflict with or even corrupt each-other?