Randomly when I go to check out a document in Webtop I get a UCF error.
Anyone have any ideas how to troubleshoot this?
I would check a few things:
1) Is Java correctly installed? Is the right version of Java installed? (You can check it at http://www.javatester.org/version.html).
2) Try deleting the ucf folder (something like C:\Documents and Settings\{USERNAME}\Documentum\ucf), cleaning IE cache and restarting it.
3) Enable (in file C:\Documents and Settings\{USERNAME}\Documentum\ucf\{MACHINENAME}\shared\config\ucf.client.config.xml) and then check UCF logs. Also check Webtop app server logs.
Thanks, Kirill
may be you use some kind of load balancing, and your webtop hidden under load-balancer? UCF session not stored in load-balancer, so this session can randomly ping-ponged between servers and loose.
Related
I am using AnypointStudio 3.7 and trying to install object-store plugin from exchange. but when I click on install button I got an error displaying the message
"There was a problem loading the update site located at
http://repository.mulesoft.org/connectors/releases/3.5.0"
The same error also occurs in order to install other plugins/connector like box from same repository.
I have tried to add the plugin from Help->Install New software window but there also getting the same error.
error getting here is :
"Unable to read repository at http://repository.mulesoft.org/connectors/releases/3.5.0/content.xml."
However I am able to install the updates from other sites like Anypoint update, DevKit etc but not able to install updates from connector update site.
Please anyone help me to find the reason why Anypoint is behaving like this:
FYI , I am using proxy setting in my machine. Could it be the cause of failure?
Thanks in advance !!
Instead of adding from exchange, you can also try an option to add new software from Help -> Install New Software -> work with "Anypoint connector update site" -> specify "objectstore" in search. Select the appropriate ve
#Md. Sadique Ansari ... Please check http://repository.mulesoft.org/connectors/releases/3.5.0/content.xml this url from your browser first because this error mostly due to network firewall setting.
Are you assessing this in your organization network ??
I spotted the message about this in the error logs...googling lead me here...
I noticed, in my attempts to manually test the urtl in a browser that some paths got flipped to HTTPS...so I changed the url in preferences to use HTTPS...and now no errors in the log!
(No updates either but...)
I have deployed a system integrated with weblogic, but until now I faced a problem is the weblogic increasing the stdout.out size heavily(by GB per week), it caused the system to load slowly and slowly.
Any way to prevent it increase the size heavily or redirect into .log?
Thanks alot
As David Herget says above, using the WebLogic Scripting Tool (WLST) to redirect StdOut and StdErr did not actually work for me either; I had to also do so through the web console (even though they appear to be set on the console) and restart the relevant jvms.
I can't reply to David's comment above due to being a newbie. [Edited since for clarity]
Not totally sure to understand fully your question.
Are you talking about the {server_name}.out file located in the {Domain_Path}/servers/{server_name}/logs ?
If so, I've never found anyway to rotate those logs automatically so I run a script each day to rotate it (basically copying it to another name, zip it and echoing a NULL in the orginal file...erasing the older one after).
If you are talking about redirecting StdOut to the logs though, that can be done within the console for each server in the logging tab by checking "Redirect stdout logging enabled". Configuration to rotate those logs can also be done within that tab.
On that, StdErr can also be redirected, but not from the console (in WL9). You have to put "RedirectStderrToServerLogEnabled" at true in the MBean tree by wlst (it's located at /Servers/{server_name}/Log/{server_name}
I know the question was ask long time ago but hoping it would help nonetheless
Weblogic provides features of log files rotation based on the size and time interval.
You can try rotating the log files based on the size. You would need to configure the log rotation policy from the admin console. Please refer the below link for further details.
http://docs.oracle.com/cd/E12840_01/wls/docs103/ConsoleHelp/taskhelp/logging/RotateLogFiles.html
If you want to rotate the log files on demand, you can use the below WSLT script.
C:\>java weblogic.WLST
#connect WLST to an Administration Server
wls:/offline> connect('username','password')
#navigate to the ServerRuntime MBean hierarchy
wls:/mydomain/serverConfig> serverRuntime()
wls:/mydomain/serverRuntime>ls()
#navigate to the server LogRuntimeMBean
wls:/mydomain/serverRuntime> cd('LogRuntime/myserver')
wls:/mydomain/serverRuntime/LogRuntime/myserver> ls()
-r-- Name myserver
-r-- Type LogRuntime
-r-x forceLogRotation java.lang.Void :
#force the immediate rotation of the server log file
wls:/mydomain/serverRuntime/LogRuntime/myserver> cmo.forceLogRotation()
wls:/mydomain/serverRuntime/LogRuntime/myserver>
http://docs.oracle.com/cd/E12840_01/wls/docs103/logging/config_logs.html#wp1001654
I am a newbie.I am using Weblogic 10.0.0.0..I am getting an validation error in first page(Login Page wit user name and pwd) as "logger is not initialized",while deploying. I do the same thing with tomcat, and the .war is imported and deployed is success. What is the reason? and also ,in weblogic 10.0.0.0 we have two jdk's(jdk 1.6 and Jrockit)...in my system i m having 1.6.0_17..so which one it takes.i forgot which i choose while installing..whether it takes from wblogic jdk or which one?..wher i m going wrong..its a small one i notice..but could not figure out..plz lemme kno??
This is either because you haven't configured your WLS installation correctly. When you first setup your console there is a parameter you have to change in your auth file that if not set with cause this issue.
Or you are selecting logging during deployment from the admin console and you haven't configured log4j in your application.
We are running a Domino 8.5.3 and the server log is constantly issuing these errors:
HTTP JVM:
!err.PersistenceServiceResourceProvider.Errorwritingtopersistedcontenttor!
We have not been able to isloate it to a particular page. Eventually, the HTTP task will crash and we need to reboot the server and recompile all the databases on the server. We are using the CKEditor to generate the HTML content. You help would be most appreciated.
We used to get this exact error a lot which appeared to be caused by inline images uploaded via the CKEditor like Paul mentioned.
I don't know why but we fixed it by changing the directory domino uses for uploads via the
xsp property xsp.persistence.dir.xspupload (formally xsp.upload.directory)
changing it to something like c:\temp rather than the windows default made the problem go away. could have been a co-incidence but may have been something in windows interfering
I haven't seen that error before but it reads like it might be something to do with asking the server to make a lot of data available to the xpages between calls to the server- effectively, session and application scope data.
When running a web deploy to a specific IIS site I get the following error:
Error: The synchronization is being stopped because the maximum number of sync passes '5' has been exceeded even though all the changes could not be applied. This could occur if there are external changes being made to the destination.
At C:\Code\.....\deploy.ps1:185 char:10
+ & <<<< ($appDeployCmd) $type /M:$url /U:$user /P:$pass /A:Basic -allowUntrusted -useCheckSum
+ CategoryInfo : NotSpecified: (Error: The sync...he destination.:String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
Web Deploy is working fine on this environment against other IIS sites and file syncs are also working. I have previously been able to use web deploy to deploy this specific site without issue. All of the sudden out of nowhere, this issue started happening and I can no longer deploy this site.
I'm doing a basic site deploy with a package built from msbuild. I don't think the specifics are that important because as I said this was all working before and currently works against other sites on the same server farm without issues.
The error message says:
"This could occur if there are external changes being made to the destination."
but I'm not sure how to track this down or if it is even the issue to begin with. I've made sure all explorer windows are closed in all remote sessions. I've tried restarting the site and the app pool. The only thing I have not tried is rebooting the server which is not possible at moment.
Any ideas what might be cause this web deploy to fail?
I had the same error and the problem was my dropbox.
I was working directly in my dropbox folder, and when you publish, it causes dropbox to syncronize at the same time, which caused the error.
Disabling dropbox sync while working solved the problem.
I recon the problem also could happen with onedrive, google drive and so on.
We had this problem when converting from a previously adhoc deploy of a service to MSDeploy, and found that if there were files that were either
marked as read-only via the DOS/Windows read-only file attribute.
inaccessible due to ACLs
then we would get the "maximum number of sync passes" error on deploying.
Once we fixed the attributes/ACLs, we were able to sync.
Quick and easy way to resolve this issue is to delete the files in the destination and re-run the web deploy.
The issue seems to revolve around the ACL step of the web deploy, which attempts to change the permissions of your websites files as a safety measure intended to ensure they are not changed during a deployment.
By default Web Deploy sets the ACL of the sites anonymous user to read only while also overwriting Control Panel access to your website.
Source
You can turn of ACL in future to avoid this if you wish, but it's not really worth it. This will also speed up web deploys - but that is a separate issue.
Not really an answer, but one workaround you can try if you are using the Web Deploy dirPath, filePath, or contentPath providers is the ignoreErrors provider setting. If you know that you are consistently hitting a certain error number, you can specify that that error be ignored when it's hit. See the dirPath provider article for full details (and caveats).
In my case I couldn't fix it but realised the deployment worked regardless.
If you are reading this I wouldn't suggest to just assume it worked, and if it did that it deployed fully, but consider that it may be a false alarm!