WRITE_CLIP not allowed

Question

We are trying to write an integration in java for Centera and we keep getting things like

EXCEPTION : com.filepool.fplibrary.FPLibraryException: The use of this operation is restricted (transid='sles1164/826/WRITE_CLIP

.....

we are using a peafile and has capability query says we do have read,write,exist, etc rights.

How can we troubleshoot this?

Code follows

        FPClip theClip = null;
        FPTag newTag = null;
        FPTag topTag =null;
        try
        {
            FPPool pool = CenteraPoolManager.getInstance().getPool(poolAddress); // singleton
            theClip = new FPClip(pool,clipName);

            /**
             * Follow centera best practices
             */
            theClip.setDescriptionAttribute("app-vendor", "GWAVA");
            theClip.setDescriptionAttribute("app-name",CenteraPoolManager.appName);
            theClip.setDescriptionAttribute("app-version", CenteraPoolManager.appVersion);

            // retention period in seconds
            if (
                    (retentionDays > 0)
                )    {
                theClip.setRetentionPeriod(retentionDays * (24 * 60 * 60));
            }
            topTag = theClip.getTopTag();

newTag = new FPTag(topTag, tagName);

            try {
                topTag.Close(); // SDK docs imply this should occur after blobWrite, but SDK example shows this
            } finally {
                topTag=null;
            }

            // Blob size is written to clip, so lets just write out filename.
            newTag.setAttribute("filename", asDoc.getFileName());
            newTag.setAttribute(MetaNames.contentType, asDoc.getMeta().getProperty(MetaNames.contentType));
            newTag.setAttribute("docID", asDoc.getMeta().getProperty("old_hash"));
            newTag.setAttribute("size", asDoc.getSize());

// write the binary data for this tag to the Centera
newTag.BlobWrite(is); // Could add argument for example to explicitly state LINK (not embedded) or EMBED)

            String clipID = theClip.Write();

return clipID;

        } finally
        {
            StreamUtils.close(is);
            close(newTag);
            close(topTag);
            close(theClip);
        }

khanz1 · Answer

Hi mjb,

Download Centera Tools and use JCenteraVerify to test your pea file. If you still get this error then check to ensure that your profile has the access allowed at the profile as well as the pool level on your Centera.

mjb4 · Answer

I shoud clarify: We are experiencing the same issue against online cluster US3 (although US2) works fine. And of course we are using your PEA files in this case

mckeown_paul · Answer

I just managed to write a clip with a blob onto US3 use the top PEA file provided for it. Could you recheck what PEA file you are using?

mjb4 · Answer

same pea file.

Let's start over, although I would refer you to the code in the original message.

1. There are 3 sites that have been tested: US3, US2, and a customer site.

2. All except US2 fail with WRITE_CLIP errors.

3. The JCenteraVerify and the stack trace of the WRITE_CLIP against the customer follow.

4. The error line referenced in the stak trace is String clipID = theClip.Write();

5. Notice we do verify with centera the capabilities below and centera concedes we have those rights

Stack trace:

14:25:39,560 CenteraPoolManager - Centera read: result=true
14:25:39,561 CenteraPoolManager - Centera write: result=true
14:25:39,561 CenteraPoolManager - Centera delete: result=true
14:25:39,561 CenteraPoolManager - Centera exist: result=true
14:25:39,625 ServerErrorHandlerStrategy - reportError: StoreEmail :: com.gwava.archive.StoreEmail.handleArchiveExceptions:453 :: EXCEPTION : com.filepool.fplibrary.FPLibraryException: The use of this operation is restricted (transid='crpplx1retain1/5/WRITE_CLIP') com.filepool.fplibrary.FPLibraryException: The use of this operation is restricted (transid='crpplx1retain1/5/WRITE_CLIP')
    at com.filepool.fplibrary.FPClip.Write(Unknown Source)
    at com.gwava.engine.centera.Centera.store(Centera.java:211)
    at com.gwava.engine.centera.RetainDBCenteraEngine.archiveEmail(RetainDBCenteraEngine.java:91)
    at com.gwava.archive.StoreEmail.handlePUT(StoreEmail.java:273)

JCenteraVerify:

**************************************************************
************** Start of JCenteraVerify log ******************
**************************************************************

--------------------- General information -----------------------

Time:         Thu Feb 18 15:59:20 EST 2010
Tool Version:     3.2.23
SDK Version:    3.2.607

--------------------- User configuration ------------------------

TOOL SETTINGS
   Number Of Files:    3
   FileSize (KB):    1, 10, 100
   Working Dir:    .\Temp
   Restore Dir:    .\Temp\Retrieve
   Log File:        .\JCenteraVerify.log
   Delete temp Files:    true
   Delete restore Files:    true

SDK SETTINGS
Number of Retries: -1
Retry Sleep: -1

----------------- JCenteraVerify test results -------------------

ACCESS NODE CONNECTIVITY CHECK

172.23.239.50?C:\gwarchive_merged_sdc_jdc.pea is available.

CLUSTER INFORMATION

   ClusterId:        2b9573d4-1dd2-11b2-ab42-eee61dfc2f0c
   CentraStar:        4.0.2-3195-1019-20652
   Available Capacity:    41,137 GB
   Total Free Capacity:    44,712 GB
   Replica Address:    172.24.64.29,172.24.64.27

CAPABILITIES

      Read allowed:    true
      Write allowed:    true
      Delete allowed:    true
      Exists allowed:    true
      Purge allowed:    false
      Monitor allowed:    false
      Query allowed:    true
      PrivDelete allowed:    false

Writing the file 1
1 File(s) written successfully.    CA: 38G5O9G9DUD44e3QUH8JO6HH35JG414RHD8A0K0U6LS65MCNFGCIN
Reading the file 1.        CA: 38G5O9G9DUD44e3QUH8JO6HH35JG414RHD8A0K0U6LS65MCNFGCIN
1 File(s) read successfully
Deleting the file 1.        CA: 38G5O9G9DUD44e3QUH8JO6HH35JG414RHD8A0K0U6LS65MCNFGCIN
1 File(s) deleted successfully
Writing the file 2
2 File(s) written successfully.    CA: 5PHI735CRTIURe02TLJ2PQBEFIEG414RHD8B0L0E89KBAF82M8DC3
Reading the file 2.        CA: 5PHI735CRTIURe02TLJ2PQBEFIEG414RHD8B0L0E89KBAF82M8DC3
2 File(s) read successfully
Deleting the file 2.        CA: 5PHI735CRTIURe02TLJ2PQBEFIEG414RHD8B0L0E89KBAF82M8DC3
2 File(s) deleted successfully
Writing the file 3
3 File(s) written successfully.    CA: 5INR0UH286PL2eDOL27UP2T0EVTG414RHD8C0O087MT2CFCGPEIP9
Reading the file 3.        CA: 5INR0UH286PL2eDOL27UP2T0EVTG414RHD8C0O087MT2CFCGPEIP9
3 File(s) read successfully
Deleting the file 3.        CA: 5INR0UH286PL2eDOL27UP2T0EVTG414RHD8C0O087MT2CFCGPEIP9
3 File(s) deleted successfully

**************************************************************
***************** End of JCenteraVerify log ****************

gstuartemc · Answer

I may be misinterpreting your post, but are you saying that on the customer site (and with US3) JCenteraVerify shows everything is working properly while your application is receiving write errors? And that you are able to write successfully to US2?

If this is the case then you should raise a support call. These forums are intended for queries and discussions - we answer them when we have spare time to do so and have no access to customer clusters to resolve issues.

In cases such as yours (production customer issues), raising a support call will ensure that things are dealt with in a more timely fashion and with a defined escalation procedure. Support will also be able to examine the production cluster and retrieve the cluster logs to investigate why the write transaction is failing.

gstuartemc · Answer

One thing I did notice in your code is that there are 2 places where you close the TopTag - this is incorrect. You should only ever close tags once, and they should be closed as soon as they are no longer used i.e. you have created any required attributes on the tag and any FPStream relating to the tag has been closed.

In your code, you close the topTag immediately after creating newTag. As you only create a single tag in your Clip then this is the correct time to do so and the additional close (at the end) should be removed.

mjb4 · Answer

Actually I found out the answer.

1. Bug in my code: One of the singleton constructors was building nly the SERVER name, not appending the pea file info. So it was an anonymous login.

2. Possible bug on EMC: Is it deliberate that US2 allows anonymous login? That's the only reason US2 worked.

3. Bug on EMC: One thing that kept me from finding this obvious bug was I QUERIED the capabilities after login and was told TRUE to READ, WRITE, EXISTS on US3 with an anonymous login. Clearly that ain't true

4. The two places where the tag is closed are correct. One of them is in a finally clause and belongs there in case an exception occurred BEFORE the regular close call.

gstuartemc · Answer

Thanks for the update. I only quickly looked at your code and as I was not viewing it in an IDE (but on my blackberry) it made matching the try-catch-finally sections difficult!

Anonymous is deliberately enabled on some clusters as there are people who want to test using this method (even though it is against Best Practice application / cluster setup).

There does appear to be a problem with anonymous on US3 when writing clips and this will be investigated. Given the capabilities of the cluster, it should work, so your code was doing the correct things. Thanks for letting us know!

Centera

WRITE_CLIP not allowed

Was this post helpful?

Register Now! for Secure Secrets with Kubernetes & DevSecOps - and grab a lab!

Dell Technologies at SpiceWorld 2022