[JBoss JIRA] Created: (HIBERNATE-54) problems w/ column names beginning with '_' (underscore) w/ apache derby database
by bugra uytun (JIRA)
problems w/ column names beginning with '_' (underscore) w/ apache derby database
---------------------------------------------------------------------------------
Key: HIBERNATE-54
URL: http://jira.jboss.com/jira/browse/HIBERNATE-54
Project: Hibernate
Issue Type: Bug
Environment: windows xp, java 1.5.0_09, eclispe 3.2.1, hibernate 3.2.1, derby 10.2.2.0, hibernate tools 3.2 beta8
Reporter: bugra uytun
Assigned To: Steve Ebersole
derby has problems with column names beginning with underscore, see also http://db.apache.org/derby/docs/10.1/ref/crefsqlj1003454.html
therefore such column names should be between double quotation marks (notice that double quotation marks also sets the case sensitivity on column names.)
but hibernate translates a HQL statement like this "from table1 t where t.id = '1'" to something like:
select table1_.id as id4, table1_._colname1 as column27_4_ schema1.table1 table1_ where table1_.id = '1'
but because of the columns that are beginning with an underscore the translation should be:
select table1_."id" as id4, table1_."_colname1" as column27_4_ schema1."table1" table1_ where table1_."id" = '1'
the errors i got are:
DEBUG [JDBCExceptionReporter]: could not execute query [<translated sql statement>]
ERROR 42X01: Syntax error: Encountered "_" at line 1, column 987.
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(Unknown Source)
at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown Source)
at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:497)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:415)
at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1538)
at org.hibernate.loader.Loader.doQuery(Loader.java:661)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
at org.hibernate.loader.Loader.doList(Loader.java:2211)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2095)
at org.hibernate.loader.Loader.list(Loader.java:2090)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:388)
at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338)
at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
at <mypackage>.MyHibernate.main(MyHibernate.java:13)
WARN main org.hibernate.util.JDBCExceptionReporter - SQL Error: 20000, SQLState: 42X01
ERROR main org.hibernate.util.JDBCExceptionReporter - Syntax error: Encountered "_" at line 1, column 987.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4633) Concurrent Access to @SessionScoped @Stateful beans is not serialised if there is no active transaction
by James Fellows (JIRA)
James Fellows created AS7-4633:
----------------------------------
Summary: Concurrent Access to @SessionScoped @Stateful beans is not serialised if there is no active transaction
Key: AS7-4633
URL: https://issues.jboss.org/browse/AS7-4633
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.1.Final, 7.1.0.Final
Environment: Linux Ubuntu 11.10, Sun JDK & JRE 1.6.0_26 Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
Reporter: James Fellows
Assignee: jaikiran pai
Concurrent calls to @Stateful @SessionScoped beans in the absence of a transaction (for example where the method being invoked is annotated @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) are not serialized and (I believe) they should be, byt the container. Concurrent access to the same method annotated @TransactionAttribute(TransactionAttributeType.REQUIRED) IS serialised correctly.
Moreover, when concurrent access to the bean occurs in the absence of a transaction, no errors are logged - the instance is simply removed from the pool leading to NullPointerExceptions on subsequent calls (from any thread).
I have looked at the unit tests for org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor (which is where I believe the issue lies - see explanation in the forum), but I really don't understand it. I'm not familiar with Mockito, but as far as I can tell the functionality is only tested during Bean and Container Managed transactions, not in their absence.
The problem can be recreated in an integration-test scenario by making multiple concurrent calls to a @Stateful @sessionScoped bean. In my case my app makes the calls from @Stateless JAX-RS services.
In the world of AJAX and tabbed browsing I believe this issue to be significant. I suspect transaction-less calls will become more common as people get used to the @PersistenceContext(type=PersistenceContextType.EXTENDED) EntityManagers and the flexibility they allow (it's heavily featured in Adam Bien's Rethinking J2EE Patterns book). There have been some discussions on StackOverflow of people trying to figure out the issue, but only very few.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4751) Singleton Service fails on Windows with "IllegalStateException: JBAS010350: Expected result from singleton provider only, but instead received 0 results"
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4751:
-----------------------------------
Summary: Singleton Service fails on Windows with "IllegalStateException: JBAS010350: Expected result from singleton provider only, but instead received 0 results"
Key: AS7-4751
URL: https://issues.jboss.org/browse/AS7-4751
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: 7.1.1.Final
Environment: Windows -- any
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Fix For: 7.1.2.Final (EAP)
As seen on hudson runs and observed by Tom C. (thanks Tom) :
http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/ea...
{noformat}
07:34:17,664 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/singleton].[org.jboss.as.test.clustering.cluster.singleton.service.MyServiceServlet]] (http--10.16.92.4-8080-1) Servlet.service() for servlet org.jboss.as.test.clustering.cluster.singleton.service.MyServiceServlet threw exception: java.lang.IllegalStateException: java.lang.IllegalStateException: JBAS010350: Expected result from singleton provider only, but instead received 0 results.
at org.jboss.as.clustering.singleton.SingletonService$RpcHandler.getValueRef(SingletonService.java:225) [jboss-as-clustering-singleton-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
at org.jboss.as.clustering.singleton.SingletonService.getValue(SingletonService.java:176) [jboss-as-clustering-singleton-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
at org.jboss.as.clustering.singleton.SingletonService.getValue(SingletonService.java:53) [jboss-as-clustering-singleton-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1203) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
at org.jboss.as.test.clustering.cluster.singleton.service.MyServiceServlet.doGet(MyServiceServlet.java:40) [classes:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.1.Final-redhat-1.jar:1.0.1.Final-redhat-1]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.1.Final-redhat-1.jar:1.0.1.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.15.Final-redhat-1.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.15.Final-redhat-1.jar:]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.15.Final-redhat-1.jar:]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.15.Final-redhat-1.jar:]
at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:67)
at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:48)
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.15.Final-redhat-1.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.15.Final-redhat-1.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.15.Final-redhat-1.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.15.Final-redhat-1.jar:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.15.Final-redhat-1.jar:]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.15.Final-redhat-1.jar:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.15.Final-redhat-1.jar:]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_02]
Caused by: java.lang.IllegalStateException: JBAS010350: Expected result from singleton provider only, but instead received 0 results.
at org.jboss.as.clustering.singleton.SingletonService$RpcHandler.getValueRef(SingletonService.java:221) [jboss-as-clustering-singleton-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
... 21 more
{noformat}
Test itself then fails with
{noformat}
Error Message
Deployment with name deployment-1 could not be undeployed. Container container-1 must be still running.
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4836) Invalid recursive module creation triggered by bundle event
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-4836?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-4836:
--------------------------------
Fix Version/s: (was: 7.1.3.Final (EAP))
Forum Reference: https://community.jboss.org/message/736258 (was: https://community.jboss.org/message/736258)
> Invalid recursive module creation triggered by bundle event
> -----------------------------------------------------------
>
> Key: AS7-4836
> URL: https://issues.jboss.org/browse/AS7-4836
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 7.2.0.Alpha1
>
>
> {code}
> at org.jboss.as.osgi.service.ModuleLoaderIntegration.addModule(ModuleLoaderIntegration.java:128)
> at org.jboss.osgi.framework.internal.ModuleManagerPlugin.createHostModule(ModuleManagerPlugin.java:298)
> at org.jboss.osgi.framework.internal.ModuleManagerPlugin.addModule(ModuleManagerPlugin.java:196)
> at org.jboss.osgi.framework.internal.ResolverPlugin.addModules(ResolverPlugin.java:253)
> at org.jboss.osgi.framework.internal.ResolverPlugin.applyResolverResults(ResolverPlugin.java:201)
> at org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:121)
> at org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:551)
> at org.jboss.osgi.framework.internal.HostBundleRevision.findEntries(HostBundleRevision.java:126)
> at org.jboss.osgi.framework.internal.AbstractBundleState.findEntries(AbstractBundleState.java:443)
> at org.eclipse.gemini.blueprint.extender.internal.support.NamespaceManager.maybeAddNamespaceHandlerFor(NamespaceManager.java:130)
> at org.eclipse.gemini.blueprint.extender.internal.activator.ContextLoaderListener.maybeAddNamespaceHandlerFor(ContextLoaderListener.java:462)
> at org.eclipse.gemini.blueprint.extender.internal.activator.ContextLoaderListener$NamespaceBundleLister.handleEvent(ContextLoaderListener.java:169)
> at org.eclipse.gemini.blueprint.extender.internal.activator.ContextLoaderListener$BaseListener.bundleChanged(ContextLoaderListener.java:137)
> at org.jboss.osgi.framework.internal.FrameworkEventsPlugin.fireBundleEvent(FrameworkEventsPlugin.java:372)
> at org.jboss.osgi.framework.internal.AbstractBundleState.fireBundleEvent(AbstractBundleState.java:198)
> at org.jboss.osgi.framework.internal.AbstractBundleState.changeState(AbstractBundleState.java:192)
> at org.jboss.osgi.framework.internal.AbstractBundleState.changeState(AbstractBundleState.java:174)
> at org.jboss.osgi.framework.internal.ResolverPlugin.setBundleToResolved(ResolverPlugin.java:277)
> at org.jboss.osgi.framework.internal.ResolverPlugin.applyResolverResults(ResolverPlugin.java:207)
> at org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:121)
> at org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:551)
> at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:232)
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:485)
> at org.jboss.as.osgi.management.BundleResourceHandler.handleOperation(BundleResourceHandler.java:145)
> at org.jboss.as.osgi.management.BundleResourceHandler.executeRuntimeStep(BundleResourceHandler.java:99)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4865) Datasource after creation is in a peculiar state
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/AS7-4865?page=com.atlassian.jira.plugin.s... ]
Jesper Pedersen updated AS7-4865:
---------------------------------
Fix Version/s: 7.2.0.Alpha1
7.1.2.Final (EAP)
Git Pull Request: https://github.com/jbossas/jboss-as/pull/2367, https://github.com/jbossas/jboss-as/pull/2366 (was: https://github.com/jbossas/jboss-as/pull/2367, https://github.com/jbossas/jboss-as/pull/2366)
> Datasource after creation is in a peculiar state
> ------------------------------------------------
>
> Key: AS7-4865
> URL: https://issues.jboss.org/browse/AS7-4865
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Reporter: Jan Martiska
> Assignee: Stefano Maestri
> Priority: Critical
> Fix For: 7.1.2.Final (EAP), 7.2.0.Alpha1
>
>
> Create a (xa)datasource in admin console. Try to disable it using the appropriate button. This error will happen:
> {noformat}
> Request
> {
> "xa-datasource-class" => "org.h2.jdbcx.JdbcDataSource",
> "pad-xid" => false,
> "wrap-xa-resource" => false,
> "same-rm-override" => false,
> "interleaving" => false,
> "name" => "qrh",
> "driver-name" => "h2",
> "password" => "",
> "enabled" => true,
> "user-name" => "",
> "security-domain" => "",
> "jndi-name" => "java:/uyyyy",
> "pool-name" => "",
> "transaction-isolation" => "",
> "new-connection-sql" => "",
> "connection-url" => "",
> "driver-class" => "",
> "valid-connection-checker-class-name" => "",
> "check-valid-connection-sql" => "",
> "background-validation" => false,
> "background-validation-millis" => -1L,
> "validate-on-match" => false,
> "stale-connection-checker-class-name" => "",
> "exception-sorter-class-name" => "",
> "prepared-statements-cache-size" => -1L,
> "share-prepared-statements" => false,
> "use-ccm" => false,
> "operation" => "disable",
> "address" => [
> ("subsystem" => "datasources"),
> ("xa-data-source" => "qrh")
> ],
> "operation-headers" => {"allow-resource-service-restart" => true}
> }
> Response
> Internal Server Error
> {
> "outcome" => "failed",
> "failure-description" => "JBAS010455: Data-source service [qrh] is not enabled",
> "rolled-back" => true,
> "response-headers" => {"process-state" => "restart-required"}
> }
> {noformat}
> It states that "Data-source service [qrh] is not enabled" even though the datasource has property "enabled" equal "true".
> After you disable the datasource in CLI using :disable operation (this works) and then enable it back -> from this point, disabling and enabling in console will work, just the first time (after creation) it doesn't.
> *Also, weird thing is - after you create a datasource, it is not shown in JNDI naming tree, it looks like it is not active, even though CLI says it is enabled.* You have to reload server, only then will the datasource appear in JNDI naming tree - it behaves like datasource creation requires server-reload, but JCA subsystem doesn't indicate this.
> What is the correct behavior?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4705) differences between registered and described operations for messaging resources in domain mode
by Jeff Mesnil (JIRA)
Jeff Mesnil created AS7-4705:
--------------------------------
Summary: differences between registered and described operations for messaging resources in domain mode
Key: AS7-4705
URL: https://issues.jboss.org/browse/AS7-4705
Project: Application Server 7
Issue Type: Bug
Components: Console, JMS
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
The console does not give the same list of operation names for a messaging jms-topic resource when AS7 runs in standalone mode or domain mode.
In standalone mode:
{noformat}
[standalone@localhost:9999 /] /subsystem=messaging/hornetq-server=default/jms-topic=testT/:read-operation-names
{
"outcome" => "success",
"result" => [
"add",
"add-jndi",
"count-messages-for-subscription",
"drop-all-subscriptions",
"drop-durable-subscription",
"list-all-subscriptions",
"list-all-subscriptions-as-json",
"list-durable-subscriptions",
"list-durable-subscriptions-as-json",
"list-messages-for-subscription",
"list-messages-for-subscription-as-json",
"list-non-durable-subscriptions",
"list-non-durable-subscriptions-as-json",
"read-attribute",
"read-children-names",
"read-children-resources",
"read-children-types",
"read-operation-description",
"read-operation-names",
"read-resource",
"read-resource-description",
"remove",
"remove-messages",
"undefine-attribute",
"whoami",
"write-attribute"
]
}
{noformat}
In domain mode:
{noformat}
[domain@localhost:9999 /] /host=master/server=server-one/subsystem=messaging/hornetq-server=default/jms-topic=testT/:read-operation-names
{
"outcome" => "success",
"result" => [
"count-messages-for-subscription",
"list-all-subscriptions",
"list-all-subscriptions-as-json",
"list-durable-subscriptions",
"list-durable-subscriptions-as-json",
"list-messages-for-subscription",
"list-messages-for-subscription-as-json",
"list-non-durable-subscriptions",
"list-non-durable-subscriptions-as-json",
"read-attribute",
"read-children-names",
"read-children-resources",
"read-children-types",
"read-operation-description",
"read-operation-names",
"read-resource",
"read-resource-description"
]
}
{noformat}
I was expecting to have access to the same list of operations names using this address in domain mode than in standalone mode but some are missing (eg drop-all-subscriptions).
However it is possible to perform the operation even when it is not displayed in the operation names:
{noformat}
[domain@localhost:9999 /] /host=master/server=server-one/subsystem=messaging/hornetq-server=default/jms-topic=testT/:read-operation-description(name="drop-all-subscriptions")
{
"outcome" => "failed",
"result" => undefined,
"failure-description" => "JBAS014753: There is no operation drop-all-subscriptions registered at address [
(\"subsystem\" => \"messaging\"),
(\"hornetq-server\" => \"default\"),
(\"jms-topic\" => \"testT\")
]",
"rolled-back" => true
}
[domain@localhost:9999 /] /host=master/server=server-one/subsystem=messaging/hornetq-server=default/jms-topic=testT/:drop-all-subscriptions()
{
"outcome" => "success",
"result" => undefined
}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4860) Client InitialContext only works on 127.0.0.1 due to 5 second delay in server on other addresses
by Remmelt van der Werff (JIRA)
Remmelt van der Werff created AS7-4860:
------------------------------------------
Summary: Client InitialContext only works on 127.0.0.1 due to 5 second delay in server on other addresses
Key: AS7-4860
URL: https://issues.jboss.org/browse/AS7-4860
Project: Application Server 7
Issue Type: Bug
Components: Naming, Remoting
Affects Versions: 7.1.1.Final, 7.2.0.Alpha1
Environment: Ubuntu 12.04LTS 64bit
Reporter: Remmelt van der Werff
Assignee: John Bailey
I am in the process of migrating from jboss 5 to 7 and I am having problems accessing jms through jndi, which I think is related to a bug.
The lookup works fine when the client accesses the server on 127.0.0.1. On any other address bound to the loopback device (eg 127.0.0.2) the getting of the initial context fails with the "Operation failed with status WAITING" error.
The server was started with -b 0.0.0.0.
Looking at the logs I notice the following. The client waits max 5 seconds for a response from the server before issueing the WAITING error. In case of 127.0.0.1 no problem, but with 127.0.0.2 the server does "something" that takes up exactly 5 seconds.
10:02:16,565 TRACE [org.xnio.channels.framed] (Remoting "server17" read-1) Created new framed message channel around TCP socket channel (NIO) <5f55b990>, receive buffer Pooled wrapper around java.nio.HeapByteBuffer[pos=0 lim=8196 cap=8196], transmit buffer Pooled wrapper around java.nio.HeapByteBuffer[pos=0 lim=8196 cap=8196]
10:02:21,573 TRACE [org.xnio.listener] (Remoting "server17" read-1) Setting channel listener to org.jboss.remoting3.remote.RemoteConnection$RemoteWriteListener@54038f36
This 5 seconds delay in the server breaks the 5 second timeout in the client. In the client log you can see the initial handshake comming in right after the error message (which gets terminated because the connections was already closed by the client).
Problem occurs with both 7.1.1.Final as with jboss-as-7.2.0.Alpha1-SNAPSHOT
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4865) Datasource after creation is in a peculiar state
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-4865?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri commented on AS7-4865:
--------------------------------------
The root cause of the issue is that newly created ds are disabled, but the attribute enabled is set (wrongly) to true, "confusing" web console.
> Datasource after creation is in a peculiar state
> ------------------------------------------------
>
> Key: AS7-4865
> URL: https://issues.jboss.org/browse/AS7-4865
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Reporter: Jan Martiska
> Assignee: Stefano Maestri
> Priority: Critical
>
> Create a (xa)datasource in admin console. Try to disable it using the appropriate button. This error will happen:
> {noformat}
> Request
> {
> "xa-datasource-class" => "org.h2.jdbcx.JdbcDataSource",
> "pad-xid" => false,
> "wrap-xa-resource" => false,
> "same-rm-override" => false,
> "interleaving" => false,
> "name" => "qrh",
> "driver-name" => "h2",
> "password" => "",
> "enabled" => true,
> "user-name" => "",
> "security-domain" => "",
> "jndi-name" => "java:/uyyyy",
> "pool-name" => "",
> "transaction-isolation" => "",
> "new-connection-sql" => "",
> "connection-url" => "",
> "driver-class" => "",
> "valid-connection-checker-class-name" => "",
> "check-valid-connection-sql" => "",
> "background-validation" => false,
> "background-validation-millis" => -1L,
> "validate-on-match" => false,
> "stale-connection-checker-class-name" => "",
> "exception-sorter-class-name" => "",
> "prepared-statements-cache-size" => -1L,
> "share-prepared-statements" => false,
> "use-ccm" => false,
> "operation" => "disable",
> "address" => [
> ("subsystem" => "datasources"),
> ("xa-data-source" => "qrh")
> ],
> "operation-headers" => {"allow-resource-service-restart" => true}
> }
> Response
> Internal Server Error
> {
> "outcome" => "failed",
> "failure-description" => "JBAS010455: Data-source service [qrh] is not enabled",
> "rolled-back" => true,
> "response-headers" => {"process-state" => "restart-required"}
> }
> {noformat}
> It states that "Data-source service [qrh] is not enabled" even though the datasource has property "enabled" equal "true".
> After you disable the datasource in CLI using :disable operation (this works) and then enable it back -> from this point, disabling and enabling in console will work, just the first time (after creation) it doesn't.
> *Also, weird thing is - after you create a datasource, it is not shown in JNDI naming tree, it looks like it is not active, even though CLI says it is enabled.* You have to reload server, only then will the datasource appear in JNDI naming tree - it behaves like datasource creation requires server-reload, but JCA subsystem doesn't indicate this.
> What is the correct behavior?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month