[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession
by andrew asa (Jira)
[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ]
andrew asa edited comment on JGRP-2299 at 4/28/19 5:10 AM:
-----------------------------------------------------------
LockService can use udp? when client sent GRANT_LOCK to coord,and coord sent LOCK_GRANTED to client,but udp user DatagramSocket to send msg to client ,something client can no reciver LOCK_GRANTED msg ,that will make client
block on lock method.
any thing i Consider missing。
was (Author: andrew.asa):
LockService can use udp? when client sent GRANT_LOCK to coord,and coord sent LOCK_GRANTED to client,and udp user DatagramSocket to send msg to client ,but something error client can no reciver LOCK_GRANTED msg ,that will make client
block on lock method.
any thing i Consider missing。
> LockService does not work correctly if unlock/lock is called in immediate succession
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2299
> URL: https://issues.jboss.org/browse/JGRP-2299
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Environment: Windows 10 Oracle JDK 1.8 131
> AIX IBM Java 8
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.1
>
> Attachments: JGroupsExample.java, udp+lock.xml
>
>
> In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
> This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
> If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months
[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession
by andrew asa (Jira)
[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ]
andrew asa edited comment on JGRP-2299 at 4/28/19 5:09 AM:
-----------------------------------------------------------
LockService can use udp? when client sent GRANT_LOCK to coord,and coord sent LOCK_GRANTED to client,and udp user DatagramSocket to send msg to client ,but something error client can no reciver LOCK_GRANTED msg ,that will make client
block on lock method.
any thing i Consider missing。
was (Author: andrew.asa):
LockService can use upd? when client sent GRANT_LOCK to coord,and coord sent LOCK_GRANTED to client,and udp user DatagramSocket to send msg to client ,but something error client can no reciver LOCK_GRANTED msg ,that will make client
block on lock method.
any thing i Consider missing。
> LockService does not work correctly if unlock/lock is called in immediate succession
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2299
> URL: https://issues.jboss.org/browse/JGRP-2299
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Environment: Windows 10 Oracle JDK 1.8 131
> AIX IBM Java 8
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.1
>
> Attachments: JGroupsExample.java, udp+lock.xml
>
>
> In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
> This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
> If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months
[JBoss JIRA] (DROOLS-1540) Drools does not work with spring-boot-devtools
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-1540?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1540:
-------------------------------------
Let me clarify a bit more what happens here. A Drools knowledge base implements a (highly customizied and improved) variance of the rete algorithm https://en.wikipedia.org/wiki/Rete_algorithm. There the first layer of the alpha network is made by what we call Object Type nodes. The role of OTNs is performing a first discrimination based on the type (class) of the object to be matched. For instance if a rule is pattern matching on an object of class Person the corresponding OTN will filter only the objects that are instances of that class.
Given my current understanding what spring-boot-devtools does is "transparently" creating a different version of that Person class on a different classloader. The problem is that in this way the Person OTN is not able to match instances of this second Person class and then no rule can fire. I disagree that this is a Drools limitation: even if the OTN would be able to match this new Person object, for instance using the class name instead of the class itself (something that it is not possible because it would break polymorphism support) we would just delay the problem to a later stage of the network when I will get a ClassCastException when any of the alpha or beta nodes will try to read a property of the object.
[~snicoll] I'd really would love to solve this problem, but I haven't found a solution yet and unfortunately I'm not sure that I'm understanding what you're suggesting. What do you mean with "specify the classloader"? Is there a way to be notified when spring-boot-devtools decides to create a different classloader? If so I could try to "rewire" the knowledge base against the new classloader. Thanks for clarification.
> Drools does not work with spring-boot-devtools
> ----------------------------------------------
>
> Key: DROOLS-1540
> URL: https://issues.jboss.org/browse/DROOLS-1540
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Reporter: G Xiong
> Assignee: Mario Fusco
> Priority: Critical
> Attachments: complete.zip
>
>
> Drools does work with spring-boot-devtools.
> If you add in pom.xml the following, no rules will be fired in Drools.
> <dependency>
> <groupId>org.springframework.boot</groupId>
> <artifactId>spring-boot-devtools</artifactId>
> </dependency>
> if you comment out this, then rules will be fired in Drools.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months
[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession
by andrew asa (Jira)
[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ]
andrew asa commented on JGRP-2299:
----------------------------------
LockService can use upd? when client sent GRANT_LOCK to coord,and coord sent LOCK_GRANTED to client,and udp user DatagramSocket to send msg to client ,but something error client can no reciver LOCK_GRANTED msg ,that will make client
block on lock method.
any thing i Consider missing。
> LockService does not work correctly if unlock/lock is called in immediate succession
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2299
> URL: https://issues.jboss.org/browse/JGRP-2299
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Environment: Windows 10 Oracle JDK 1.8 131
> AIX IBM Java 8
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.1
>
> Attachments: JGroupsExample.java, udp+lock.xml
>
>
> In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
> This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
> If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months
[JBoss JIRA] (DROOLS-1540) Drools does not work with spring-boot-devtools
by Stéphane Nicoll (Jira)
[ https://issues.jboss.org/browse/DROOLS-1540?page=com.atlassian.jira.plugi... ]
Stéphane Nicoll commented on DROOLS-1540:
-----------------------------------------
Does that mean that instances must be loaded by the launcher classloader in order to be used by Drools? Would it be possible to alleviate this limitation, for instance by allowing to specify the {{ClassLoader}} to use rather than using an hardcoded one?
> Drools does not work with spring-boot-devtools
> ----------------------------------------------
>
> Key: DROOLS-1540
> URL: https://issues.jboss.org/browse/DROOLS-1540
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Reporter: G Xiong
> Assignee: Mario Fusco
> Priority: Critical
> Attachments: complete.zip
>
>
> Drools does work with spring-boot-devtools.
> If you add in pom.xml the following, no rules will be fired in Drools.
> <dependency>
> <groupId>org.springframework.boot</groupId>
> <artifactId>spring-boot-devtools</artifactId>
> </dependency>
> if you comment out this, then rules will be fired in Drools.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months
[JBoss JIRA] (WFLY-11986) HAL Console places <datasource-class> in <datasource> element in standalone.xml. It leads to Test Connection fail
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11986?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-11986:
------------------------------------
Component/s: Web Console
[~harald.pehl] FYI. I don't know if this is a console issue or a server-side issue.
> HAL Console places <datasource-class> in <datasource> element in standalone.xml. It leads to Test Connection fail
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11986
> URL: https://issues.jboss.org/browse/WFLY-11986
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Web Console
> Affects Versions: 16.0.0.Final
> Environment: Windows 10 Pro RU, MSSQL Server 2008 on remote machine, Microsoft JDBC driver. mssql-jdbc-6.2.2.jre7
> Reporter: Dmitry Lazarev
> Assignee: Stefano Maestri
> Priority: Major
>
> When Datasource for MSSQL is created through HAL Management console, it inserts tag <datasource-class>com.microsoft.sqlserver.jdbc.SQLServerDataSource</datasource-class> in <datasource> element in standalone.xml.
> Then when I try to test connection it fails with error "WFLYJCA0040: failed to invoke operation: WFLYJCA0047: Connection is not valid" If i remove element <datasource-class> manualy from standalone.xml, Test Connection works properly.
> 2019-04-12 17:01:15,500 WARN [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (External Management Request Threads -- 2) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: IJ031084: Unable to create connection
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:345)
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:352)
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:287)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1325)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:499)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:1067)
> at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:93)
> at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:240)
> at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:97)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1412)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.jboss.as.controller.ModelControllerImpl$$Lambda$489/1626912192.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity$$Lambda$491/1133081806.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:289)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:255)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:93)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler$$Lambda$541/1958155244.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity$$Lambda$542/1328593333.run(Unknown Source)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:313)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:270)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> at org.jboss.as.domain.http.server.security.ElytronIdentityHandler.handleRequest(ElytronIdentityHandler.java:61)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:364)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Не удалось установить соединение TCP/IP к серверу localhost по порту 1433. Ошибка: "Connection refused: no further information. Проверьте свойства соединения. Убедитесь, что на сервере запущен экземпляр SQL Server и он принимает TCP/IP-соединения по порту. Убедитесь, что TCP-соединения по этому порту не блокируются брандмауэром.".
> at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(SQLServerException.java:227)
> at com.microsoft.sqlserver.jdbc.SQLServerException.ConvertConnectExceptionToSQLServerException(SQLServerException.java:284)
> at com.microsoft.sqlserver.jdbc.SocketFinder.findSocket(IOBuffer.java:2435)
> at com.microsoft.sqlserver.jdbc.TDSChannel.open(IOBuffer.java:635)
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:2010)
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:1687)
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectInternal(SQLServerConnection.java:1528)
> at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:866)
> at com.microsoft.sqlserver.jdbc.SQLServerDataSource.getConnectionInternal(SQLServerDataSource.java:968)
> at com.microsoft.sqlserver.jdbc.SQLServerDataSource.getConnection(SQLServerDataSource.java:78)
> at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:314)
> ... 39 more
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months