[JBoss JIRA] (AS7-6624) Jboss connection pool is not auto reconnects to mySQl (XA-datasource)
by Alexey S. (JIRA)
[ https://issues.jboss.org/browse/AS7-6624?page=com.atlassian.jira.plugin.s... ]
Alexey S. commented on AS7-6624:
--------------------------------
Jesper, I dont understand why it rejected? Are you saying this is not a bug? I give all needed information for reproduce, in the user forums it seems that similar problems are unresolved not only at my thread but also in similar threads, so why its rejected?
> Jboss connection pool is not auto reconnects to mySQl (XA-datasource)
> ---------------------------------------------------------------------
>
> Key: AS7-6624
> URL: https://issues.jboss.org/browse/AS7-6624
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.1.1.Final
> Reporter: Alexey S.
> Assignee: Stefano Maestri
>
> I am using JPA Hibernate in Timer EJB.
> After MySQL's restarted, JBOSS connection pool should be restarted also to renew the transaction, but it doesnt happened.
> my datasource is
> <xa-datasource jndi-name="java:jboss/datasources/db" pool-name="db" enabled="true" use-java-context="true">
> <xa-datasource-property name="ServerName">
> localhost
> </xa-datasource-property>
> <xa-datasource-property name="DatabaseName">
> db
> </xa-datasource-property>
> <xa-datasource-property name="User">
> root
> </xa-datasource-property>
> <xa-datasource-property name="Password">
> xxxxx
> </xa-datasource-property>
> <xa-datasource-property name="AutoReconnectForPools">
> true
> </xa-datasource-property>
> <xa-datasource-property name="FailOverReadOnly">
> false
> </xa-datasource-property>
> <xa-datasource-property name="MaxReconnects">
> 100
> </xa-datasource-property>
> <xa-datasource-property name="ReconnectAtTxEnd">
> true
> </xa-datasource-property>
> <driver>com.mysql</driver>
> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
> <check-valid-connection-sql>select 1</check-valid-connection-sql>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
> </validation>
> </xa-datasource>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-5794) JMX over remoting pollutes query results with ModelController objects
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/AS7-5794?page=com.atlassian.jira.plugin.s... ]
Tristan Tarrant commented on AS7-5794:
--------------------------------------
This still happens 7.2 (actually I tried with EAP 6.1.DR4). Here is a log snippet which shows what happens:
2013-02-26 15:41:01,202 TRACE [ResourceDiscoveryComponent.invoker.daemon-13] (org.infinispan.rhq.CacheDiscovery)- Querying *:type=Cache,component=Cache,manager="DefaultCacheManager",* returned beans: [jboss.jsr77:j2eeType=J2EEDomain,name=jboss.jsr77, org.infinispan:type=Cache,name="___defaultcache(local)",manager="DefaultCacheManager",component=Cache, jboss.jsr77:j2eeType=J2EEServer,name=default, jboss.jsr77:j2eeType=JVM,name=default,J2EEServer=default]
2013-02-26 15:41:01,202 WARN [ResourceDiscoveryComponent.invoker.daemon-13] (org.infinispan.rhq.CacheDiscovery)- MBeanServer returned spurious object jboss.jsr77:j2eeType=J2EEDomain,name=jboss.jsr77
> JMX over remoting pollutes query results with ModelController objects
> ---------------------------------------------------------------------
>
> Key: AS7-5794
> URL: https://issues.jboss.org/browse/AS7-5794
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, JMX
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Tristan Tarrant
> Assignee: Kabir Khan
> Fix For: 7.3.0.Alpha1
>
>
> When issuing MBean queries over JMX remoting, the AS is returning a list of org.jboss.as.controller.ModelController objects in addition to those matching the query.
> This is a transcript of a chat we had about it on IRC:
> Oct 15 14:51:46 <ttarrant> darranl, if I issue a jmx query over jmx-remoting I get many more objects than expected
> Oct 15 14:51:55 <ttarrant> darranl, i.e. ones that do not match the query
> Oct 15 14:52:09 <ttarrant> darranl, this is with 7.1.x
> Oct 15 14:52:57 <ttarrant> darranl, this works if I use the standard JMX over RMI
> Oct 15 14:53:08 --> fnasser (~fnasser(a)CPE602ad07ab726-CM602ad07ab723.cpe.net.cable.rogers.com) has joined #jboss-as7
> Oct 15 14:53:09 <-- fnasser has quit (Changing host)
> Oct 15 14:53:09 --> fnasser (~fnasser@redhat/jboss/fnasser) has joined #jboss-as7
> Oct 15 14:53:09 --- ChanServ gives voice to fnasser
> Oct 15 14:53:16 <ttarrant> darranl, do you just pass the query the the mbeanserver ?
> Oct 15 14:53:39 <darranl> ttarrant: what kind of objects? within AS7 I think there are two things that could affec
> t this 1 - The Remoting JMX protocol, 2 - The domain management representation over JMX
> Oct 15 14:53:54 <darranl> For #1 yes we just pass it to the MBEanServer and return whatever it returns
> Oct 15 14:54:04 <darranl> if it was a Remoting JMX bug maybe we are messing up the query
> Oct 15 14:54:16 <ttarrant> darranl, the query is as follows: *:type=CacheManager,component=Interpreter,name=*
> Oct 15 14:54:16 <darranl> But not sure if #2 could be the reason more is getting added
> Oct 15 14:54:32 <ttarrant> darranl, wait a sec
> Oct 15 14:54:57 <darranl> ttarrant: I would suggest getting a Jira raised and assigned to me, I can verify if it i
> s a remoting jmx issue or pass over if it is a domain management integration issue
> Oct 15 14:55:20 <darranl> regardless of where it is happenign it sounds like you may have discovered a bug
> Oct 15 14:56:23 <ttarrant> darranl, let me get the objects it's returning
> Oct 15 14:56:39 <darranl> ttarrant: when you enable the RMI approach you bypass both Remoting JMX AND the domain m
> anagement integration
> Oct 15 14:56:42 <darranl> ok
> Oct 15 15:26:08 <ttarrant> darranl, ok, my query actually returns the object I queried for and a bunch of org.jboss.as.controller.ModelController (one for each subsystem)
> Oct 15 15:51:24 <darranl> ttarrant: ok that does then sound like it is the domain management integration that is 'poluting' the query results
> Oct 15 15:51:53 <darranl> ttarrant: going RMI was just bypassing that as well
> Oct 15 15:52:05 <ttarrant> darranl, shall I open a Jira ?
> Oct 15 15:52:34 <ttarrant> darranl, I work around the issue by manually filtering the returned objects based on class name
> Oct 15 15:53:23 <darranl> ttarrant: it would probably be one for kkhan to look into, think he is just back today so may be worth the Jira so he can have a look once he has caught back up ;-)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6635) EJB2 CMB beans: ejbActivate callback is called after the bean creation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6635?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6635:
----------------------------------------------
Jaikiran Pai <jpai(a)redhat.com> made a comment on [bug 914738|https://bugzilla.redhat.com/show_bug.cgi?id=914738]
Can you please attach the logs of the failing test, so that I can quickly check if this is really an issue or a testcase problem?
> EJB2 CMB beans: ejbActivate callback is called after the bean creation
> -----------------------------------------------------------------------
>
> Key: AS7-6635
> URL: https://issues.jboss.org/browse/AS7-6635
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.2.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Labels: cmp, ejb, entities, entity
>
> Called ejbActive after the create() call on home interface is incorrect by spec.
> 10.1.3
> There are two possible transitions from the pooled to the ready state: through the ejbCreate<METHOD> and ejbPostCreate<METHOD> methods, or through the ejbActivate method. The container invokes the ejbCreate<METHOD> and ejbPostCreate<METHOD> methods when the instance is assigned to an entity object during entity object creation.
> The container invokes the ejbActivate method on an instance when an instance needs to be activated to service an invocation on an existing entity object—this occurs because there is no suitable instance in the ready state to service the client’s call or the ejbTimeout method.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6624) Jboss connection pool is not auto reconnects to mySQl (XA-datasource)
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/AS7-6624?page=com.atlassian.jira.plugin.s... ]
Jesper Pedersen closed AS7-6624.
--------------------------------
Resolution: Rejected
Use the user forum for discussions
> Jboss connection pool is not auto reconnects to mySQl (XA-datasource)
> ---------------------------------------------------------------------
>
> Key: AS7-6624
> URL: https://issues.jboss.org/browse/AS7-6624
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.1.1.Final
> Reporter: Alexey S.
> Assignee: Stefano Maestri
>
> I am using JPA Hibernate in Timer EJB.
> After MySQL's restarted, JBOSS connection pool should be restarted also to renew the transaction, but it doesnt happened.
> my datasource is
> <xa-datasource jndi-name="java:jboss/datasources/db" pool-name="db" enabled="true" use-java-context="true">
> <xa-datasource-property name="ServerName">
> localhost
> </xa-datasource-property>
> <xa-datasource-property name="DatabaseName">
> db
> </xa-datasource-property>
> <xa-datasource-property name="User">
> root
> </xa-datasource-property>
> <xa-datasource-property name="Password">
> xxxxx
> </xa-datasource-property>
> <xa-datasource-property name="AutoReconnectForPools">
> true
> </xa-datasource-property>
> <xa-datasource-property name="FailOverReadOnly">
> false
> </xa-datasource-property>
> <xa-datasource-property name="MaxReconnects">
> 100
> </xa-datasource-property>
> <xa-datasource-property name="ReconnectAtTxEnd">
> true
> </xa-datasource-property>
> <driver>com.mysql</driver>
> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
> <check-valid-connection-sql>select 1</check-valid-connection-sql>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
> </validation>
> </xa-datasource>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (JBJCA-989) Build failure under windows due to UTF-8 characters
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-989?page=com.atlassian.jira.plugin.... ]
Jesper Pedersen closed JBJCA-989.
---------------------------------
Resolution: Rejected
Please, start by opening a discussion in the user forum before filing JIRAs
> Build failure under windows due to UTF-8 characters
> ---------------------------------------------------
>
> Key: JBJCA-989
> URL: https://issues.jboss.org/browse/JBJCA-989
> Project: IronJacamar
> Issue Type: Feature Request
> Reporter: Jan Roman
> Assignee: Jesper Pedersen
> Priority: Minor
> Attachments: JBJCA-989.diff
>
>
> Build tasks are using default system charset which under windows can differ (in my case it was cp1451). As there are UTF-8 characters in sourcecode build is failing.
> It is better to not rely on system defaults in build descriptors.
> There is another problem with build on windows causing error message:
> [metadata-parser] Generating Interface: Connector
> [metadata-parser] Error at xsl:result-document on line 237 of :
> [metadata-parser] Resolved URL is malformed: unknown protocol: c
> This is caused by bug in ShrinkWrap which has been fixed in 2.0.0-alpha-5.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6511) Investigate OSGi test failures after MSC upgrade to 1.1.1.Final
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/AS7-6511?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on AS7-6511:
----------------------------------
I'm escalating this because it is interfering with proper operation of the test suite. If someone disagrees, or if the tests are disabled, then it can be de-escalated again.
> Investigate OSGi test failures after MSC upgrade to 1.1.1.Final
> ---------------------------------------------------------------
>
> Key: AS7-6511
> URL: https://issues.jboss.org/browse/AS7-6511
> Project: Application Server 7
> Issue Type: Task
> Components: OSGi
> Environment: Tested on (not able to reproduce)
> ---
> [blackhole][/home/opalka/git/jboss-as/trunk]>java -version
> java version "1.6.0_38"
> Java(TM) SE Runtime Environment (build 1.6.0_38-b05)
> Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode)
> ---
> [blackhole][/home/opalka/git/jboss-as/trunk]>mvn -version
> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: /home/opalka/java/maven/3.0.4
> Java version: 1.6.0_38, vendor: Sun Microsystems Inc.
> Java home: /home/opalka/java/jdk/orcl/jdk1.6.0_38/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.7.6-201.fc18.x86_64", arch: "amd64", family: "unix"
> ---
> [blackhole][/home/opalka/git/jboss-as/trunk]>uname -a
> Linux blackhole 3.7.6-201.fc18.x86_64 #1 SMP Mon Feb 4 15:54:08 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Richard Opalka
> Assignee: Thomas Diesler
> Priority: Blocker
> Fix For: 7.3.0.Alpha1
>
>
> I did my best to reproduce this issue but I'm not able to reproduce it locally:( It doesn't matter if I run whole test suite or just this test, the
> test is always passing for me. Since OSGi is not my domain, I'm assigning
> this issue to OSGi team. This bug is related to this PR:
> https://github.com/jbossas/jboss-as/pull/4052
> I'm temporarily disabling the failing test (the purpose of this JIRA).
> Failing test is:
> [INFO] Surefire report directory: /home/jenkins/jenkins-work/workspace/as7-param-pull/testsuite/integration/osgi/target/surefire-reports
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> ...
> Results :
> Failed tests: testFailStartLevel(org.jboss.as.test.integration.osgi.deployment.DeferredResolveTestCase): Bundle ACTIVE expected:<32> but was:<4>
> Tests run: 120, Failures: 1, Errors: 0, Skipped: 6
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6511) Investigate OSGi test failures after MSC upgrade to 1.1.1.Final
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/AS7-6511?page=com.atlassian.jira.plugin.s... ]
David Lloyd updated AS7-6511:
-----------------------------
Priority: Blocker (was: Major)
> Investigate OSGi test failures after MSC upgrade to 1.1.1.Final
> ---------------------------------------------------------------
>
> Key: AS7-6511
> URL: https://issues.jboss.org/browse/AS7-6511
> Project: Application Server 7
> Issue Type: Task
> Components: OSGi
> Environment: Tested on (not able to reproduce)
> ---
> [blackhole][/home/opalka/git/jboss-as/trunk]>java -version
> java version "1.6.0_38"
> Java(TM) SE Runtime Environment (build 1.6.0_38-b05)
> Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode)
> ---
> [blackhole][/home/opalka/git/jboss-as/trunk]>mvn -version
> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: /home/opalka/java/maven/3.0.4
> Java version: 1.6.0_38, vendor: Sun Microsystems Inc.
> Java home: /home/opalka/java/jdk/orcl/jdk1.6.0_38/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.7.6-201.fc18.x86_64", arch: "amd64", family: "unix"
> ---
> [blackhole][/home/opalka/git/jboss-as/trunk]>uname -a
> Linux blackhole 3.7.6-201.fc18.x86_64 #1 SMP Mon Feb 4 15:54:08 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Richard Opalka
> Assignee: Thomas Diesler
> Priority: Blocker
> Fix For: 7.3.0.Alpha1
>
>
> I did my best to reproduce this issue but I'm not able to reproduce it locally:( It doesn't matter if I run whole test suite or just this test, the
> test is always passing for me. Since OSGi is not my domain, I'm assigning
> this issue to OSGi team. This bug is related to this PR:
> https://github.com/jbossas/jboss-as/pull/4052
> I'm temporarily disabling the failing test (the purpose of this JIRA).
> Failing test is:
> [INFO] Surefire report directory: /home/jenkins/jenkins-work/workspace/as7-param-pull/testsuite/integration/osgi/target/surefire-reports
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> ...
> Results :
> Failed tests: testFailStartLevel(org.jboss.as.test.integration.osgi.deployment.DeferredResolveTestCase): Bundle ACTIVE expected:<32> but was:<4>
> Tests run: 120, Failures: 1, Errors: 0, Skipped: 6
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6635) EJB2 CMB beans: ejbActivate callback is called after the bean creation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6635?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated AS7-6635:
-----------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=914738
> EJB2 CMB beans: ejbActivate callback is called after the bean creation
> -----------------------------------------------------------------------
>
> Key: AS7-6635
> URL: https://issues.jboss.org/browse/AS7-6635
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.2.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Labels: cmp, ejb, entities, entity
>
> Called ejbActive after the create() call on home interface is incorrect by spec.
> 10.1.3
> There are two possible transitions from the pooled to the ready state: through the ejbCreate<METHOD> and ejbPostCreate<METHOD> methods, or through the ejbActivate method. The container invokes the ejbCreate<METHOD> and ejbPostCreate<METHOD> methods when the instance is assigned to an entity object during entity object creation.
> The container invokes the ejbActivate method on an instance when an instance needs to be activated to service an invocation on an existing entity object—this occurs because there is no suitable instance in the ready state to service the client’s call or the ejbTimeout method.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6635) EJB2 CMB beans: ejbActivate callback is called after the bean creation
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created AS7-6635:
-------------------------------------
Summary: EJB2 CMB beans: ejbActivate callback is called after the bean creation
Key: AS7-6635
URL: https://issues.jboss.org/browse/AS7-6635
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.2.0.Alpha1
Reporter: Wolf-Dieter Fink
Assignee: Wolf-Dieter Fink
Called ejbActive after the create() call on home interface is incorrect by spec.
10.1.3
There are two possible transitions from the pooled to the ready state: through the ejbCreate<METHOD> and ejbPostCreate<METHOD> methods, or through the ejbActivate method. The container invokes the ejbCreate<METHOD> and ejbPostCreate<METHOD> methods when the instance is assigned to an entity object during entity object creation.
The container invokes the ejbActivate method on an instance when an instance needs to be activated to service an invocation on an existing entity object—this occurs because there is no suitable instance in the ready state to service the client’s call or the ejbTimeout method.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6634) Complete support for OSGi Blueprint
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/AS7-6634?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar commented on AS7-6634:
-------------------------------------
The problem is that Managed*DeployableContainer kills the managed server instead of regular shutdown in stop() on Windows. ARQ's stop is supposed to shutdown the server 'nicely', for abrupt termination there is jvmKill().
This was probably implemented like this incorrectly assuming that on windows, the process is sent SIGTERM like on *NIX-based OSes but there is no such thing on windows and the process is terminated immediately.
This shows up only in clustered tests, compared to other tests which dont rely on the shutdown sequence to be completed, but clustering testsuite relies on shutdown to disconnect the channel and leave the cluster without FD having to kick in.
> Complete support for OSGi Blueprint
> -----------------------------------
>
> Key: AS7-6634
> URL: https://issues.jboss.org/browse/AS7-6634
> Project: Application Server 7
> Issue Type: Feature Request
> Components: OSGi
> Reporter: Thomas Diesler
>
> R5 TCK compliance for Blueprint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months