Related
In SAP Cloud SDK FAQ page, there is a QA about I'm Observing a DefaultHttpClientFactory not a subtype Exception, now I encountered a similar error Provider com.sap.cloud.sdk.cloudplatform.connectivity.CertificateBasedHttpClientFactory not a subtype, however I could not exclude connectivity-scp-cf since this is mandatory?
Any hints how to solve this error?
Caused by: com.sap.core.connectivity.jco.cf.auth.TokenFactory$GetTokenException: Could not get ClientCredentialsGrantAccessToken
at com.sap.core.connectivity.jco.cf.auth.TokenFactory.getClientCredentialsGrantAccessToken(TokenFactory.java:61)
at com.sap.core.connectivity.jco.cf.destination.ConnectivityConfigurationCF.getConfiguration(ConnectivityConfigurationCF.java:72)
... 92 more
Caused by: java.lang.NoClassDefFoundError: com/sap/cloud/security/client/HttpClientFactory : cannot initialize class because prior initialization attempt failed
at com.sap.core.connectivity.jco.cf.auth.TokenFactory.executeTokenExchange(TokenFactory.java:94)
at com.sap.core.connectivity.jco.cf.auth.TokenFactory.getClientCredentialsGrantAccessToken(TokenFactory.java:57)
... 93 more
Caused by: java.lang.ExceptionInInitializerError: java.util.ServiceConfigurationError: com.sap.cloud.security.client.HttpClientFactory: Provider com.sap.cloud.sdk.cloudplatform.connectivity.CertificateBasedHttpClientFactory not a subtype
Interface type com.sap.cloud.security.client.HttpClientFactory is part of dependency com.sap.cloud.security.xsuaa:token-client.
When using SAP Java Buildpack (e.g. for JCo), please make sure to give this dependency a provided scope. Otherwise you'll be experiencing class loading issues like in your current case. For further errors, please attach your mvn dependency:tree.
--- symptoms
When i load my Dll from a subthread of the host app and host app closes, only 1 thread remains when Dll_PROCESS_DETACH called. This is bad. It causes memory leaks and the required cleanup can't be done.
When i load my Dll from MAIN thread of the host app and host app closes,
all threads created in Dll are still running when Dll_PROCESS_DETACH called.
This is good, because i can do all the cleanup work required.
My Dll_PROCESS_ATTACH contains NO code. No thread is created, no API function called.
-- purpose of this Dll, use case
I need a Dll which can run in various host apps where i do not know when
exactly my Dll is loaded and unloaded.
Some of those host appls obviously
load my Dll from within a thread, e.g. this thread is running a script and the script uses exported functions of my Dll.
The general problem is: When the Dll is first loaded from a subthread of host app, it is not unloaded properly, because all threads seemed to be removed when Dll_PROCESS_DETACH called. This just not only causes memory leaks, also it can't do some internal clean up work, stopping threads and doing a final socket connection, used to communicate with a server.
All this works fine, when the Dll is loaded from a main thread (in my test host) or in specific host apps it tested.
Two stack traces of debug sessions of the c++ Dll running in Visual Studio 17.
First is the bad one, where the Dll is loaded froma subthread.
The 2nd is the good one, where the Dll been loaded from main thread.
// exit stack Dll Dll loaded in subthread ; breakpoint in `Dll_PROCESS_DETACH` This is BAD
DllTest.dll!DllTest_app::~DllTest_app() Line 176 C++
[External Code]
DllTest.dll!DllTest_app::destroy() Line 208 C++
DllTest.dll!DllMain(HINSTANCE__ * hModule, unsigned long ul_reason_for_call, void * lpReserved) Line 43 C++
[External Code]
DllTest_test.exe!exit_or_terminate_process(const unsigned int return_code) Line 130 C++
DllTest_test.exe!common_exit(const int return_code, const _crt_exit_cleanup_mode cleanup_mode, const _crt_exit_return_mode return_mode) Line 271 C++
DllTest_test.exe!exit(int return_code) Line 283 C++
[External Code]
// exit stack Dll loaded in mainthread; breakpoint in `Dll_PROCESS_DETACH` This is GOOD
DllTest.dll!DllTest_app::~DllTest_app() Line 175 C++
[External Code]
DllTest.dll!DllTest_app::destroy() Line 208 C++
DllTest.dll!DllMain(HINSTANCE__ * hModule, unsigned long ul_reason_for_call, void * lpReserved) Line 43 C++
[External Code]
DllTest_test.exe!DllTestWrap::Unload(int code, int bdeleteerror) Line 139 C++
DllTest_test.exe!DllTestWrap::~DllTestWrap() Line 66 C++
[External Code]
DllTest_test.exe!_execute_onexit_table::__l22::<lambda>() Line 198 C++
DllTest_test.exe!__crt_seh_guarded_call<int>::operator()<void <lambda>(void),int <lambda>(void) & __ptr64,void <lambda>(void) >(__acrt_lock_and_call::__l3::void <lambda>(void) && setup, _execute_onexit_table::__l22::int <lambda>(void) & action, __acrt_lock_and_call::__l4::void <lambda>(void) && cleanup) Line 199 C++
DllTest_test.exe!__acrt_lock_and_call<int <lambda>(void) >(const __acrt_lock_id lock_id, _execute_onexit_table::__l22::int <lambda>(void) && action) Line 882 C++
DllTest_test.exe!_execute_onexit_table(_onexit_table_t * table) Line 222 C++
DllTest_test.exe!common_exit(const int return_code, const _crt_exit_cleanup_mode cleanup_mode, const _crt_exit_return_mode return_mode) Line 211 C++
DllTest_test.exe!exit(int return_code) Line 283 C++
[External Code]
How to accomplish, that on Dll_PROCESS_DETACH called, all threads created in Dll still running and not terminated, regardless, if Dll is loaded from subthread or mainthread of host app.
Is there something that can be done by compiler- or linker settings, or a workaround ?
Thank you in advance for each hint.
It seems like one of the threads in your app calls exit() which leads to calling ExitProcess() API - https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-exitprocess
As documented in ExitProcess documentation, it terminates all threads and then calls DllMain() with DLL_PROCESS_DETACH.
Calling ExitProcess can also lead to a deadlock, if the terminated threads hold a mutex which the last thread executing DLL_PROCESS_DETACH tries to acquire.
I'm using CXF WSDL2Java (using JAXB to generate Java classes). I now have everything generating my classes fine, but I get INFO messages of the form;
Jun 15, 2016 4:39:16 PM org.apache.cxf.wsdl11.WSDLServiceBuilder checkForWrapped
INFO: Operation <--my operation--> cannot be unwrapped, its wsdl:part/#element reference must match xs:complexType/xs:sequence.
I understand why it can't be unwrapped and don't have the option to "fix" the WSDL, it's already in use as is.
I'd like to pass something in so that I don't see these INFO messages during my build, as it just creates noise for something that's really OK.
How can I run WSDL2Java to avoid this message?
I have created one portlet and i am trying to do deploy, but while doing deployment, I am getting the following error,
Note:I am using liferay-plugins-sdk-6.2-ce-ga6
Please help me out.
SEVERE: Exception sending context destroyed event to listener instance of class com.liferay.portal.kernel.servlet.PluginContextListener
java.lang.ExceptionInInitializerError
at com.liferay.portal.kernel.deploy.hot.HotDeployEvent.initDependentServletContextNames(HotDeployEvent.java:97)
at com.liferay.portal.kernel.deploy.hot.HotDeployEvent.<init>(HotDeployEvent.java:53)
at com.liferay.portal.kernel.servlet.PluginContextListener.fireUndeployEvent(PluginContextListener.java:170)
at com.liferay.portal.kernel.servlet.PluginContextListener.doPortalDestroy(PluginContextListener.java:132)
at com.liferay.portal.kernel.util.BasePortalLifecycle.portalDestroy(BasePortalLifecycle.java:31)
at com.liferay.portal.kernel.servlet.PluginContextListener.contextDestroyed(PluginContextListener.java:97)
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:4980)
at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5626)
at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1028)
at org.apache.catalina.startup.HostConfig.deleteRedeployResources(HostConfig.java:1299)
at org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1229)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1439)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:315)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.NullPointerException
at com.liferay.portal.kernel.util.PropsUtil.get(PropsUtil.java:32)
at com.liferay.portal.kernel.deploy.hot.DependencyManagementThreadLocal.<clinit>(DependencyManagementThreadLocal.java:40)
... 21 more
May 27, 2016 2:21:54 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/Sample-portlet] created a ThreadLocal with key of type [com.liferay.portal.kernel.util.CentralizedThreadLocal.ThreadLocalMapThreadLocal] (value [com.liferay.portal.kernel.util.CentralizedThreadLocal$ThreadLocalMapThreadLocal#32b11adf]) and a value of type [com.liferay.portal.kernel.util.CentralizedThreadLocal.ThreadLocalMap] (value [com.liferay.portal.kernel.util.CentralizedThreadLocal$ThreadLocalMap#95b4079]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
After googling a while I found that this type of error comes sometimes when you have duplicated the portal-service.jar so make sure this dendency in your pom is set to provided
I am new to Liferay. I am working on a task, in that I need to convert the list content in XML to liferay article. In short, I am converting huge list of content into Liferay article.
I have developed a portal, through that I am importing a content into liferay. During importing time,few minutes successfully import the content into liferay. After few minutes, I got below exception. I have tried many times to import, But I failed to import complete content into liferay.
importing:java.lang.ArrayIndexOutOfBoundsException
Aug 27, 2015 9:38:16 AM org.apache.catalina.core.ApplicationDispatcher invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.NullPointerException
atcom.liferay.portal.service.permission.PortletPermissionImpl.contains(PortletPermissionImpl.java:305)
atcom.liferay.portal.service.permission.PortletPermissionImpl.contains(PortletPermissionImpl.java:226)
atcom.liferay.portal.service.permission.PortletPermissionImpl.contains(PortletPermissionImpl.java:211)
atcom.liferay.portal.service.permission.PortletPermissionImpl.hasAccessPermission(PortletPermissionImpl.java:436)
atcom.liferay.portal.service.permission.PortletPermissionUtil.hasAccessPermission(PortletPermissionUtil.java:278)
atcom.liferay.portlet.SecurityPortletContainerWrapper.hasAccessPermission(SecurityPortletContainerWrapper.java:344)
atcom.liferay.portlet.SecurityPortletContainerWrapper.check(SecurityPortletContainerWrapper.java:209)
atcom.liferay.portlet.SecurityPortletContainerWrapper.checkRender(SecurityPortletContainerWrapper.java:243)
atcom.liferay.portlet.SecurityPortletContainerWrapper.render(SecurityPortletContainerWrapper.java:139)
atcom.liferay.portlet.RestrictPortletContainerWrapper.render(RestrictPortletContainerWrapper.java:126)
atcom.liferay.portal.kernel.portlet.PortletContainerUtil.render(PortletContainerUtil.java:156)
atcom.liferay.portal.layoutconfiguration.util.PortletRenderer._render(PortletRenderer.java:125)
atcom.liferay.portal.layoutconfiguration.util.PortletRenderer.access$4(PortletRenderer.java:107)
atcom.liferay.portal.layoutconfiguration.util.PortletRenderer$PortletRendererCallable.doCall(PortletRenderer.java:180)
atcom.liferay.portal.layoutconfiguration.util.PortletRenderer$PortletRendererCallable.doCall(PortletRenderer.java:1)
atcom.liferay.portal.kernel.executor.CopyThreadLocalCallable.call(CopyThreadLocalCallable.java:69)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
atcom.liferay.portal.kernel.concurrent.ThreadPoolExecutor$WorkerTask._runTask(ThreadPoolExecutor.java:682)
atcom.liferay.portal.kernel.concurrent.ThreadPoolExecutor$WorkerTask.run(ThreadPoolExecutor.java:593)
at java.lang.Thread.run(Thread.java:745)
09:38:16,735 ERROR [http-bio-9001-exec-134][status_jsp:753] javax.servlet.ServletException: java.util.concurrent.ExecutionException: com.liferay.portal.kernel.portlet.PortletContainerException: com.liferay.portal.kernel.portlet.PortletContainerException: java.lang.NullPointerException
As a workaround of this, you can consider increasing the max queue size:
index.search.writer.max.queue.size=9999999
Also, you can add the following which makes disk writes less often:
lucene.commit.batch.size=10000
lucene.commit.time.interval=300000
You can consider referring this defect notes for more information.
Cheers!
AJ
P.S. This is just a possible workaround or tuning thing, but I think there would be a better solution somewhere in case the above is not.