Remote invocation error

[Former Community Member]

Hi,



I'm currently trying to invoke LiveCycle Assembler with a remote EJB client. The creation of the remote interface is made successfully, but when invoking one command (asm.invoke(ddxDoc, inputs, environment, null)),

I get the exception below.

The related folder exists on the LiveCycle assembler but is empty, whereas it is supposed to contain the input PDF file. When I execute the same invocation on the same server as LiveCycle Assembler, the code is correctly executed and files correctly copied.



Is this issue may be related to some missing access rights? To a bad creation of the remote interface? To the local policy of the server? The remote client is not on the same domain as the LiveCycle assembler server, and no authentication is required to access Assembler.



Thanks in advance for your help,



The exception:



java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:

java.rmi.ServerException: RuntimeException; nested exception is:

com.adobe.idp.DocumentError: Failed to copy from file "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\AdobeDocumentStorage\global\removeOn2006Y07M21D20h57m39s.1153508259000\9039370017604104651" to file "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\AdobeDocumentStorage\global\removeOn2006Y07M21D20h57m43s.1153508263000\2297780702837695720"

at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:292)

at sun.rmi.transport.Transport$1.run(Transport.java:148)

at java.security.AccessController.doPrivileged(Native Method)

at sun.rmi.transport.Transport.serviceCall(Transport.java:144)

at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)

at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)

at java.lang.Thread.run(Thread.java:534)

at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Unknown Source)

at sun.rmi.transport.StreamRemoteCall.executeCall(Unknown Source)

at sun.rmi.server.UnicastRef.invoke(Unknown Source)

at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source)

at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:135)

at org.jboss.invocation.MarshallingInvokerInterceptor.invoke(MarshallingInvokerInterceptor.java:67)

at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)

at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:53)

at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:100)

at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:85)

at $Proxy1.invoke(Unknown Source)

at ...

[Former Community Member]

The fact that your client program works fine when executed on the server machine is an excellent diagnostic. With that information, we can conclude that the exception is happening due to a constraint in the com.adobe.idp.Document object which is used to transfer the documents between the client and the server.



The easiest way to fix this is to configure a network directory that is shared on both the client and server machines and use that as the global document storage directory. You'll need to rerun the configuration manager on the server machine and input that directory path as the Global Document Storage Directory. Then you'll need to redeploy the LiveCycle.ear on the server. On the client, you'll need to set the com.adobe.idp.Document.globalDocumentStorageRootDir to the path of the shared directory. It is suggested that this be done via the -D command line option when starting the client, but it can also be done by client code that reads a client properties file.



Another option which may work is to set the com.adobe.idp.Document.defaultDocumentMaxInlineSize property to a value that is larger than all of the documents, both inputs and results. This should result in the documents being transferred inline with the EJB call, and kept in memory during execution. This is not recommended for large documents since it will impact memory usage on both the client and the server. You'll have to evaluate how much memory is available on both machines and how heavily loaded your machines are to determine if this is a viable approach.



The javadocs in Assembler\Documentation\javadocs\assembler_api have more information on the Document object and its use.



Don

[Former Community Member]

Hi Don,



Thanks for your answer. I've created a shared folder and repackaged and deployed the ear. The temporary file is now successfully created in the shared document storage folder, but I've got a time zone problem: the ejb creates a folder "removeOn2006Y07M23D14h05m43s" with the temporary file inside, but the client expects the document in the folder "removeOn2006Y07M23D14h02m18s": it appears that there's few minutes discrepancy between the server and the client. Do the two stations must be exactly at the same time, or is there a way to take into account only the server hour for instance?



Concerning the javadoc, I'm currently working with the beta version of the assembler and I will access to the released version until on mid-september so that I can access to only a limited documentation. I saw that the Document class attribute Document.globalDocumentStorageRootDir is private static final so that I can't modify nor access it. I don't know if this changed in the released version.



Regarding your other solution that I've tested before the shared folder one, increasing the defaultDocumentMaxInlineSize value makes the temporary folder created on the client instead of the folder but the folder is still empty. Nevertheless, according to the expected size of the PDF documents, I don't think that I'll use this solution.



If you have any idea about the time discrepancy, I would greatly appreciate your help.

Thanks,

[Former Community Member]

It appears I was mistaken about the globalDocumentStorageRootDir. I Your observation that this property is private is true in the release version as well, so it must be set with the -D option on a remote EJB client. I thought there was going to be a setter method on the Document object. Sorry for the confustion.



As for the timing issue, the document manager has a built-in mechanism to account for time differences between machines, so there should not be a need for the machines to be in sync or even in the same time zone. Did you observe that the client failed to receive a document because of a directory naming issue? If you are getting errors or exceptions, could you please post an example that includes the entire directory paths involved?



If the problem persists, it might be helpful to describe a little more fully what your system configuration is. I'm assuming its 2 Windows machines - is that correct? Is it a LiveCycle server with a standalone remote EJB client? Or is it 2 LiveCycle servers communicating? Also, which machine actually hosts the shared directory?



Thanks,

Don

[Former Community Member]

Hi Don,



Here is my current configuration:



LiveCycle server:

- Windows 2003 US SP1

- BEA Weblogic 8.1 SP4

- LiveCycle Assembler 7 beta

- 1 shared folder used as document storage directory



Client development workstation:

- Windows XP SP2

- available access to shared folder on LiveCycle server

- Eclipse + 1 stand-alone client program using Assembler API



Currently the client program is stand-alone for testing purpose, but it is planned to be included on an other server, inside another application for which I'm not sure to access to the launching parameters:



Client server:

- Windows 2003 SP1

- available access to shared folder on LiveCycle server



Regarding more precisely the error message, it appears that my idea about the time discrepancy was a mistake:



I've got the following message:



com.adobe.idp.DocumentError: Failed to copy from file "\\LIVECYCLE\SharedFolder\removeOn2006Y07M24D23h34m56s.1153776896000\94001609799663520" to file "\\LIVECYCLE\SharedFolder\removeOn2006Y07M24D23h34m56s.1153776896000\7887808311175301412"



In the shared folder on the livecycle server, I've got the target folder \\LIVECYCLE\SharedFolder\removeOn2006Y07M24D23h34m56s.1153776896000

that is empty as the program can't find the input folder



However, on the client workstation, I've got the folder

C:\DOCUME~1\A01148~1.DO-\LOCALS~1\Temp\AdobeDocumentStorage\global\removeOn2006Y07M24D23h34m56s.1153776896000

that contains the requested file 94001609799663520



The hours are then coherent, despite of any time zone or hour discrepancy, and the problem seems effectively to come from the fact that I've got to specifiy for my client application the location of the common document storage.

Therefore, could you please precise your idea about the -D parameter? Could you provide me an example of using it?



Thanks a lot,

Yohann

[Former Community Member]

On the command line that you use to start the remote EJB client, include:

-Dcom.adobe.idp.Document.globalDocumentStorageRootDir="S:\shared folder"



Replace the path to the actual shared folder as your client machine sees it. We use a mounted drive. I've not tried the network path notation, but it should work. I don't have the javadocs in front of me at the moment, so hopefully I've remembered the exact property name - you might want to double check that.

[Former Community Member]

Finally, the following line enabled the successful remote call of assembler (caution to the name of the package):



System.setProperty("com.adobe.idp.globalDocumentStorageRootDir","S:\shared folder");



Thanks a million, Don.

[Former Community Member]

We got a network with 2 LifeCycle Assembler installations, one is intended for test the other for production (ie. their NOT clustered). These two installations have some different configurations with regards to disk use. Our client is running on a different host. When we started testing we encountered the same problem as described in this thread. After setting the com.adobe.idp.globalDocumentStorageRootDir in the client and re-configuring the LifeCycle Assembler installation, everything seemed to work fine. However, when doing more testing (the client addressing the test installation), the invoke call failed from time to time because the production installation picked up the call and started processing it.

When reading the documentation it is stated that the globalDocumentStorageRootDir property is only to be used in a clustered environment. So how do we configure the Assembler and the remote client not using this property.

[Former Community Member]

Where does it say the globalDocumentStorageRootDir property is just for clusters? That is wrong, and I'd be happy to let Adobe know. :-) Back to your question...



Exactly what is your setup? I'll assume you have 3 machines: "test", "production" and "client". Lets say the globalDocumentStorageRootDir (GDSRD) from test is mounted on the client as T:\shared, and the GDSRD from production is mounted on the client as P:\shared. Then, to run tests from the client, you'd specify the JNDI url as jnp://test:8080 with GDSRD as specified T:\shared using the -D option. And production invocations would use jnp://production:8080 with GDSRD as P:\shared.



If that is what you're already doing, then we'd have to check the app server config. Which app server are you using? If JBoss, then check the C:\Adobe\LiveCycle\jboss\server\all\deploy directory to see if there is a cluster-service.xml in it. If so, try removing it and restarting the app servers.



Don

[Former Community Member]

We have installed the the LifeCycle product (v7.2) on JBoss. The servers runs on Windows Server 2003 and client are running on windows XP.



We've set the "Global storage directory" on the servers.

In the AdobeAssembleDoc.zip file we've found the document install_jboss.pdf. In the chapter "Configuring LiveCycle Assembler for deployment" there is a table listing run-time properties set using Configuration Manager. Regarding the "Global storage directory" it says: "This option specifies the path to an NFS shared directory

used to store long-lived documents that are involved in a

workflow process and to share them among all

cluster nodes. Specify a temporary directory for this

property only when deploying LiveCycle products in a

clustered environment."



On the client we've set: System.setProperty("com.adobe.idp.globalDocumentStorageRootDir","//test/shared");

JNDI url as jnp://test:8080

On the test server we set:

"Global storage direcotry" = T:\shared (same directory as //test/shared).

On the production server we set:

"Global storage direcotry" = P:\shared (different directory than //test/shared).



When running our test scenario document assembling sometimes failed because the production server picked up the invoke request.

We've not removed the cluster-service.xml files, only changed configuration disabling clustering. Removing the the cluster-service.xml file resulted in communicationException (connection refused) when getting the home interface.

Why did removing the cluster-service.xml file on the test server fail?

[Former Community Member]

Try on the client side setting jnp.disableDiscovery to true on the client side. This would be in the InitialContext properties. Using example 2.2 from the developer_guide.pdf:<br />//Create a Hashtable object<br />Hashtable propsJNDI = new Hashtable();<br />//Populate the Hashtable object with JNDI environment values<br />propsJNDI.put("java.naming.factory.initial","org.jnp.interfaces.<br />NamingContextFactory");<br />propsJNDI.put("java.naming.provider.url","jnp://<AppServer>:<AppPort>");<br />propsJNDI.put("java.naming.factory.url.pkgs","org.jboss.naming:org.jnp.<br />interfaces");<br />propsJNDI.put("jnp.disableDiscovery","true");<br />//Get a remote interface based on specified JNDI values<br />Assembler7Home home = Assembler7Util.getHome(propsJNDI);<br />asm = home.create();<br /><br />Let us know if that works.

[Former Community Member]

Thanks for the answer.

Our problem turned out to do with configuration of jboss.

What we did to make it work were:

On the server side in the jboss' cluster_service.xml set unique PartitionName for our two installations (e.g. TestPartition and ProductionPartition). In the same file we set the mcast_addr = "127.0.0.0", mcast_port="34374"

On the client side we tried you're suggestion, but it did not work. What worked was setting propsJNDI.put("jnp.partitionName",partitionName);

[Former Community Member]

Hi- We have the same problem mentioned in the original text of this topic.



But we have Assembler installed on AIX and tried to invoke from client (windows). So, we do not have option of Shared path as solution to fix this issue.



Please let us know how to solve this problem.



com.adobe.service.pdfm.client.OperationException: com.adobe.idp.DocumentError: Failed to copy from file "/tmp/AdobeDocumentStorage/global/removeOn2006Y12M07D12h17m54s.1165511874000/3268265252137391346" to file "/tmp/AdobeDocumentStorage/global/removeOn2006Y12M07D12h16m11s.1165515371000/3339882923713376045"

at com.adobe.idp.DocumentFileUtil.copy(DocumentFileBackend.java:418)

at com.adobe.idp.DocumentFileBackend.copy(DocumentFileBackend.java:175)

at com.adobe.idp.Document.passivate(Document.java:611)

at com.adobe.idp.Document.passivate(Document.java:580)

at com.adobe.idp.Document.length(Document.java:770)

[Former Community Member]

You'll need to use Samba or an NFS client of some sort to make a shared directory. LiveCycle 7.2 requires a shared network path for documents that are larger than the max inline size setting.

Don

[Former Community Member]

Hi Don,

i face a similar behavior while runnign my application on the same server.

if i run my application from a batch file every thing works, but in case i run it from a service (which activates the same batch file) i get the following exception:



General Exception -- java.io.FileNotFoundException: C:\WINDOWS\TEMP\AdobeDocumentStorage\global\removeOn2007Y08M01D08h26m13s.1185956773000\7947676097999737161 (The system cannot find the path specified)



is it related to the share problem? which directory should be shared? is it "C:\WINDOWS\TEMP\AdobeDocumentStorage"



thanks,

Hagai