Bug 1372950

Summary: Engine fail to start with NPE No default constructor for ManageNetworkClustersParameters["attachments"]
Product: [oVirt] ovirt-engine Reporter: Meni Yakove <myakove>
Component: BLL.NetworkAssignee: Martin Mucha <mmucha>
Status: CLOSED CURRENTRELEASE QA Contact: Pavel Stehlik <pstehlik>
Severity: high Docs Contact:
Priority: urgent    
Version: 4.0.4CC: bugs, danken, gklein, juan.hernandez, mmucha, ncredi, oourfali, ylavi
Target Milestone: ovirt-4.0.4Keywords: Automation, AutomationBlocker, Regression
Target Release: 4.0.4.2Flags: rule-engine: ovirt-4.0.z+
rule-engine: blocker+
ylavi: planning_ack+
rule-engine: devel_ack+
myakove: testing_ack+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
undefined
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-09-26 12:32:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Network RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
engine and server logs none

Description Meni Yakove 2016-09-04 08:40:48 UTC
Created attachment 1197588 [details]
engine and server logs

Description of problem:
While network tier2 run the engine goes down and cannot start again with NPE:

Caused by: org.apache.commons.lang.SerializationException: org.codehaus.jackson.map.JsonMappingException: No default constructor for [collection type; class java.util.Collections$SingletonSe
t, contains [simple type, class org.ovirt.engine.core.common.businessentities.network.NetworkCluster]] (through reference chain: org.ovirt.engine.core.common.action.ManageNetworkClustersPara
meters["attachments"])
        at org.ovirt.engine.core.utils.serialization.json.JsonObjectDeserializer.readJsonString(JsonObjectDeserializer.java:103)
        at org.ovirt.engine.core.utils.serialization.json.JsonObjectDeserializer.deserialize(JsonObjectDeserializer.java:60)
        at org.ovirt.engine.core.dao.CommandEntityDaoImpl.deserializeParameters(CommandEntityDaoImpl.java:155)
        at org.ovirt.engine.core.dao.CommandEntityDaoImpl.access$000(CommandEntityDaoImpl.java:33)
        at org.ovirt.engine.core.dao.CommandEntityDaoImpl$1.mapRow(CommandEntityDaoImpl.java:73)
        at org.ovirt.engine.core.dao.CommandEntityDaoImpl$1.mapRow(CommandEntityDaoImpl.java:59)
        at org.springframework.jdbc.core.RowMapperResultSetExtractor.extractData(RowMapperResultSetExtractor.java:93)
        at org.springframework.jdbc.core.RowMapperResultSetExtractor.extractData(RowMapperResultSetExtractor.java:60)
        at org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(JdbcTemplate.java:693)
        at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:629)
        at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:680)
        at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:712)
        at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:762)
        at org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall.executeCallInternal(PostgresDbEngineDialect.java:154)
        at org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall.doExecute(PostgresDbEngineDialect.java:120)
        at org.springframework.jdbc.core.simple.SimpleJdbcCall.execute(SimpleJdbcCall.java:198)
        at org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeImpl(SimpleJdbcCallsHandler.java:147)
        at org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeReadList(SimpleJdbcCallsHandler.java:109)
        at org.ovirt.engine.core.dao.DefaultReadDao.getAll(DefaultReadDao.java:77)
        at org.ovirt.engine.core.bll.tasks.CommandsCacheImpl.initializeCache(CommandsCacheImpl.java:35)
        at org.ovirt.engine.core.bll.tasks.CommandsCacheImpl.keySet(CommandsCacheImpl.java:47)
        at org.ovirt.engine.core.bll.tasks.CommandsRepository.getCommands(CommandsRepository.java:204)
        at org.ovirt.engine.core.bll.tasks.CommandsRepository.handleUnmanagedCommands(CommandsRepository.java:93)

Version-Release number of selected component (if applicable):
rhevm-4.0.4-0.1.el7ev.noarch


Steps to Reproduce:
1. Run network tier2

Comment 1 Dan Kenigsberg 2016-09-04 08:54:23 UTC
This seems to be a regression due to the fixes for bug 1300220. We'll attempt a quick fix, and if it fails, we'd revert those changes.

Comment 2 Meni Yakove 2016-09-05 06:58:53 UTC
Network Tier2 pass on both envs with Arik Hadas fix.

Comment 3 Meni Yakove 2016-09-05 07:47:47 UTC
We got it again so maybe the fix is not good.

Comment 4 Martin Mucha 2016-09-05 08:54:07 UTC
looking quickly at related area I found two places which can cause this exception:

org.ovirt.engine.core.bll.network.cluster.AttachNetworkToClusterCommand#attachLabeledNetwork

org.ovirt.engine.core.bll.network.cluster.DetachNetworkToClusterCommand#detachLabeledNetworksFromClusterHosts

both using:
Collections.singleton

which is (apparently) unsupported by serialization we're using. However this is perfectly normal java construction and should be supported by 'command coordination' framework, and issue should be handled there, because there can be much more errors like this in our codebase.

Comment 5 Oved Ourfali 2016-09-05 13:22:41 UTC
Juan - isn't it a duplicate of Bug 1372952 ?

Comment 6 Dan Kenigsberg 2016-09-05 13:28:50 UTC
Lowering urgency, as this is no new regression in 3.6.9.

Comment 7 Dan Kenigsberg 2016-09-05 13:42:07 UTC
Let's keep this bug to track the network-specific issue (we should avoid using singletonSet). Bug 1372952 should track the general problem in the codebase. In my opinion we should have a unit test making sure that all our objects are de-serializable.

Comment 8 Juan Hernández 2016-09-05 14:38:12 UTC
*** Bug 1372952 has been marked as a duplicate of this bug. ***

Comment 9 Oved Ourfali 2016-09-06 07:04:07 UTC
*** Bug 1372952 has been marked as a duplicate of this bug. ***

Comment 10 Martin Mucha 2016-09-08 09:23:51 UTC
note: if user is facing these deserialization issues, he can clear invalid data from db using following sql statement:

DELETE FROM command_entities;

Comment 11 Meni Yakove 2016-09-10 12:50:06 UTC
rhevm-4.0.4.2-0.1.el7ev.noarch