I'm trying to open the Artifactory Users Management page, following the Admin->Security->Users tab.
Then I'm getting the following error:
Any idea of what might be causing it? Also, which log I can check this? Couldn't find anything yet.
The server error generally indicates there is problem fetching the user details from Artifactory. This can happen due to any of the following reasons:
when you have a high volume of users and the request is timing out.
There is a chance that you might have created a username with a
special character which is not allowed (using the REST method or some
other method)
There is an issue with the backend database
And the best place to troubleshoot is to first check the request log a good valid entry looks like below:
20200715164402|104|REQUEST|165.225.104.49|admin|GET|/ui/users|HTTP/1.1|200|0
Next check the artifactory.log file for java stack or check catalina.out under tomcat/logs directory.
Related
I know a similar question has been asked (link), but the response didn't work for me.
TLDR: I keep running into errors when trying to authenticate Google Cloud Storage in RStudio. I'm not sure what is going wrong and would love advice.
I have downloaded both the GCS_AUTH_FILE (created a service account with service admin privileges'--downloaded the key associated with the service account) and also downloaded GAR_CLIENT_WEB_JSON by creating a OAuth 2.0 Client ID and downloading that associated JSON file.
I've tried authenticating my Google Cloud Storage in several ways and hit different errors.
Way 1-automatic setup:
gcs_setup()
Then I select any one of the options, and get the error: Error in if (file.exists(local_file)) { : argument is of length zero And that error happens no matter which of the three options I select.
Way 2 - basic, following manual setup instructions from the package:
Sys.setenv("GCS_DEFAULT_BUCKET" = "my-default-bucket",
"GCS_AUTH_FILE" = "/fullpath/to/service-auth.json")
gcs_auth()
In this case, GCS_AUTH_FILE is the file that I mentioned at the beginning of this post, and the GCS_DEFAULT_BUCKET is the name of the bucket. When I run the first line, it seems to be working (nothing goes awry and it runs just fine), but when I run gcs_auth() I get taken to a web browser page that states:
"Authorization Error
Error 400: invalid_request
Missing required parameter: client_id"
Way 3: Following the method from the post that I linked above
This way involves manually setting the .Renviron file w/ the GCS_AUTH_FILE and GAR__CLIENT_WEB_JSON locations, and then running gar_auth(). And yet again, I get the exact same error as in Way 2.
Any ideas about what could be going wrong? Thanks for your help. I wasn't sure how to put in totally reproducible code in this case, so if there is a way I should do that, please let me know.
I am trying to send a message through the command line using msg.exe on Windows 7. I have successfully gotten everything to work except for the Session ID. I get the error Error 5 getting session names. After searching online I found that I can edit the registry to remove this error using regedit.exe. However, on the domain I am on, I do not have permissions to edit the registry. I can only view it.
I know the individual session ID's of the users that I am trying to send a message to.
Super user hasn't really been any help... How do I prevent the error from occurring without editing the registry?
You need to log into the user, that the computer you are trying to send to is on.You will need to do is go to credential manager, and add the credentials. That error message will go away.
Sometimes when we open folder, Alfresco shows spinning wheel and never opens the folder. The log has below exception.
2016-03-08 11:45:40,652 INFO [webscripts.connector.RemoteClient] [http-bio-8080-exec-494] Exception calling (GET) http://localhost:8080/alfresco/s/slingshot/doclib/treenode/site/test/documentLibrary/Books/science?children=true&max=-1&alf_ticket=TICKET_400a73c20348346eed011695af270f837f27a654
2016-03-08 11:45:40,652 INFO [webscripts.connector.RemoteClient] [http-bio-8080-exec-494] Error status 500 null
ClientAbortException: java.net.SocketException: Connection reset
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:413)
If I curl the above URL or open directly in webrowser I am able to get the json response successfully.
I am using only Alfresco Share and not anyother client. The localhost:8080 is working perfectly fine in most of the cases except this one.
Can anyone please tell me what is the issue and why connection is closed or ClientAbortException exception is occurring?
Mostly this is an issue of timeout and you'll need active monitoring on your Alfresco & Share environment to see how Alfresco is running.
Easy check is to install some java monitoring or use Jmeter to load test the system and see how it responds on different load.
Mostly the outcome is more CPU/RAM for Alfresco :).
As Tahir Malik mentioned above, the issue is related to performance.
The ClientAbort error itself occurs when the client (in this case, Share) times out or the user cancels a download. The message on the log is type INFO. More details here: https://issues.alfresco.com/jira/browse/ALF-20349
If you are on SSO and using Alfresco Enterprise 5.2.3 or 5.2.4, there is a chance that you may hit a similar bug, which is discussed in the Alfresco Forum. However, this particular bug would not show the ClientAbortException.
I don't have any errors with my smart target application, but I do see in the event log, the following error messages:
ERROR 2012-09-19 14:30:09
com.tridion.smarttarget.utils.AmbientDataHelper - can't find defined
trigger-types in claim store (check if your smarttarget cartridge is
up and running)
and:
ERROR 2012-09-19 14:30:11
com.tridion.smarttarget.tags.TimeoutQueryRunner - The fredhopper query
timed out java.util.concurrent.TimeoutException at
java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source) at
java.util.concurrent.FutureTask.get(Unknown Source) at
com.tridion.smarttarget.tags.TimeoutQueryRunner.executeQuery(TimeoutQueryRunner.java:64)
ERROR 2012-09-19 14:30:11
com.tridion.smarttarget.tags.TimeoutQueryRunner - The fredhopper query
timed out
I would really like to understand what is causing these and how I can remove them. Or some suggested steps to help me debug this would be great :)
As I say, everything is working perfectly, later on in the logs I see the query to ST is correct and the results being generated.
In the event that is helps, I'm running on a 2009 implementation with Smart Target 2010, java 1.5.
thanks
John
Sounds like you might have a trigger configured in ST that does not actually exist in the ADF (or is mismatched). Have you looked through your trigger-types.xml file for anything obvious? Have you disabled an ADF cartridge but not removed the corresponding trigger in the XML perhaps? See the documentation for Defining trigger types.
I think your timeout is coming from the SmartTarget region rather than FredHopper. Sometimes a query that isn't already cached in FredHopper can take a while to return, even though it's ultimately successful. The ST query tag has a timeout (defined in the smarttarget_conf.xml file, or over-ridden with a tag attribute) that it will wait for a response from Fredhopper for before resorting to using the fallback content. This might explain why you see later in the logs that the query is correct and that results are returned. See the documentation for <tcdl:query>.
No conclusive answer for you I'm afraid, but I hope that helps.
The first error is logged if your SmartTarget cartridge is not running -- or if the data that it puts into ADF is lost somehow (e.g. you have disabled sessions in your web server).
In that case, SmartTarget will still do a query but it won't include anything from the Ambient Data Framework in it. If you don't have any triggers based on ambient data, the end result is the same for you.
To get rid of the error, make sure that smarttarget_cartridge is configured correctly.
As for the timeout error, it simply means that the query sent to Fredhopper took longer than the configured time. In that case it will show the fallback content instead. If this is happening a lot, you might want to increase the timeout within smarttarget_conf.xml.
I hope you found the issue, but for future reference, the first error message is raised when the claim "taf:claim:ambientdata:definedtriggertypes" is not set by the SmartTarget cartridge. This can be caused by:
SmartTarget cartridge could not load the the trigger types from the SmartTarget server. The log will show an error "can't retrieve list of defined trigger types from FH".
The HTTP session on your web server is expired during an active visit (the HTTP session expired but the browser is still open) and the claim is "lost".
The server does not support sessions like Peter mentioned.
My symptoms and System.DirectoryServices.AccountManagement stack trace are exactly the same as While trying to retrieve the authorization groups, an error (5) occurred except that I get an error 110 which docs explain as ERROR_OPEN_FAILED: The system cannot open the device or file specified.
In my situation, this functionality was working one day and stopped working the next day within an ASP.NET v4 application. I am using an AD service account that I've created in order to establish a connection to AD. The service account has admin privileges to a specific OU further down in the directory.
I've narrowed the exception down to a call made to the AuthzInitializeContextFromSid native function inside the System.DirectoryServices.AccountManagement.AuthZSet constructor. It is not clear to me why this fails and since user.GetGroups works for me (per the answer given in the other SO link), I'll put my research on hold for now.
Does anyone else have any thoughts on what might be occurring?
Error 5 usually means you are having an ERROR_ACCESS_DENIED win32 error. That can happen if you're accessing a downlevel API that can only be queried with administrative rights or if the object you are accessing has ACLs that deny access from the process token your program is running at.
In simple words: try running your app elevated. If it works, you had insufficient access rights when running without elevation.