Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: Redeploying the service module breaks all portal indexer post-processor
I have several OSGi components split into API/SERVICE/WEB modules. I am facing issue when redeploying SERVICE module breaks all Indexer post-processors (located in API modules). During redeployment I can only see STOPPED/STARTED for that particular SERVICE module without any impact on other modules. That SERVICE module contains Indexer. There is no error reported in the log nor in the GoGo Shell (using diag command).
Would it be possible any redeployment of Indexer affects all available post-processors?
Currently I have to fix this by redeploying all API modules (containing those Indexer post-processors).
I am using 7.2.0 GA1
Would it be possible any redeployment of Indexer affects all available post-processors?
Currently I have to fix this by redeploying all API modules (containing those Indexer post-processors).
I am using 7.2.0 GA1
Jan Tošovský:
Not sure: If you create active code in API modules (other than just passive interfaces): Won't you make the API dependent on the SERVICE module, thus create a circular dependency? I'd assume that postprocessors would be somewhat active, and one way or another depend on an actual service implementation to be deployed. I'd rather avoid that and either locate postprocessors within the service module, or in a separate one, where dependency (ideally only on API, but possible on SERVICE) could be managed without any circles.
I am facing issue when redeploying SERVICE module breaks all Indexer post-processors (located in API modules).
Or am I missing something?
<p>I've moved the search related code into dedicated module. But the problem persists. However, it is clear now this is caused by one specific service module, not other service modules. All my service modules looks almost same, I can't see any remarkable difference. Strange.</p>
<p> </p>
<p>Is there any possibility to log some deploying events to more details to inspect what is happening in the background?</p>
<p> </p>
<p>Is there any possibility to log some deploying events to more details to inspect what is happening in the background?</p>
I can list all these post indexer services using GoGo Shell:
services (objectClass=com.liferay.portal.kernel.search.IndexerPostProcessor);
The list is same before and after deploying that particular service. Can I somehow inspect these services (not bundles)? They seem to be somehow deactivated. They can be reactivated just by refreshing the entire bundle in GoGo shell. But as there are couple of them, it is not very convenient as I need to know exact bundle IDs.
services (objectClass=com.liferay.portal.kernel.search.IndexerPostProcessor);
The list is same before and after deploying that particular service. Can I somehow inspect these services (not bundles)? They seem to be somehow deactivated. They can be reactivated just by refreshing the entire bundle in GoGo shell. But as there are couple of them, it is not very convenient as I need to know exact bundle IDs.
If refreshing the bundle works, you might be closer to a solution: I'd look at the kind of dependency you have on your indexer or related components. Look at the @Reference statements.
OSGi is notoriously lazy rewiring components, unless you specify that you always want the best match, even if that means rewiring. Once two components are wired to each other, they stay wired to each other until you undeploy or refresh them. (or unless they're declaring that they want to be rewired on every opportunity to do so). I'd have to look up the appropriate @Reference lingo - I never use them. Last time I've covered them was in a training years ago.
Alternative thought: Or did you hold on to a reference that should have gone away, anywhere else than in the autowired field? OSGi can't do magic if you keep your own references: Having your own reference means that the old object is still there, can't be garbage collected, etc. But it might have been deactivated/unwired already, thus useless... until you "refresh" and get a new one that's properly initialized.
OSGi is notoriously lazy rewiring components, unless you specify that you always want the best match, even if that means rewiring. Once two components are wired to each other, they stay wired to each other until you undeploy or refresh them. (or unless they're declaring that they want to be rewired on every opportunity to do so). I'd have to look up the appropriate @Reference lingo - I never use them. Last time I've covered them was in a training years ago.
Alternative thought: Or did you hold on to a reference that should have gone away, anywhere else than in the autowired field? OSGi can't do magic if you keep your own references: Having your own reference means that the old object is still there, can't be garbage collected, etc. But it might have been deactivated/unwired already, thus useless... until you "refresh" and get a new one that's properly initialized.
I found my breaking service module (BSM) breaks not only indexer post-processors, but also Indexers themselves. And it breaks this stuff even all Indexers are removed from this BSM.
So there remains model.impl and service.impl classes, couple of standard configuration files and some auto-generated stuff.
Configurations are practically same as in other modules.
In my Impl class I use minimum references:
And in my Custom Finder I use
The only link to some Index related stuff is now
in BaseImpl classes (but this is auto-generated content).
This BSM is dependent only on its API module. And it is not referenced in any other module. When it is stopped, nothing else is deactivated.
Really strange.
So there remains model.impl and service.impl classes, couple of standard configuration files and some auto-generated stuff.
Configurations are practically same as in other modules.
In my Impl class I use minimum references:
@ServiceReference(type = DLFileVersionLocalService.class)
private DLFileVersionLocalService dlFileVersionLocalService;@ServiceReference(type = MBMessageLocalService.class)
private MBMessageLocalService mbMessageLocalService;And in my Custom Finder I use
@ServiceReference(type = CustomSQL.class)
private CustomSQL _customSQL;
The only link to some Index related stuff is now
@Indexable(type = IndexableType.REINDEX)in BaseImpl classes (but this is auto-generated content).
This BSM is dependent only on its API module. And it is not referenced in any other module. When it is stopped, nothing else is deactivated.
Really strange.