Why camel routes start and stops on its own? - apache-camel
My jar is deployed in jboss fuse server, i have installed it using osgi command. But DefaultShutdownStrategy does gracefull shutdown of my camel routes and again my routes starts and then againg gets shutdown, how should i find whats wrong with my camel route?
16:23:46,095 | INFO | 4 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: DLC_Error_Handler shutdown complete, was consuming from: Endpoint[direct://DLCErrorHandler]
16:23:46,095 | INFO | 4 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: LogCreateAccountResponse shutdown complete, was consuming from: Endpoint[seda://logCreateAccountResp]
16:23:46,095 | INFO | 4 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: LogCreateAccountRequest shutdown complete, was consuming from: Endpoint[seda://logCreateAccountReq]
16:23:46,095 | INFO | 4 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: LogCRMResponse shutdown complete, was consuming from: Endpoint[seda://logCRMRequest]
16:23:46,095 | INFO | 4 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: SendCRMResponse shutdown complete, was consuming from: Endpoint[direct://sendResponse]
16:23:46,095 | INFO | 4 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: CreateAccountContract shutdown complete, was consuming from: Endpoint[direct://createAccountContract]
16:23:46,095 | INFO | 4 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: GetNonRecCharges shutdown complete, was consuming from: Endpoint[direct://getNonRecCharges]
16:23:46,095 | INFO | 4 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: GetRateClassList shutdown complete, was consuming from: Endpoint[direct://getRateClassList]
16:23:46,095 | INFO | 4 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: getRecCharges shutdown complete, was consuming from: Endpoint[direct://getRecCharges]
16:23:46,095 | INFO | 4 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: GetBillingCharges shutdown complete, was consuming from: Endpoint[direct://getBillingCharges]
16:23:46,095 | INFO | 4 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: GetRatePlan shutdown complete, was consuming from: Endpoint[direct://getRatePlanDetails]
16:23:46,095 | INFO | 4 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: MainRoute shutdown complete, was consuming from: Endpoint[activemq://queue:createAccountContract]
16:23:46,095 | INFO | Thread-358 | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Graceful shutdown of 12 routes completed in 4 seconds
16:23:50,742 | INFO | rint Extender: 1 | BlueprintCamelContext | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: MainRoute started and consuming from: Endpoint[activemq://queue:createAccountContract]
16:23:50,743 | INFO | rint Extender: 1 | BlueprintCamelContext | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: GetRatePlan started and consuming from: Endpoint[direct://getRatePlanDetails]
16:23:50,743 | INFO | rint Extender: 1 | BlueprintCamelContext | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: GetBillingCharges started and consuming from: Endpoint[direct://getBillingCharges]
16:23:50,743 | INFO | rint Extender: 1 | BlueprintCamelContext | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: getRecCharges started and consuming from: Endpoint[direct://getRecCharges]
16:23:50,744 | INFO | rint Extender: 1 | BlueprintCamelContext | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: GetRateClassList started and consuming from: Endpoint[direct://getRateClassList]
16:23:50,744 | INFO | rint Extender: 1 | BlueprintCamelContext | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: GetNonRecCharges started and consuming from: Endpoint[direct://getNonRecCharges]
16:23:50,744 | INFO | rint Extender: 1 | BlueprintCamelContext | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: CreateAccountContract started and consuming from: Endpoint[direct://createAccountContract]
16:23:50,745 | INFO | rint Extender: 1 | BlueprintCamelContext | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: SendCRMResponse started and consuming from: Endpoint[direct://sendResponse]
16:23:50,745 | INFO | rint Extender: 1 | BlueprintCamelContext | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: LogCRMResponse started and consuming from: Endpoint[seda://logCRMRequest]
16:23:50,747 | INFO | rint Extender: 1 | BlueprintCamelContext | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: LogCreateAccountRequest started and consuming from: Endpoint[seda://logCreateAccountReq]
16:23:50,747 | INFO | rint Extender: 1 | BlueprintCamelContext | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: LogCreateAccountResponse started and consuming from: Endpoint[seda://logCreateAccountResp]
16:23:50,748 | INFO | rint Extender: 1 | BlueprintCamelContext | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: DLC_Error_Handler started and consuming from: Endpoint[direct://DLCErrorHandler]
16:23:50,748 | INFO | rint Extender: 1 | BlueprintCamelContext | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Total 12 routes, of which 12 are started.
16:23:50,748 | INFO | rint Extender: 1 | BlueprintCamelContext | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Apache Camel 2.17.0.redhat-630187 (CamelContext: camel-85) started in 4.572 seconds
16:23:50,752 | INFO | Thread-360 | BlueprintCamelContext | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Apache Camel 2.17.0.redhat-630187 (CamelContext: camel-85) is shutting down
16:23:50,753 | INFO | Thread-360 | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Starting to graceful shutdown 12 routes (timeout 300 seconds)
16:23:53,186 | INFO | qtp1920375558-80 | route1 | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Create Account Contract Request received : <?xml version="1.0" encoding="UTF-8" standalone="yes"?>n | <CreateAccountContractRequest>n | <CAF_No>CAF_31883</CAF_No>n | <CAN_No>9165199</CAN_No>n | <CreateAccountContractDetails>n | <subsNo>17954</subsNo>n | <ratePlanID>ENT_BIA100</ratePlanID>n | <servicegroupno>15452</servicegroupno>n | <startDate>2017-10-08T00:00:00+05:30</startDate>n | <RCAmount>75000.0</RCAmount>n | <NRCAmount>25000.0</NRCAmount>n | </CreateAccountContractDetails>n | <SessionObject>n | <ipAddress>10.158.103.4</ipAddress>n | <userName>admin</userName>n | <usrNo>1</usrNo>n | </SessionObject>n | </CreateAccountContractRequest>n |
16:23:53,231 | INFO | qtp1920375558-80 | route1 | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | send request onto the queue
16:23:54,793 | INFO | 9 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: DLC_Error_Handler shutdown complete, was consuming from: Endpoint[direct://DLCErrorHandler]
16:23:54,793 | INFO | 9 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: LogCreateAccountResponse shutdown complete, was consuming from: Endpoint[seda://logCreateAccountResp]
16:23:54,793 | INFO | 9 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: LogCreateAccountRequest shutdown complete, was consuming from: Endpoint[seda://logCreateAccountReq]
16:23:54,793 | INFO | 9 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: LogCRMResponse shutdown complete, was consuming from: Endpoint[seda://logCRMRequest]
16:23:54,793 | INFO | 9 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: SendCRMResponse shutdown complete, was consuming from: Endpoint[direct://sendResponse]
16:23:54,793 | INFO | 9 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: CreateAccountContract shutdown complete, was consuming from: Endpoint[direct://createAccountContract]
16:23:54,793 | INFO | 9 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: GetNonRecCharges shutdown complete, was consuming from: Endpoint[direct://getNonRecCharges]
16:23:54,793 | INFO | 9 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: GetRateClassList shutdown complete, was consuming from: Endpoint[direct://getRateClassList]
16:23:54,793 | INFO | 9 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: getRecCharges shutdown complete, was consuming from: Endpoint[direct://getRecCharges]
16:23:54,793 | INFO | 9 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: GetBillingCharges shutdown complete, was consuming from: Endpoint[direct://getBillingCharges]
16:23:54,793 | INFO | 9 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: GetRatePlan shutdown complete, was consuming from: Endpoint[direct://getRatePlanDetails]
16:23:54,793 | INFO | 9 - ShutdownTask | DefaultShutdownStrategy | 232 - org.apache.camel.camel-core - 2.17.0.redhat-630187 | Route: MainRoute shutdown complete, was consuming from: Endpoint[activemq://queue:createAccountContract]
Related
In vertica, Is there any way to access admintools without admin rights?
In vertica, Is there any way to access admintools without admin rights?. How to find nodes and cluster configure details in normal user in vertica?
You might have already tried it. You must have access to the Linux shell level on one of the Vertica nodes, as a user that is allowed to write to /opt/vertica/log/adminTools.log . And that is, by default, dbadmin. I would regard it as quite a security risk to tamper with the permissions around that, really. A good start would be: $ vsql -U <user> -w <pwd> -h 127.127.127.128 -d dbnm -x -c "select * from host_resources" -[ RECORD 1 ]------------------+----------------------------------------- host_name | 127.127.127.128 open_files_limit | 65536 threads_limit | 7873 core_file_limit_max_size_bytes | 0 processor_count | 1 processor_core_count | 2 processor_description | Intel(R) Xeon(R) CPU E5-2670 0 # 2.60GHz opened_file_count | 7 opened_socket_count | 10 opened_nonfile_nonsocket_count | 7 total_memory_bytes | 8254820352 total_memory_free_bytes | 1034915840 total_buffer_memory_bytes | 523386880 total_memory_cache_bytes | 5516861440 total_swap_memory_bytes | 2097147904 total_swap_memory_free_bytes | 2097147904 disk_space_free_mb | 425185 disk_space_used_mb | 76682 disk_space_total_mb | 501867 system_open_files | 1440 system_max_files | 798044 -[ RECORD 2 ]------------------+----------------------------------------- host_name | 127.127.127.129 open_files_limit | 65536 threads_limit | 7873 core_file_limit_max_size_bytes | 0 processor_count | 1 processor_core_count | 2 processor_description | Intel(R) Xeon(R) CPU E5-2670 0 # 2.60GHz opened_file_count | 7 opened_socket_count | 9 opened_nonfile_nonsocket_count | 7 total_memory_bytes | 8254820352 total_memory_free_bytes | 1836150784 total_buffer_memory_bytes | 487129088 total_memory_cache_bytes | 4774060032 total_swap_memory_bytes | 2097147904 total_swap_memory_free_bytes | 2097147904 disk_space_free_mb | 447084 disk_space_used_mb | 54783 disk_space_total_mb | 501867 system_open_files | 1408 system_max_files | 798044 -[ RECORD 3 ]------------------+----------------------------------------- host_name | 127.127.127.130 open_files_limit | 65536 threads_limit | 7873 core_file_limit_max_size_bytes | 0 processor_count | 1 processor_core_count | 2 processor_description | Intel(R) Xeon(R) CPU E5-2670 0 # 2.60GHz opened_file_count | 7 opened_socket_count | 9 opened_nonfile_nonsocket_count | 7 total_memory_bytes | 8254820352 total_memory_free_bytes | 1747091456 total_buffer_memory_bytes | 531447808 total_memory_cache_bytes | 4813959168 total_swap_memory_bytes | 2097147904 total_swap_memory_free_bytes | 2097147904 disk_space_free_mb | 451444 disk_space_used_mb | 50423 disk_space_total_mb | 501867 system_open_files | 1408 system_max_files | 798044 In general, check the Vertica docu for system tables and information available there....
AbstractMethodError inTomcat 8
I am getting this error.
Stacktrace:] with root cause
INFO | jvm 1 | 2019/06/06 08:49:59 | java.lang.AbstractMethodError
INFO | jvm 1 | 2019/06/06 08:49:59 | at net.sourceforge.jtds.jdbc.JtdsConnection.isValid(JtdsConnection.java:2833)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.tomcat.dbcp.dbcp2.DelegatingConnection.isValid(DelegatingConnection.java:874)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.tomcat.dbcp.dbcp2.PoolableConnection.validate(PoolableConnection.java:270)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.tomcat.dbcp.dbcp2.PoolableConnectionFactory.validateConnection(PoolableConnectionFactory.java:389)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.validateConnectionFactory(BasicDataSource.java:2398)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createPoolableConnectionFactory(BasicDataSource.java:2381)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.createDataSource(BasicDataSource.java:2110)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1563)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.jsp.startpage_jsp.getDBConnection(startpage_jsp.java:60)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.jsp.startpage_jsp.getUserInfo(startpage_jsp.java:474)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.jsp.startpage_jsp._jspService(startpage_jsp.java:732)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
INFO | jvm 1 | 2019/06/06 08:49:59 | at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:476)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:386)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:330)
INFO | jvm 1 | 2019/06/06 08:49:59 | at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
INFO | jvm 1 | 2019/06/06 08:49:59 | at nl.planon.tomcat.ForgotPasswordFilter.doFilter(ForgotPasswordFilter.java:78)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
INFO | jvm 1 | 2019/06/06 08:49:59 | at nl.planon.webrequestsigner.WebRequestSignerFilter.doFilter(WebRequestSignerFilter.java:67)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:610)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:660)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:240)
INFO | jvm 1 | 2019/06/06 08:49:59 | at nl.planon.owasp.valve.WhitelistHTTPMethodsValve.invoke(WhitelistHTTPMethodsValve.java:72)
INFO | jvm 1 | 2019/06/06 08:49:59 | at nl.planon.owasp.valve.XSSProtectionHeaderValve.invoke(XSSProtectionHeaderValve.java:175)
INFO | jvm 1 | 2019/06/06 08:49:59 | at nl.planon.tomcat.AddHeaderValve.invoke(AddHeaderValve.java:117)
INFO | jvm 1 | 2019/06/06 08:49:59 | at nl.planon.tomcat.ClickjackHostValve.invoke(ClickjackHostValve.java:107)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:798)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
INFO | jvm 1 | 2019/06/06 08:49:59 | at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
INFO | jvm 1 | 2019/06/06 08:49:59 | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
INFO | jvm 1 | 2019/06/06 08:49:59 | at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
INFO | jvm 1 | 2019/06/06 08:49:59 | at java.lang.Thread.run(Thread.java:748)
INFO | jvm 1 | 2019/06/06 08:49:59 |
I found some solutions with adding validationQuery="select 1" to context.xml. But in my context.xml I don't have a resource.
<Context>
<!-- Authenticate against PlanonRealmLogin (JAAS) -->
<!-- allRolesMode=authOnly" means that no role is needed for '*' requirement -->
<Realm appName="PlanonRealmLogin"
className="org.apache.catalina.realm.JAASRealm"
userClassNames="nl.planon.cerebeus.PnUser"
roleClassNames="nl.planon.cerebeus.PnRole"
allRolesMode="authOnly"/>
<!--Valve className="nl.planon.tomcat.AccessKeyValve" throttle="5000"/-->
<!--Valve className="nl.planon.tomcat.ForgotPasswordLoginValve"/-->
<!-- Will force authentication attempts to be parsed as UTF-8. The Landingpage will prevent HTTP 408 messages
because now, even without a stored original location, Tomcat knows where to forward to. -->
<!-- exceptionAttributeName="PnLoginException"-->
<Valve className="nl.planon.tomcat.PnMessageFormAuthenticator" landingPage="/" characterEncoding="utf-8"/>
<!-- This valve excludes valid webdav users with role webdav_readwrite to enter the web application(s) -->
<!--Valve className="nl.planon.tomcat.ExcludingRoleValve"/-->
<!--Parameter name="trustedServiceKeystore" value="${catalina.home}/webclientKeystore.jks" />
<Parameter name="trustedServiceName" value="webclient" /-->
<Manager pathname="" />
<ResourceLink
name="jdbc/PlanonDS"
global="jdbc/PlanonDS"
type="javax.sql.DataSource" />
<!-- Whitelist the minimal set of HTTP Methods that Web Bootstrap needs -->
<!--Valve className="nl.planon.owasp.valve.WhitelistHTTPMethodsValve" methods="GET, OPTIONS, HEAD, POST, PUT, DELETE" /-->
In my server.xml I have mentioned resource.
<GlobalNamingResources>
<!-- Editable user database that can also be used by
UserDatabaseRealm to authenticate users
-->
<Resource auth="Container" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" name="UserDatabase" pathname="conf/tomcat-users.xml" type="org.apache.catalina.UserDatabase"/>
<Resource name="jdbc/PlanonDS"
auth="Container"
type="javax.sql.DataSource"
username=""
password=""
driverClassName="net.sourceforge.jtds.jdbc.Driver"
url="jdbc:jtds:sqlserver://SZH1DB;instance=planon"
validationQuery="select 1"
maxActive="8"
maxIdle="4"/>
Here I have used validationQuery="select 1". But still I get the same error.
Can someone help me with this error?
READ UNCOMMITTED isolation level behavior on more than one transaction
I have a stored procedure to update a table, and i set the isolation level to READ UNCOMMITTED. In this sp i set the comment count (CommentCount+=1). If more than one user call this sp at the same time, is it possible that comment count increase less than number of user that added comment?
SQL Server still acquires locks on updated rows in the READ UNCOMMITTED isolation level. An UPDATE statement like this will not miss increments when executed by multiple READ UNCOMMITTED sessions concurrently: UPDATE dbo.Post SET CommentCount += 1 WHERE PostID = #PostID; Here's a trace of locks by this statement, updating by a clustered primary key on PostID. The exclusive lock will block other concurrent updates to the row. +---------------+----+--------------+----------+--+ | Lock:Acquired | 58 | 5 - OBJECT | 8 - IX | | | Lock:Acquired | 58 | 6 - PAGE | 8 - IX | | | Lock:Acquired | 58 | 7 - KEY | 5 - X | | | Lock:Released | 58 | 7 - KEY | 0 - NULL | | | Lock:Released | 58 | 6 - PAGE | 0 - NULL | | | Lock:Released | 58 | 7 - KEY | 5 - X | | | Lock:Released | 58 | 6 - PAGE | 8 - IX | | | Lock:Released | 58 | 5 - OBJECT | 8 - IX | | +---------------+----+--------------+----------+--+ And here's a trace where the row is located using a non-clustered primary key index. The update lock on the non-clustered key will serialize other update statements for the same key and the exclusive lock on the clustered key will block other data modifications. +---------------+----+------------+----------+--+ | Lock:Acquired | 58 | 5 - OBJECT | 8 - IX | | | Lock:Acquired | 58 | 6 - PAGE | 7 - IU | | | Lock:Acquired | 58 | 7 - KEY | 4 - U | | | Lock:Acquired | 58 | 6 - PAGE | 7 - IU | | | Lock:Acquired | 58 | 7 - KEY | 4 - U | | | Lock:Acquired | 58 | 6 - PAGE | 8 - IX | | | Lock:Acquired | 58 | 7 - KEY | 5 - X | | | Lock:Released | 58 | 7 - KEY | 0 - NULL | | | Lock:Released | 58 | 6 - PAGE | 0 - NULL | | | Lock:Released | 58 | 7 - KEY | 4 - U | | | Lock:Released | 58 | 6 - PAGE | 7 - IU | | | Lock:Released | 58 | 7 - KEY | 5 - X | | | Lock:Released | 58 | 6 - PAGE | 8 - IX | | | Lock:Released | 58 | 5 - OBJECT | 8 - IX | | +---------------+----+------------+----------+--+
Query now extremely slow after server change
After changing servers, we are now experiencing extremely slow execution times for just one query. When we analyze the sessions during the runtime, we see hundreds (sometimes over 1000) open sessions all with the same session id and they are blocking themselves. Here is an extract: +----------------------+------------+-----------------+------------------+-----------+--------------------+-----------------------+---------------------+--------------------------+--------------------------------------------------------------------+ | waiting_task_address | session_id | exec_context_id | wait_duration_ms | wait_type | resource_address | blocking_task_address | blocking_session_id | blocking_exec_context_id | resource_description | +----------------------+------------+-----------------+------------------+-----------+--------------------+-----------------------+---------------------+--------------------------+--------------------------------------------------------------------+ | 0x00000005A3B83468 | 161 | 19 | 121058 | CXPACKET | 0x0000000EB9B9C830 | 0x00000010BF029C28 | 161 | 3 | exchangeEvent id=Pipe8a2d88200 WaitType=e_waitPipeNewRow nodeId=12 | | 0x00000010BE003C28 | 161 | 10 | 121079 | CXPACKET | 0x00000008A1A0E9C0 | 0x00000005734964E8 | 161 | 93 | exchangeEvent id=Pipe79fcc6200 WaitType=e_waitPipeNewRow nodeId=8 | | 0x000000050BFA1088 | 161 | 42 | 121092 | CXPACKET | 0x000000058C7C12D0 | 0x00000010B484A8C8 | 161 | 27 | exchangeEvent id=Pipe5647e2110 WaitType=e_waitPipeNewRow nodeId=15 | | 0x0000000DFB199088 | 161 | 20 | 121094 | CXPACKET | 0x0000000E77A4DCC0 | 0x00000005A3B82CA8 | 161 | 44 | exchangeEvent id=Pipe915578ed0 WaitType=e_waitPipeGetRow nodeId=15 | | 0x0000000E501A64E8 | 161 | 66 | 121094 | CXPACKET | 0x000000088DB9DCB0 | 0x0000000E44591C28 | 161 | 81 | exchangeEvent id=Pipe79fcc8d00 WaitType=e_waitPipeGetRow nodeId=5 | | 0x0000000E501A64E8 | 161 | 66 | 121094 | CXPACKET | 0x000000088DB9DCB0 | 0x00000003714868C8 | 161 | 82 | exchangeEvent id=Pipe79fcc8d00 WaitType=e_waitPipeGetRow nodeId=5 | | 0x0000000E501A64E8 | 161 | 66 | 121094 | CXPACKET | 0x000000088DB9DCB0 | 0x0000000DC854B848 | 161 | 83 | exchangeEvent id=Pipe79fcc8d00 WaitType=e_waitPipeGetRow nodeId=5 | | 0x0000000E501A64E8 | 161 | 66 | 121094 | CXPACKET | 0x000000088DB9DCB0 | 0x00000010B3A25848 | 161 | 84 | exchangeEvent id=Pipe79fcc8d00 WaitType=e_waitPipeGetRow nodeId=5 | | 0x0000000E501A64E8 | 161 | 66 | 121094 | CXPACKET | 0x000000088DB9DCB0 | 0x0000000F39DFA4E8 | 161 | 85 | exchangeEvent id=Pipe79fcc8d00 WaitType=e_waitPipeGetRow nodeId=5 | +----------------------+------------+-----------------+------------------+-----------+--------------------+-----------------------+---------------------+--------------------------+--------------------------------------------------------------------+ I am not sure what causes this. The problem didn't exist before moving the server. We had a short period of time during which the query executed fast on the current server and now have the problem of slow execution times again.
Have you compared execution plans? If you have upgraded SQL to a newer version have you updated statistics? If these are different servers with the same database is the data the same? Is the indexing the same? I used to run a replication topology and would delete unused indexes on subscribers. The self blocking isn't really blocking. I think they introduced it in SQL 2005 and it's just slowness.
In Which File SolrConfig.xml file path is configured?
I am getting org.apache.solr.common.SolrException: Could not load config file C:\nemoCode\sceneric-hybris\hybris\config\solr\embedded\solrconfig.xml INFO | jvm 1 | main | 2017/05/23 11:54:01.550 | at org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:530) INFO | jvm 1 | main | 2017/05/23 11:54:01.550 | at org.apache.solr.core.CoreContainer.create(CoreContainer.java:597) INFO | jvm 1 | main | 2017/05/23 11:54:01.550 | at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:251) INFO | jvm 1 | main | 2017/05/23 11:54:01.550 | at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:243) INFO | jvm 1 | main | 2017/05/23 11:54:01.550 | at java.util.concurrent.FutureTask.run(FutureTask.java:262) INFO | jvm 1 | main | 2017/05/23 11:54:01.551 | at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) INFO | jvm 1 | main | 2017/05/23 11:54:01.551 | at java.util.concurrent.FutureTask.run(FutureTask.java:262) INFO | jvm 1 | main | 2017/05/23 11:54:01.551 | at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) INFO | jvm 1 | main | 2017/05/23 11:54:01.551 | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) INFO | jvm 1 | main | 2017/05/23 11:54:01.551 | at java.lang.Thread.run(Thread.java:745) INFO | jvm 1 | main | 2017/05/23 11:54:01.551 | Caused by: java.io.IOException: Can't find resource 'solrconfig.xml' in classpath or 'C:\nemoCode\sceneric-hybris\hybris\config\solr\embedded\conf' INFO | jvm 1 | main | 2017/05/23 11:54:01.552 | at org.apache.solr.core.SolrResourceLoader.openResource(SolrResourceLoader.java:342) INFO | jvm 1 | main | 2017/05/23 11:54:01.552 | at org.apache.solr.core.SolrResourceLoader.openConfig(SolrResourceLoader.java:288) INFO | jvm 1 | main | 2017/05/23 11:54:01.552 | at org.apache.solr.core.Config.<init>(Config.java:116) INFO | jvm 1 | main | 2017/05/23 11:54:01.552 | at org.apache.solr.core.Config.<init>(Config.java:86) INFO | jvm 1 | main | 2017/05/23 11:54:01.553 | at org.apache.solr.core.SolrConfig.<init>(SolrConfig.java:139) INFO | jvm 1 | main | 2017/05/23 11:54:01.553 | at org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:527) INFO | jvm 1 | main | 2017/05/23 11:54:01.553 | ... 9 more But I dont have that path in my c drive. Where it is configured that it should serach from that perticular file path???
I think that the path is configured inside your solr.xml , you will find it inside ${HYBRIS_CONFIG_DIR}/solr/embedded/solr.xml
The solr.xml file specifies configuration options for each Solr core, including configuration options for multiple cores. The file also contains mappings for request URLs, and indicates which cores to load when the server starts.
so check the instanceDir and dataDir of one of your cores
An example of core inside solr.xml
<core name="master_apparel-de_Product"
instanceDir="A:\source\hybris.5.2.0\hybris\config/solr/embedded"
dataDir="A:\source\hybris.5.2.0\hybris\data\solrfacetsearch\MASTER\apparel-de_Product_1"/>
This is not a usual location for solrconfig.xml. Usually the location is: [solr.home]/[corename]/conf/solrconfig.xml It is possible to deviate from that by changing config property in the core.properties files that is just in the [corename] directory. That location can be relative which is what may be causing you some issues.