we are using Artifactory server and I encountered a problem today.
I tried deleting a distribution repo but I was unable.
I got an error message:
Deleting repo 'BASELINES-BINTRAY' failed: Could not merge and save new descriptor [org.jfrog.common.ExecutionFailed: Last retry failed: code exception. Not trying again (Failed to reload configuration:
org.artifactory.descriptor.repo.distribution.rule.DistributionRule cannot be cast
to org.artifactory.descriptor.repo.RepoDescriptor)]
I looked at the logs of Artifactory and this is what I saw:
2018-02-13 22:25:16,525 [http-nio-8080-exec-2637] [ERROR] (o.a.u.r.s.a.c.r.DeleteRepositoryConfigService:66) - Deleting repo 'BASELINES-BINTRAY' failed: Could not merge and save new descriptor
[org.jfrog.common.ExecutionFailed: Last retry failed: code exception. Not trying again (Failed to reload configuration:
org.artifactory.descriptor.repo.distribution.rule.DistributionRule cannot be cast to org.artifactory.descriptor.repo.RepoDescriptor)]
java.lang.IllegalStateException: Could not merge and save new descriptor [org.jfrog.common.ExecutionFailed: Last retry failed: code exception. Not trying again (Failed to reload configuration:
org.artifactory.descriptor.repo.distribution.rule.DistributionRule cannot be cast to org.artifactory.descriptor.repo.RepoDescriptor)]
any ideas what it means ?
Related
My Artifactory logs are showing the following errors with alarming frequency. The metadata service is up and healthy according to Artifactory, and aside from the log spam, it doesn't seem to be causing any problems. Does anyone have any ideas how to fix this?
[jfrt ] [ERROR] [af10ed1c492f4e88] [s.MetadataEventServiceImpl:346] [art-exec-6 ] - Unable to send statistics event to Metadata Server. Caught exception: Failed executing api/v1/stats, with response code: HTTP/1.1 500 Internal Server Error and response message: {"cause":"Internal error while processing request","message":"Failed to update stats with error couldn't find versionIDs for the given paths: couldn't find versionIDs for the given paths"}
Artifactory 7.27.10, running in Kubernetes
Using an external postgres 13 database
Using s3 as the storage backend
This is a known issue (documented internally as META-1180). This has been fixed and is released with Artifactory 7.29. This version of Artifactory is scheduled for release sometime over the next few weeks.
I have an illegal repository name, which starts with a number.
It's an old repo, created with API request (in Artifactory 6.5.1 version)
Artifactory accepts illegal name with API requests but if you restart artifactory, it's down
So my problem is the same like here:
https://www.jfrog.com/jira/browse/RTFACT-16669
Except the solution doesn't work for me.
Because my instance/server is new, so i have not this file $ARTIFACTORY_HOME/etc/artifactory.config.latest.xml with the local repository.
I have repositories on AWS S3 and a AWS RDS database
And my new AWS EC2 instance have to get repos on S3
My question is:
Can i start artifactory ignoring the bad repo ?
Or
Can i delete the repo without starting artifactory ? (without API request or GUI)
The logs are here:
2019-05-13 14:37:11,581 [art-init] [ERROR] (o.a.c.CentralConfigServiceImpl:744) - Could not load configuration due to: Failed to read object from stream
java.lang.RuntimeException: Failed to read object from stream
at org.artifactory.jaxb.JaxbHelper.read(JaxbHelper.java:131)
at org.artifactory.jaxb.JaxbHelper.readConfig(JaxbHelper.java:66)
at org.artifactory.descriptor.reader.CentralConfigReader.readAndConvert(CentralConfigReader.java:76)
etc ...
Caused by: javax.xml.bind.UnmarshalException: null
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.createUnmarshalException(AbstractUnmarshallerImpl.java:335)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.createUnmarshalException(UnmarshallerImpl.java:578)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:264)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:229)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:157)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:125)
at org.artifactory.jaxb.JaxbHelper.read(JaxbHelper.java:129)
... 56 common frames omitted
Caused by: org.xml.sax.SAXParseException: cvc-datatype-valid.1.2.1: '0ta' is not a valid value for 'NCName'.
etc ...
[art-init] [ERROR] (o.a.w.s.ArtifactoryContextConfigListener:96) - Application could not be initialized: null
java.lang.reflect.InvocationTargetException: null
etc ...
Caused by: org.springframework.beans.factory.BeanInitializationException: Failed to initialize bean 'org.artifactory.security.access.AccessService'.; nested exception is com.google.common.util.concurrent.UncheckedExecutionException: java.lang.NullPointerException
etc ...
[http-nio-8081-exec-2] [ERROR] (o.a.w.s.ArtifactoryFilter:194) - Artifactory failed to initialize: Context is null
Thanks
Cyril
The Artifactory config descriptor is stored in the Artifactory DB schema under a table named configs.
In order to overcome this, you can do the following:
Extract the artifactory.config.xml config from the configs table
Store the extracted configuration as a file in: $ARTIFACTORY_HOME/etc/artifactory.config.import.xml
Edit the artifactory.config.import.xml file and manually fix/delete the '0ta' repository reference from the configuration file
After modifying the descriptor, restart the Artifactory service.
Note, if you already have artifacts assigned to the illegal repo name, you will not be able to see them after modifying the repository name, however, since it is a new installation, I'm not sure that that this is relevant for you.
I have upgraded a few test instances of our Artifactory 6.0.2 Installation to version 6.9.1 using the provided instructions found at:
https://www.jfrog.com/confluence/display/RTF/Upgrading+Artifactory
I have tried both the yum upgrade and rpm installation pathways, and would like to end the installation with no error messages in the log files to minimize any potential issues from such errors.
After installation and many manual remediation steps I have reached an error "Unable to request the Metadata Service Service-Id" that I cannot find Google results for:
2019-04-09 16:22:13,409 [art-init] [ERROR] (o.a.m.s.s.ArtifactoryMetadataClientConfigStore:111) - Unable to request the Metadata Service Service-Id
2019-04-09 16:22:13,409 [art-init] [ERROR] (o.a.m.s.MetadataEventServiceImpl:188) - Unable to init the Metadata client. The Metadata Event pipeline will be disabled.
I have tried both the yum upgrade and rpm installation pathways.
After the upgrades, I noticed errors in the Catalina and Artifactory log files and followed the google search results regarding those error messages (added below my question for posterity):
(1) Created:
/var/opt/jfrog/artifactory/access/etc/bootstrap.creds
Containing:
access-admin#127.0.0.1=NEW_PASSWORD
(2) Removed access folder:
rm -rf /opt/jfrog/artifactory/tomcat/webapps/access
(3) Changed permissions of Artifactory directories:
cd /var/opt/jfrog/artifactory/
chown -R artifactory:artifactory .
(4) EDITED the artifactory.system.properties file adding:
artifactory.pathChecksum.migration.job.enabled=true
(5) Enabled sha 256 migration by adding this content to this same file:
##SHA2 Migration block
artifactory.sha2.migration.job.enabled=true
artifactory.sha2.migration.job.queue.workers=5
(5) Finally, Rebooted instance.
Yet the errors including The Metadata Event pipeline will be disabled persist.
I expect that the final state of the Artifactory server will be such that there are no error messages in the Artifactory nor Catalina log files.
Any assistance on remediating this error so that i can deploy the latest Artifactory build will be highly appreciated.
Thank you in advance.
======================
Here are some of the ERROR LOGS WHICH INITIATED CHANGES SHOWN ABOVE:
(1) 2019-03-27 05:03:22,872 [art-init] [WARN ] (o.j.a.c.AccessClientHttpException:41) - Unrecognized ErrorsModel by Access. Original message: Failed on executing /api/v1/system/ping, with response: Not Found
2019-03-27 05:03:22,872 [art-init] [ERROR] (o.a.s.a.AccessServiceImpl:364) - Could not ping access server: {}
org.jfrog.access.client.AccessClientHttpException: HTTP response status 404:Failed on executing /api/v1/system/ping, with response: Not Found.
(2)2019-03-27 05:06:53,235 [art-exec-3] [INFO ]
(o.a.s.j.m.s.Sha256MigrationJobDelegate:216) - SHA256 migration job (for existing artifacts) is disabled and will not run, there are 52496 artifacts without SHA256 values in the database. Future versions of Artifactory may enforce this migration as a prerequisite for upgrades.
(3) 2019-04-04 16:20:10,951 [localhost-startStop-1] [JFrog-Access] [WARN ] (o.s.b.c.e.AnnotationConfigEmbeddedWebApplicationContext:550) - Exception encountered during context initialization - cancelling refresh attempt: org.springframework.context.ApplicationContextException: Unable to start embedded container; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'org.springframework.boot.autoconfigure.jersey.JerseyAutoConfiguration': Unsatisfied dependency expressed through constructor parameter 1; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jerseyConfig' defined in URL [jar:file:/opt/jfrog/artifactory/tomcat/webapps/access/WEB-INF/lib/access-application-4.2.0.jar!/org/jfrog/access/rest/config/JerseyConfig.class]: Bean instantiation via constructor failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.jfrog.access.rest.config.JerseyConfig]: Constructor threw exception; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'systemResource' defined in URL [jar:file:/opt/jfrog/artifactory/tomcat/webapps/access/WEB-INF/lib/access-server-rest-4.2.0.jar!/org/jfrog/access/server/rest/resource/system/SystemResource.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'backupSubResource' defined in URL [jar:file:/opt/jfrog/artifactory/tomcat/webapps/access/WEB-INF/lib/access-server-rest-4.2.0.jar!/org/jfrog/access/server/rest/resource/system/backup/BackupSubResource.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'backupServiceImpl': Unsatisfied dependency expressed through field 'importerExporter'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'accessImporterExporterImpl': Unsatisfied dependency expressed through method 'setServerBootstrap' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'accessServerBootstrapImpl': Invocation of init method failed; nested exception is java.lang.IllegalStateException: Failed to bootstrap initial access credentials.
Thank you for the feedback #error404.
We ended up opening a ticket with Jfrog support (https://www.jfrog.com/jira/browse/RTFACT-18939) who was able to replicate the issue and subsequently marked the ticket as "Fix Version/s: 6.10.0"
Although not strictly stated, I assume this Fix Version update implies that the described issue will be remediated in the next release.
we have problems with our artifactory server since this morning. When I try to restart Artifactory, we get this error:
2018-04-16 10:11:11,360 [art-init] [WARN ] (o.j.a.c.AccessClientHttpException:27) - Couldn't parse ErrorsModel from Access. Original message: Not Found
2018-04-16 10:11:37,420 [art-init] [ERROR] (o.a.w.s.ArtifactoryContextConfigListener:99) - Application could not be initialized: Waiting for access server to respond timed-out after 90303 milliseconds. java.lang.reflect.InvocationTargetException: null
Can anyone help, we have no idea what's wrong
Thanks
It seems there is an issue with the Access application, which is being started simultaneously with Artifactory.
You should fine relevant logs at the following log file: $ART_HOME/access/logs/access.log
the error message is somewhat misleading. In fact, there was a problem at the database level. the transaction log becomes full on our MSSQL database. We have increased the limit and are working to see how to reduce the size of the log.
I am trying to publish one page on tomcat server. But it fails at Deploying phase with error message
Phase: Deployment Processing Phase failed, Could not initialize class com.tridion.storage.StorageManagerFactory. Can anybody help me?
Please also check password encryption in cd_storage_conf.xml: try without password encryption and see if it works.
Thanks for replying. The error was due to wrong configuration in cd_deployer_config.xml. That I fixed. But now I am getting error at committing deployment phase.
Error:
Phase: Deployment Prepare Commit Phase failed, Unable to prepare transaction: tcm:0-44-66560, org.hibernate.exception.SQLGrammarException: Cannot open connection, org.hibernate.exception.SQLGrammarException: Cannot open connection, Unable to prepare transaction: tcm:0-44-66560, org.hibernate.exception.SQLGrammarException: Cannot open connection, org.hibernate.exception.SQLGrammarException: Cannot open connection