[JBoss JIRA] (ELY-554) Server specific MechanismConfiguration
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-554:
------------------------------------
Summary: Server specific MechanismConfiguration
Key: ELY-554
URL: https://issues.jboss.org/browse/ELY-554
Project: WildFly Elytron
Issue Type: Enhancement
Components: API / SPI
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.Beta6
In addition to having a default MechanismConfiguration per mechanism we will also have server specific configurations.
We will also have a new ServerNameCallback callback for the mechanism to specify the server name - this will cause the ServerAuthenticationContext to swap out the current MechanismConfiguration with the server specific configuration.
MechanismConfiguration selection by server name will fall back to the default MechanismConfiguration if no server specific configuration is found.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6561) EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-6561?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf reopened WFLY-6561:
---------------------------------
> EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-6561
> URL: https://issues.jboss.org/browse/WFLY-6561
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
> Assignee: Stuart Douglas
> Labels: downstream_dependency
> Fix For: 10.1.0.Final
>
>
> On Wildfly10, we are experiencing intermittent problems where on server startup, an @Timeout annotated method can be executed hundreds of times in a second (log below). Going through the references to the @Timeout methods and the @Scheduled methods, all scheduled methods are set to be non-persistent (ex: timerConfig.setPersistent(false), persistent=false) so we don't know how this could occur. It is not consistent and our only solution has been to kill the Wildfly10 server process and restart.
> 13:47:27,824 WARN [org.jboss.as.ejb3] (EJB default - 6) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 96) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 97) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 37) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6192) JAXBUsageTestCase fails with security manager with security manager enabled
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-6192?page=com.atlassian.jira.plugin.... ]
Ivo Studensky commented on WFLY-6192:
-------------------------------------
It would need the following fix (see \[1\]) in order to let the deployment invoke {{JAXBContext.newInstance}} without explicit additional permissions. But then there is another security exception for {{unmarshaller.unmarshal}} invocation \[2\], see the stacktrace below, and I don't think we want to call \[3\] inside of {{doPrivileged}}.
I still believe the use-case from JAXBUsageServlet is fine with those two additional perms proposed in my PR.
\[1\] https://github.com/jboss/jboss-jaxb-api_spec/pull/4/commits/a2fe3493f06c9...
\[2\] https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basi...
\[3\] https://github.com/jboss/jboss-jaxb-api_spec/blob/master/src/main/java/ja...
{noformat}
2016-05-31 15:13:07,890 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at java.lang.Class.checkMemberAccess(Class.java:2348)
at java.lang.Class.getDeclaredConstructor(Class.java:2177)
at com.sun.xml.bind.v2.ClassFactory.create0(ClassFactory.java:104)
at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.createInstance(ClassBeanInfoImpl.java:285)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.createInstance(UnmarshallingContext.java:701)
at com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.startElement(StructureLoader.java:186)
at com.sun.xml.bind.v2.runtime.unmarshaller.ProxyLoader.startElement(ProxyLoader.java:60)
at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$IntercepterLoader.startElement(ElementBeanInfoImpl.java:253)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:576)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:555)
at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:168)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:498)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:283)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(XMLNSDocumentScannerImpl.java:733)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1754)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:875)
at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:798)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1198)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:564)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:258)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:229)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:136)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:183)
at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:85)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:181)
at java.security.AccessController.doPrivileged(Native Method)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:178)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
> JAXBUsageTestCase fails with security manager with security manager enabled
> ---------------------------------------------------------------------------
>
> Key: WFLY-6192
> URL: https://issues.jboss.org/browse/WFLY-6192
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Ivo Studensky
>
> *org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet}}
> Fails with:
> {code}
> ERROR [io.undertow.request] (default task-46) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Thread.getContextClassLoader(Thread.java:500)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)
> at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(AccessController.java:650)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (SECURITY-934) RolesSearch in AdvancedLdapLoginModule is doing a needless LDAP call for each individual role
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-934?page=com.atlassian.jira.plug... ]
Darran Lofthouse resolved SECURITY-934.
---------------------------------------
Resolution: Done
> RolesSearch in AdvancedLdapLoginModule is doing a needless LDAP call for each individual role
> ---------------------------------------------------------------------------------------------
>
> Key: SECURITY-934
> URL: https://issues.jboss.org/browse/SECURITY-934
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Reporter: Hynek Švábek
> Assignee: Romain Pelisse
>
> There will be needless LDAP calls if we use AdvancedLdap login module.
> If a user is a member of (lets say) 100 groups, then we can get an extra 100 calls to the LDAP server.
> It can be performance problem.
> Same problem was in LdapExt login module.
> You can see this BZ https://bugzilla.redhat.com/show_bug.cgi?id=1223840
> https://issues.jboss.org/browse/SECURITY-891
> Example from Wireshark for 2 groups:
> {code}
> * searchRequest(3) "ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" wholeSubtree
> * searchResEntry(3) "CN=JBossAdmin,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResEntry(3) "CN=Slash/Char,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(3) success [2 results]
> * searchRequest(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
> * searchResEntry(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(4) success [1 result]
> * searchRequest(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
> * searchResEntry(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(5) success [1 result]
> {code}|
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6662) Statement.cancel() is not invoked until the statement is completed
by lorenzo benvenuti (JIRA)
[ https://issues.jboss.org/browse/WFLY-6662?page=com.atlassian.jira.plugin.... ]
lorenzo benvenuti updated WFLY-6662:
------------------------------------
Description:
Hi,
in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
{code:java}
public void cancel() throws SQLException
{
if (doLocking)
lock();
try
{
/* ... */
{code}
It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock.
Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
Thank you,
lorenzo
was:
Hi,
in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
{code:java}
public void More ...cancel() throws SQLException
{
if (doLocking)
lock();
try
{
/* ... */
{code}
It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock.
Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
Thank you,
lorenzo
> Statement.cancel() is not invoked until the statement is completed
> ------------------------------------------------------------------
>
> Key: WFLY-6662
> URL: https://issues.jboss.org/browse/WFLY-6662
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 9.0.2.Final
> Reporter: lorenzo benvenuti
> Assignee: Jesper Pedersen
>
> Hi,
> in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
> {code:java}
> public void cancel() throws SQLException
> {
> if (doLocking)
> lock();
> try
> {
> /* ... */
> {code}
> It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock.
> Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
> Thank you,
> lorenzo
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6662) Statement.cancel() is not invoked until the statement is completed
by lorenzo benvenuti (JIRA)
lorenzo benvenuti created WFLY-6662:
---------------------------------------
Summary: Statement.cancel() is not invoked until the statement is completed
Key: WFLY-6662
URL: https://issues.jboss.org/browse/WFLY-6662
Project: WildFly
Issue Type: Bug
Components: JCA
Affects Versions: 9.0.2.Final
Reporter: lorenzo benvenuti
Assignee: Jesper Pedersen
Hi,
in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
{code:java}
public void More ...cancel() throws SQLException
{
if (doLocking)
lock();
try
{
/* ... */
{code}
It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock.
Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
Thank you,
lorenzo
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6661) Bean level lock type not applied
by Keio Kraaner (JIRA)
Keio Kraaner created WFLY-6661:
----------------------------------
Summary: Bean level lock type not applied
Key: WFLY-6661
URL: https://issues.jboss.org/browse/WFLY-6661
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.0.0.Final
Reporter: Keio Kraaner
A singleton EJB has @Lock(LockType.READ) annotation declared on the class level.
The bean is accessed using a local (defined by @Local annotation) or remote (defined by @Remote annotation) EJB interface.
SingletonComponent::getLockType returns wrong value (LockType.WRITE) because the beanLevelLockType map does not contain a key equal to the local or remote interface class name. It contains a key equal to the EJB class name that implements those interfaces.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JBJCA-1320) Unable to create JDBC local datasource without properties on JBoss EAP 7
by ted won (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1320?page=com.atlassian.jira.plugin... ]
ted won updated JBJCA-1320:
---------------------------
Description:
It should display warning message than throwing error as [WFLY-6198|https://issues.jboss.org/browse/WFLY-6198].
It's failed with error "IJ031103: At least one connection property must be defined for datasource-class" when it's doing migration from JBoss EAP 6 / WildFly 10 to JBoss EAP 7 or creating non-XA datasource for using local transactions in JBoss EAP 7.
In case of MySQL datasource classes it's possible to use datasource-class and create non-XA datasource in JBoss EAP 6 and WildFly 10 but not EAP 7.
was:
It should display warning message than throwing error as [WFLY-6198|https://issues.jboss.org/browse/WFLY-6198].
It's failed with error "IJ031103: At least one connection property must be defined for datasource-class" when it's doing migration from JBoss EAP 6 / WildFly 10 or creating non-XA datasource for using local transactions in JBoss EAP 7.
In case of MySQL datasource classes it's possible to use datasource-class and create non-XA datasource in JBoss EAP 6 and WildFly 10 but not EAP 7.
> Unable to create JDBC local datasource without properties on JBoss EAP 7
> ------------------------------------------------------------------------
>
> Key: JBJCA-1320
> URL: https://issues.jboss.org/browse/JBJCA-1320
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: WildFly/IronJacamar 1.3.3.Final
> Environment: JBoss EAP 7.0.0
> Reporter: ted won
> Assignee: ted won
> Priority: Minor
> Attachments: com.msql.tar.gz
>
>
> It should display warning message than throwing error as [WFLY-6198|https://issues.jboss.org/browse/WFLY-6198].
> It's failed with error "IJ031103: At least one connection property must be defined for datasource-class" when it's doing migration from JBoss EAP 6 / WildFly 10 to JBoss EAP 7 or creating non-XA datasource for using local transactions in JBoss EAP 7.
> In case of MySQL datasource classes it's possible to use datasource-class and create non-XA datasource in JBoss EAP 6 and WildFly 10 but not EAP 7.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6660) Allow to dump Artemis journal to file by CLI operation
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-6660?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-6660:
--------------------------------------
Yes, I saw this warning as well. Question is if this is because that all journal operations must be suspended for a while or it can corrupt the journal.
> Allow to dump Artemis journal to file by CLI operation
> ------------------------------------------------------
>
> Key: WFLY-6660
> URL: https://issues.jboss.org/browse/WFLY-6660
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Attachments: journal.txt
>
>
> For debugging and investigation purposes it would useful to have CLI operation which would dump content of Artemis journal directory.
> New CLI operation like {{print-journal-date-content}} would print content of journal to a file.
> It would do the same thing like following Artemis CLI command:
> {code}
> .../activemq-artemis/artemis-distribution/target/apache-artemis-1.3.0-SNAPSHOT-bin/apache-artemis-1.3.0-SNAPSHOT/bin/artemis data print --bindings bindings --journal journal --paging paging --large-messages largemessages
> {code}
> This should work only in Admin only mode as dumping journal in run-time is not possible when data changes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months