on 12-12-2016 8:06 AM
Hi Experts, We are working on SAP Hybris 6.1 , During initialization or updation i noticed one error is coming frequently
ERROR [hybrisHTTP17] (000004NV-ImpEx-Import) [Job] Error saving log file org.springframework.dao.DuplicateKeyException: query;
SQL [];
Cannot insert duplicate key row in object 'dbo.medias' with unique index 'codeVersionIDX_30'. The duplicate key value is (20161207_121405.zip, ).;
nested exception is com.microsoft.sqlserver.jdbc.SQLServerException: Cannot insert duplicate key row in object 'dbo.medias' with unique index 'codeVersionIDX_30'. The duplicate key value is (20161207_121405.zip, ). : de.hybris.platform.jalo.JaloSystemException: org.springframework.dao.DuplicateKeyException: query;
SQL [];
Cannot insert duplicate key row in object 'dbo.medias' with unique index 'codeVersionIDX_30'. The duplicate key value is (20161207_121405.zip, ).;
nested exception is com.microsoft.sqlserver.jdbc.SQLServerException: Cannot insert duplicate key row in object 'dbo.medias' with unique index 'codeVersionIDX_30'. The duplicate key value is (20161207_121405.zip, )
I noticed this error is coming when multiple impex files are running during 1 second and SAP hybris people are saving the log file with format YYYYMMDD_HHMMSS.zip but It could be better if you can also add Milliseconds to the format, so that this issue wont occur. This code is there in Job.class file.
Hi , I have had the same thing.
The OOTB Media type added an Index, you can reverse it by adding a custom extension, and putting the following in the *-items.xml:
<itemtype code="Media" autocreate="false" generate="false">
<indexes>
<index name="codeVersionIDX" unique="false" replace="true">
<key attribute="code"/>
<key attribute="catalogVersion"/>
</index>
</indexes>
</itemtype>
The replace="true" is what changes the OOTB implementation.
It's giving you the error, as you have duplicate data in the composite key.
Regards, Govardhan.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
What you should do is stagger the schedule of your cronjobs, and accept the error on start up. Aspects are always bad as they are problematic to maintain and analyse in a production environment for your support team. Changing the OOTB implementation is always a bad idea for your upgrade path. What you should really do is raise a bug with SAP and get them to stop using timestamps as a unique identifier which is a crappy way of guaranteeing a unique id, which does not work, and something I see everywhere in the Hybris code.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi, its known problem, the quick solution is to apply the AOP, 2 pointcuts (or if possible with aspectj syntax, make 1) are required:
@Around(" execution (* de.hybris.platform.cronjob.jalo.CronJob.createNewLogFile(java.lang.String))")
@Around(" execution (* de.hybris.platform.impex.jalo.ImpExManager.createImpExMedia(java.lang.String))")
in these pointcuts you can define your logic, for example
public Object changeParameterName(final ProceedingJoinPoint pjp) throws Throwable {
Object[] args = pjp.getArgs();
if (args != null && args.length == 1) {
//final String filename = (new SimpleDateFormat("yyyyMMdd_HHmmss")).format(new Date()) + ".zip";
String oldFileName = (String) args[0];
//changing the value
args[0] = oldFileName.substring(0, oldFileName.indexOf(".")) + "_" + Config.getParameter("cluster.id") + ".zip";
}
return pjp.proceed(args);
}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Doesn't appear that it can be overridden
the method saveToLogFile is static final void - arghh
inside it it has the following
String filename = (new SimpleDateFormat("yyyyMMdd_HHmmss")).format(new Date()) + ".zip";
really this ought to be a config property.
I suggest raising an issue in JIRA to get this address in a minor patch update. It appears this problem is also in other versions (am using 5.7)
You could look into, for now, modifying the media type and extending/removing (and recreate) the offending index to include another property (owner maybe?). this will allow the system to create multiple files with the same timestamp for different cronjobs.
What other side affects this may have elsewhere I'm not 100% sure, so you will have to do some investigation/regression testing
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Gopi, did you have a solution yet ? we just updated to 6.2 and getting similar exception ..
java.lang.IllegalStateException: problem executing sql [reason: StatementCallback; uncategorized SQLException for SQL [CREATE UNIQUE INDEX codeVersionIDX_30 ON MEDIAS (P_CODE, P_CATALOGVERSION)]; SQL state [HY000]; error code [349]; SAP DBTech JDBC: [349]: cannot CREATE UNIQUE INDEX; duplicate key found: [5] Several documents with the same ID exist in the index;HYBRIS:MEDIAS.$uc_CODEVERSIONIDX_30$ content not unique, cannot define unique constraint. rowCount != distinctCount ; nested exception is com.sap.db.jdbc.exceptions.BatchUpdateExceptionSapDB: SAP DBTech JDBC: [349]: cannot CREATE UNIQUE INDEX; duplicate key found: [5] Several documents with the same ID exist in the index;HYBRIS:MEDIAS.$uc_CODEVERSIONIDX_30$ content not unique, cannot define unique constraint. rowCount != distinctCount ]
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
8 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.