To allow PG to support near real time reporting and rendering, we should engineer the server to reduce the reliance on continuous polling of the REST endpoints and ideally to be able to work on top of a read only slave database. 1. Implement JMS queues to notify clients of various events like updated topics and content specs. 2. Look at implementing the HornetQ REST server (http://docs.jboss.org/hornetq/2.4.0.Final/docs/user-manual/html_single/#d0e12353) to allow us to use message queues while allowing us share features like security. 3. Implement appropriate HTTP response codes for REST endpoints that modify the database when running on top of a read only slave database. 4. Configure a VM hosting a slave MariaDB database and PG server that can be used for read only operations like reporting and rendering.
Hibernate search will have to either be replaced with SQL free text searches (https://dev.mysql.com/doc/refman/5.0/en/fulltext-natural-language.html) or have some way to trigger updates of the index on a read only slave.
The following has been implemented: A HornetQ REST server project has been created that allows access to the JMS topics via a REST interface. This is a separate project because it is a generic application that could be deployed to any EAP server that uses HornetQ. An EJB (UpdatedEntities) has been created to query the database for updated topics and spec, and post notifications to the JMS topics. Hibernate search has been removed. I suspect that very few people were using it, and the work required to coordinate entity changes and index updates between servers would not have been worth it. If anyone objects to this we can look at putting the code back in or using an alternative like the free text search in MariaDB. A new entry has been added to the application config file called "readonly". When set to true, and POST, PUT or DELETE methods return FORBIDDEN. See RESTv1ReadOnlyInterceptor.
How to test. Keywords -------- Since there is no longer a lucene index, the keyword generation was changed to use lucene directly. This can be checked with a call that returns a topic with an expanded keywords collection. http://localhost:8080/pressgang-ccms/rest/1/topic/get/json/33?expand=%7B%22branches%22%3A%5B%7B%22trunk%22%3A%7B%22name%22%3A+%22keywords%22%7D%7D%5D%7D Readonly Endpoints ------------------ Add the line readonly=true to application.properties, and confirm that calls that modify any entities are forbidden. Messaging --------- To test the HornetQ REST API, see http://hornetq.jboss.org/rest.html.
You can also test the HornetQ REST API by running the code at https://github.com/mcasperson/DocBuilderLive. Although DocBuilderLive is only a test, it does monitor the JSM topics via the HornetQ API, so you can observe the calls and responses.
The RESTServerSettingsV1 has been updated to include the readOnly setting. The dedicated endpoint has been removed. All calls to endpoints whose paths start with "/settings" are allowed regardless of the readonly state of the server. The interceptor is now called org.jboss.pressgang.ccms.server.interceptor.ReadOnlyInterceptor.
The frequency with which the queries that populate the JMS topics are run is now exposed through the application config, and can be modified at runtime.
I have found an issue with the HornetQ REST interface losing its connection. https://community.jboss.org/message/874085#874085
The above might be fixed with. I have set this on the dev server and will have to monitor the logs for errors. <connection-factory name="InVmConnectionFactory"> <connectors> <connector-ref connector-name="in-vm"/> </connectors> <entries> <entry name="java:/ConnectionFactory"/> </entries> <connection-ttl>-1</connection-ttl> </connection-factory>
> 4. Configure a VM hosting a slave MariaDB database and PG server that can be used for read only operations like reporting and rendering. This will have to be moved to a future bug.
Server settings that define the JMS topics in standalone-full.xml file are <jms-destinations> <jms-topic name="UpdatedTopic"> <entry name="java:jboss/topics/updatedtopic"/> </jms-topic> <jms-topic name="UpdatedSpec"> <entry name="java:jboss/topics/updatedspec"/> </jms-topic> </jms-destinations> Also need to set connection-ttl <connection-factory name="InVmConnectionFactory"> <connectors> <connector-ref connector-name="in-vm"/> </connectors> <entries> <entry name="java:/ConnectionFactory"/> </entries> <connection-ttl>-1</connection-ttl> </connection-factory>
The JMS details should be deployed as a *-jms.xml file. See https://github.com/jboss-developer/jboss-eap-quickstarts/blob/jdf-2.1.9.Final/helloworld-mdb/src/main/webapp/WEB-INF/hornetq-jms.xml
Ran into the following error while adding indexes to a large table. Setting <connection-ttl>-1</connection-ttl> is supposed to fix this (see https://issues.jboss.org/browse/HORNETQ-1314). I've added <connection-ttl>-1</connection-ttl> to the pooled connection factory to see if it addresses the issue. <pooled-connection-factory name="hornetq-ra"> <transaction mode="xa"/> <connectors> <connector-ref connector-name="in-vm"/> </connectors> <entries> <entry name="java:/JmsXA"/> </entries> <connection-ttl>-1</connection-ttl> </pooled-connection-factory> Error Log: [0m[0m09:20:21,644 INFO [liquibase.integration.cdi.CDILiquibase] (MSC service thread 1-7) Booting Liquibase 3.1.1 [0m[0m09:20:53,567 INFO [liquibase] (MSC service thread 1-7) Successfully acquired change log lock [0m[0m09:21:02,673 INFO [liquibase] (MSC service thread 1-7) Reading from Skynet.DATABASECHANGELOG [0m[0m09:21:02,704 INFO [liquibase] (MSC service thread 1-7) Reading from Skynet.DATABASECHANGELOG [0m[0m09:21:02,967 INFO [liquibase] (MSC service thread 1-7) Reading from Skynet.DATABASECHANGELOG [0m[0m09:21:02,984 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.0.xml::1::lnewson: Reading from Skynet.DATABASECHANGELOG [0m[0m09:21:03,316 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.0.xml::1::lnewson: Custom SQL executed [0m[0m09:21:03,317 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.0.xml::1::lnewson: ChangeSet db/changelog/db.changelog-1.0.xml::1::lnewson ran successfully in 320ms [0m[0m09:21:05,426 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.0.xml::1::lnewson: Reading from Skynet.DATABASECHANGELOG [0m[0m09:21:05,444 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.0.xml::2::lnewson: Reading from Skynet.DATABASECHANGELOG [0m[0m09:21:05,460 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.0.xml::2::lnewson: Custom SQL executed [0m[0m09:21:05,461 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.0.xml::2::lnewson: ChangeSet db/changelog/db.changelog-1.0.xml::2::lnewson ran successfully in 2ms [0m[0m09:21:12,772 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.0.xml::2::lnewson: Reading from Skynet.DATABASECHANGELOG [0m[0m09:21:12,783 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.0.xml::3::lnewson: Reading from Skynet.DATABASECHANGELOG [0m[0m09:21:12,792 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.0.xml::3::lnewson: Custom SQL executed [0m[0m09:21:12,792 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.0.xml::3::lnewson: Custom SQL executed [0m[0m09:21:12,792 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.0.xml::3::lnewson: ChangeSet db/changelog/db.changelog-1.0.xml::3::lnewson ran successfully in 1ms [0m[0m09:21:21,528 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.0.xml::3::lnewson: Reading from Skynet.DATABASECHANGELOG [0m[0m09:21:21,548 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.6.xml::1::mcaspers: Reading from Skynet.DATABASECHANGELOG [0m[0m09:21:24,528 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.6.xml::1::mcaspers: Index ContentHash created [0m[0m09:21:25,800 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.6.xml::1::mcaspers: Index ContentHash created [0m[0m09:21:37,662 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.6.xml::1::mcaspers: Index ContentHash created [0m[0m09:21:39,274 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.6.xml::1::mcaspers: Index ContentHash created [0m[0m09:22:38,440 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.6.xml::1::mcaspers: Index ContentHash created [0m[33m09:30:15,476 WARN [org.hornetq.core.client] (Thread-3 (HornetQ-client-global-threads-931255825)) HQ212037: Connection failure has been detected: HQ119011: Did not receive data from server for InVMConnection [serverID=0, id=6728dce8-e13e-11e3-bf54-c36f63498820] [code=CONNECTION_TIMEDOUT] [0m[33m09:30:16,819 WARN [org.hornetq.jms.server] (Thread-3 (HornetQ-client-global-threads-931255825)) Notified of connection failure in xa discovery, we will retry on the next recovery: HornetQException[errorType=CONNECTION_TIMEDOUT message=HQ119011: Did not receive data from server for InVMConnection [serverID=0, id=6728dce8-e13e-11e3-bf54-c36f63498820]] at org.hornetq.core.client.impl.ClientSessionFactoryImpl$PingRunnable.run(ClientSessionFactoryImpl.java:1730) [hornetq-core-client-2.3.1.Final-redhat-1.jar:2.3.1.Final-redhat-1] at org.hornetq.core.client.impl.ClientSessionFactoryImpl$ActualScheduledPinger.run(ClientSessionFactoryImpl.java:1698) [hornetq-core-client-2.3.1.Final-redhat-1.jar:2.3.1.Final-redhat-1] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25] at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) [rt.jar:1.7.0_25] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) [rt.jar:1.7.0_25] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_25] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.7.0_25] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] [0m[33m09:30:17,081 WARN [org.hornetq.core.client] (hornetq-failure-check-thread) HQ212037: Connection failure has been detected: HQ119014: Did not receive data from invm:0. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=CONNECTION_TIMEDOUT] [0m[33m09:30:17,082 WARN [org.hornetq.core.server] (hornetq-failure-check-thread) HQ222061: Client connection failed, clearing up resources for session b1c73045-e13e-11e3-bf54-c36f63498820 [0m[33m09:30:17,084 WARN [org.hornetq.core.server] (hornetq-failure-check-thread) HQ222107: Cleared up resources for session b1c73045-e13e-11e3-bf54-c36f63498820 [0m[33m09:30:17,084 WARN [org.hornetq.core.client] (hornetq-failure-check-thread) HQ212037: Connection failure has been detected: HQ119014: Did not receive data from invm:0. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=CONNECTION_TIMEDOUT] [0m[33m09:30:17,085 WARN [org.hornetq.jms.server] (Thread-3 (HornetQ-client-global-threads-931255825)) HQ122014: Notified of connection failure in xa recovery connectionFactory for provider ClientSessionFactoryImpl [serverLocator=ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=673008d9-e13e-11e3-bf54-c36f63498820, factory=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory) ?server-id=0], discoveryGroupConfiguration=null], connectorConfig=TransportConfiguration(name=673008d9-e13e-11e3-bf54-c36f63498820, factory=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory) ?server-id=0, backupConfig=null] will attempt reconnect on next pass: HornetQException[errorType=NOT_CONNECTED message=HQ119006: Channel disconnected] at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:418) [hornetq-core-client-2.3.1.Final-redhat-1.jar:2.3.1.Final-redhat-1] at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:214) [hornetq-server-2.3.1.Final-redhat-1.jar:2.3.1.Final-redhat-1] at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:106) [hornetq-core-client-2.3.1.Final-redhat-1.jar:2.3.1.Final-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] [0m[33m09:30:17,086 WARN [org.hornetq.core.client] (hornetq-failure-check-thread) HQ212037: Connection failure has been detected: HQ119014: Did not receive data from invm:0. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=CONNECTION_TIMEDOUT] [0m[0m09:55:19,958 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.6.xml::1::mcaspers: Index ContentHash created [0m[0m09:55:19,970 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.6.xml::1::mcaspers: ChangeSet db/changelog/db.changelog-1.6.xml::1::mcaspers ran successfully in 2038410ms [0m[0m09:55:20,523 INFO [liquibase] (MSC service thread 1-7) db/db.changelog.xml: db/changelog/db.changelog-1.6.xml::1::mcaspers: Reading from Skynet.DATABASECHANGELOG [0m[0m09:55:20,623 INFO [liquibase] (MSC service thread 1-7) Successfully released change log lock
I removed the indexes and liquidbase changelog entry and reapplied them with <pooled-connection-factory name="hornetq-ra"> <transaction mode="xa"/> <connectors> <connector-ref connector-name="in-vm"/> </connectors> <entries> <entry name="java:/JmsXA"/> </entries> <connection-ttl>-1</connection-ttl> </pooled-connection-factory> The operation completed successfully without any HornetQ disconnections.
Defined JMS topics in pressgang-jms.xml.
This is still an issue with contection-ttl set to -1 [0m[31m08:33:57,221 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/pressgang-ccms-messaging].[default]] (http-/0.0.0.0:8180-9) JBWEB000236: Servlet.service() for servlet default threw exception: org.jboss.resteasy.spi.UnhandledException: java.lang.RuntimeException: HornetQException[errorType=INTERNAL_ERROR message=HQ119001: Failed to create session] at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:365) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:233) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:209) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:557) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] at org.jboss.resteasy.core.SynchronousDispatcher.invokePropagateNotFound(SynchronousDispatcher.java:169) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:212) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] at org.jboss.resteasy.plugins.server.servlet.FilterDispatcher.doFilter(FilterDispatcher.java:59) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at com.thetransactioncompany.cors.CORSFilter.doFilter(CORSFilter.java:156) [cors-filter-1.8.jar:1.8] at com.thetransactioncompany.cors.CORSFilter.doFilter(CORSFilter.java:233) [cors-filter-1.8.jar:1.8] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] Caused by: java.lang.RuntimeException: HornetQException[errorType=INTERNAL_ERROR message=HQ119001: Failed to create session] at org.hornetq.rest.topic.SubscriptionsResource.subscriptionExists(SubscriptionsResource.java:409) [hornetq-rest-2.4.1.Final.jar:] at org.hornetq.rest.topic.SubscriptionsResource.createSubscription(SubscriptionsResource.java:214) [hornetq-rest-2.4.1.Final.jar:] at sun.reflect.GeneratedMethodAccessor590.invoke(Unknown Source) [:1.7.0_25] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25] at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] at org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:107) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] at org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:154) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] ... 21 more Caused by: HornetQException[errorType=INTERNAL_ERROR message=HQ119001: Failed to create session] at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:928) [hornetq-core-client-2.3.1.Final-redhat-1.jar:2.3.1.Final-redhat-1] at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:363) [hornetq-core-client-2.3.1.Final-redhat-1.jar:2.3.1.Final-redhat-1] at org.hornetq.rest.topic.SubscriptionsResource.subscriptionExists(SubscriptionsResource.java:402) [hornetq-rest-2.4.1.Final.jar:] ... 33 more Caused by: java.lang.IllegalStateException: Connection is null at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:797) [hornetq-core-client-2.3.1.Final-redhat-1.jar:2.3.1.Final-redhat-1] ... 35 more
The way updated entities will have be be moved from time based to revision based. I have found that when the server is quite slow, it can take more than a 10 seconds to save changes. I believe in this case by the time an entity is written to the database, it is already older than 10 seconds, and will never be picked up by the query to identify updated entities.
Moving back to assigned based on Matt's last comment.
Changes to entities are now determined by their revision number. This means that long save times don't affect the query the identifies edited entities. A "SERVER_RESTART" message is posted to each topic when the server first starts up. This is an indication to any clients that they will need to refresh their contents against the server, as entities may have been updated in the background without notifications being sent to the JMS topic.
The native query "SELECT MAX( REV ) FROM REVINFO;" is now used for getting the revision number.
Renaming this bug since with only the first 3 steps being implemented, the current title is no longer valid.
So this is what should make it into 1.6: * Hibernate search is removed from the REST server and UI * REST Server can be set to read only using the application properties, with read only endpoint returning FORBIDDEN in readonly mode * JMS topics are created as part of the deployment (see the pressgang-jms.xml file) * Updates to topics and specs, as determined by revision number, should be added to the JMS topics on a regular frequency (see UpdatedEntities.java) * The frequency that entities should be checked is also defined in the application properties The HornetQ REST interface itself is not going to make it into this release, as it still does not recover from disconnections well (despite the connection-ttl being set to -1). Also setting up a read only slave will have to be bumped.
This bug has bee split up into BZ#1101330 BZ#1101327 BZ#1101328 BZ#1101329
See also BZ#1101331