[JBoss JIRA] (JGRP-1813) JDBC_PING fails to recover for corruption issue
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1813?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1813.
----------------------------
Resolution: Done
> JDBC_PING fails to recover for corruption issue
> -----------------------------------------------
>
> Key: JGRP-1813
> URL: https://issues.jboss.org/browse/JGRP-1813
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.4
> Environment: Windows 7
> Reporter: Brett Donahue
> Assignee: Bela Ban
> Priority: Minor
> Labels: EOFException, JDBC_PING,, corruption
> Fix For: 3.5, 3.4.4
>
>
> heap space was exhausted and issues occurred. In the end, one node in the cluster must have corrupted the data in the JDBC_PING table. From this point onward, our log is full of these (every two seconds):
> 2014 03 23 04:00:25#+0100#ERROR#org.jgroups.protocols.SMP_JDBC_PING##anonymous#Thread-15###Error java.io.EOFException: null
> at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:340)
> at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:226)
> at org.jgroups.util.Util.readAddress(Util.java:929)
> at org.jgroups.util.Util.readAddresses(Util.java:1047)
> at org.jgroups.protocols.PingData.readFrom(PingData.java:163)
> at org.jgroups.util.Util.streamableFromByteBuffer(Util.java:753)
> at org.jgroups.protocols.Discovery.deserialize(Discovery.java:625)
> at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:221)
> at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:201)
> at org.jgroups.protocols.FILE_PING.fetchClusterMembers(FILE_PING.java:68)
> at org.jgroups.protocols.Discovery.sendDiscoveryRequest(Discovery.java:263)
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:227)
> at org.jgroups.protocols.Discovery.findInitialMembers(Discovery.java:208)
> at org.jgroups.protocols.Discovery.down(Discovery.java:551)
> at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:101)
> at org.jgroups.protocols.MERGE2.down(MERGE2.java:185)
> at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:363)
> at org.jgroups.protocols.FD.down(FD.java:307)
> at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:84)
> at org.jgroups.protocols.BARRIER.down(BARRIER.java:95)
> at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:533)
> at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:575)
> at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
> at org.jgroups.protocols.ENCRYPT.down(ENCRYPT.java:925)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.findInitialMembers(ClientGmsImpl.java:201)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:75)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:40)
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1052)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:340)
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:237)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1024)
> at org.jgroups.JChannel.down(JChannel.java:760)
> at org.jgroups.JChannel._connect(JChannel.java:538)
> at org.jgroups.JChannel.connect(JChannel.java:290)
> at org.jgroups.JChannel.connect(JChannel.java:275)
> at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.startCommunications(ClusterCommunicationsJGroupImpl.java:45)
> at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.<init>(ClusterCommunicationsJGroupImpl.java:59)
> at com.sap.mobile.platform.server.cluster.service.impl.ClusterServiceImpl.run(ClusterServiceImpl.java:187)
> at java.lang.Thread.run(Thread.java:791)
--
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
10 years, 1 month
[JBoss JIRA] (JGRP-1813) JDBC_PING fails to recover for corruption issue
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1813?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1813:
--------------------------------
OK, the row is removed when there's an exception reading it. I'm closing this issue now; please reopen if this still doesn't work.
> JDBC_PING fails to recover for corruption issue
> -----------------------------------------------
>
> Key: JGRP-1813
> URL: https://issues.jboss.org/browse/JGRP-1813
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.4
> Environment: Windows 7
> Reporter: Brett Donahue
> Assignee: Bela Ban
> Priority: Minor
> Labels: EOFException, JDBC_PING,, corruption
> Fix For: 3.5
>
>
> heap space was exhausted and issues occurred. In the end, one node in the cluster must have corrupted the data in the JDBC_PING table. From this point onward, our log is full of these (every two seconds):
> 2014 03 23 04:00:25#+0100#ERROR#org.jgroups.protocols.SMP_JDBC_PING##anonymous#Thread-15###Error java.io.EOFException: null
> at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:340)
> at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:226)
> at org.jgroups.util.Util.readAddress(Util.java:929)
> at org.jgroups.util.Util.readAddresses(Util.java:1047)
> at org.jgroups.protocols.PingData.readFrom(PingData.java:163)
> at org.jgroups.util.Util.streamableFromByteBuffer(Util.java:753)
> at org.jgroups.protocols.Discovery.deserialize(Discovery.java:625)
> at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:221)
> at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:201)
> at org.jgroups.protocols.FILE_PING.fetchClusterMembers(FILE_PING.java:68)
> at org.jgroups.protocols.Discovery.sendDiscoveryRequest(Discovery.java:263)
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:227)
> at org.jgroups.protocols.Discovery.findInitialMembers(Discovery.java:208)
> at org.jgroups.protocols.Discovery.down(Discovery.java:551)
> at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:101)
> at org.jgroups.protocols.MERGE2.down(MERGE2.java:185)
> at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:363)
> at org.jgroups.protocols.FD.down(FD.java:307)
> at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:84)
> at org.jgroups.protocols.BARRIER.down(BARRIER.java:95)
> at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:533)
> at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:575)
> at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
> at org.jgroups.protocols.ENCRYPT.down(ENCRYPT.java:925)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.findInitialMembers(ClientGmsImpl.java:201)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:75)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:40)
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1052)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:340)
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:237)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1024)
> at org.jgroups.JChannel.down(JChannel.java:760)
> at org.jgroups.JChannel._connect(JChannel.java:538)
> at org.jgroups.JChannel.connect(JChannel.java:290)
> at org.jgroups.JChannel.connect(JChannel.java:275)
> at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.startCommunications(ClusterCommunicationsJGroupImpl.java:45)
> at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.<init>(ClusterCommunicationsJGroupImpl.java:59)
> at com.sap.mobile.platform.server.cluster.service.impl.ClusterServiceImpl.run(ClusterServiceImpl.java:187)
> at java.lang.Thread.run(Thread.java:791)
--
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
10 years, 1 month
[JBoss JIRA] (WFLY-3033) Better SSO configuration
by Jason Kim (JIRA)
[ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.... ]
Jason Kim edited comment on WFLY-3033 at 3/27/14 9:52 PM:
----------------------------------------------------------
Disregard this comment. Pull Request at https://github.com/wildfly/wildfly/pull/6080 accomplishes what I was looking for.
was (Author: lc1207h):
I just enabled "path" configuration and am using it on my wildfly. Figured, some others may not want to wait for the update so I put in a pull request. Pull request - https://github.com/wildfly/wildfly/pull/6099
> Better SSO configuration
> ------------------------
>
> Key: WFLY-3033
> URL: https://issues.jboss.org/browse/WFLY-3033
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Tin Tvrtkovic
> Assignee: Tomaz Cerar
> Priority: Critical
> Labels: single-sign-on, undertow
> Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"
--
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
10 years, 1 month
[JBoss JIRA] (WFLY-3144) Session replication doesn't work as expected
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-3144:
--------------------------------------
This is a Weld issue. See WELD-1635 for fix.
The fix in WildFly will require a Weld upgrade.
> Session replication doesn't work as expected
> --------------------------------------------
>
> Key: WFLY-3144
> URL: https://issues.jboss.org/browse/WFLY-3144
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, Clustering, EJB
> Affects Versions: 8.0.0.Final
> Reporter: Tomas Remes
> Assignee: Radoslav Husar
> Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly.
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.
--
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
10 years, 1 month
[JBoss JIRA] (WFLY-3144) Session replication doesn't work as expected
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-3144:
---------------------------------
Fix Version/s: 8.0.1.Final
> Session replication doesn't work as expected
> --------------------------------------------
>
> Key: WFLY-3144
> URL: https://issues.jboss.org/browse/WFLY-3144
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, Clustering, EJB
> Affects Versions: 8.0.0.Final
> Reporter: Tomas Remes
> Assignee: Radoslav Husar
> Fix For: 8.0.1.Final
>
> Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly.
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.
--
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
10 years, 1 month
[JBoss JIRA] (WFLY-3033) Better SSO configuration
by Jason Kim (JIRA)
[ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.... ]
Jason Kim commented on WFLY-3033:
---------------------------------
I just enabled "path" configuration and am using it on my wildfly. Figured, some others may not want to wait for the update so I put in a pull request. Pull request - https://github.com/wildfly/wildfly/pull/6099
> Better SSO configuration
> ------------------------
>
> Key: WFLY-3033
> URL: https://issues.jboss.org/browse/WFLY-3033
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Tin Tvrtkovic
> Assignee: Tomaz Cerar
> Priority: Critical
> Labels: single-sign-on, undertow
> Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"
--
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
10 years, 1 month
[JBoss JIRA] (WFLY-3185) Strip cluster name from node names
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-3185:
----------------------------------
Summary: Strip cluster name from node names
Key: WFLY-3185
URL: https://issues.jboss.org/browse/WFLY-3185
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 9.0.0.CR1
Currently, we generate cluster node names using the following format:
node-name/cluster-name
Including the cluster-name in the node name is redundant and only serves to add unnecessary bytes to messages.
We just need to make sure to include the cluster name in any log messages that refer to the node name.
--
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
10 years, 1 month
[JBoss JIRA] (DROOLS-458) Drools lock in StatelessKnowledgeSessionImpl.
by Desmond Silveira (JIRA)
[ https://issues.jboss.org/browse/DROOLS-458?page=com.atlassian.jira.plugin... ]
Desmond Silveira commented on DROOLS-458:
-----------------------------------------
I looked through the relevant Drools source code in detail, and I would agree that the synchronization _seems_ to be implemented correctly. But the fact that I had so many threads blocked for a long period of time certainly seems to indicate that there's a problem in the code.
> Drools lock in StatelessKnowledgeSessionImpl.
> ---------------------------------------------
>
> Key: DROOLS-458
> URL: https://issues.jboss.org/browse/DROOLS-458
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Environment: Tomcat 7
> Reporter: Desmond Silveira
> Assignee: Mario Fusco
> Attachments: la3ldspg05b.txt
>
>
> My Tomcat HTTP BIO connector threads (129 of them) got BLOCKED in my production Tomcat 7 instance because Drool 6.0.1 wasn't releasing a lock.
> Here is a snippet of the thread dump:
> {noformat}
> "http-bio-172.16.216.19-80-exec-37513" - Thread t@6245360
> java.lang.Thread.State: BLOCKED
> at org.drools.core.runtime.process.ProcessRuntimeFactory.getProcessRuntimeFactoryService(ProcessRuntimeFactory.java:20)
> - waiting to lock <219dcd77> (a java.lang.Class) owned by "http-bio-172.16.216.19-80-exec-37511" t@6245358
> at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:12)
> at org.drools.core.common.AbstractWorkingMemory.createProcessRuntime(AbstractWorkingMemory.java:405)
> at org.drools.core.common.AbstractWorkingMemory.setKnowledgeRuntime(AbstractWorkingMemory.java:1770)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:125)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:139)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> at com.local.lds.LdsBean.search(LdsBean.java:200)
> at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> - locked <3575a054> (a org.apache.tomcat.util.net.SocketWrapper)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Locked ownable synchronizers:
> - locked <719df963> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37511" - Thread t@6245358
> java.lang.Thread.State: RUNNABLE
> at org.kie.internal.utils.ServiceRegistryImpl.addDefault(ServiceRegistryImpl.java:212)
> - locked <3d710637> (a org.kie.internal.utils.ServiceRegistryImpl)
> at org.kie.internal.utils.ServiceRegistryImpl.addDefault(ServiceRegistryImpl.java:207)
> - locked <3d710637> (a org.kie.internal.utils.ServiceRegistryImpl)
> at org.drools.core.runtime.process.ProcessRuntimeFactory.loadProvider(ProcessRuntimeFactory.java:27)
> at org.drools.core.runtime.process.ProcessRuntimeFactory.getProcessRuntimeFactoryService(ProcessRuntimeFactory.java:21)
> - locked <219dcd77> (a java.lang.Class)
> at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:12)
> at org.drools.core.common.AbstractWorkingMemory.createProcessRuntime(AbstractWorkingMemory.java:405)
> at org.drools.core.common.AbstractWorkingMemory.setKnowledgeRuntime(AbstractWorkingMemory.java:1770)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:125)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:139)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> at com.local.lds.LdsBean.search(LdsBean.java:200)
> at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> - locked <474f2464> (a org.apache.tomcat.util.net.SocketWrapper)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Locked ownable synchronizers:
> - locked <339f344e> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37447" - Thread t@6233953
> java.lang.Thread.State: BLOCKED
> at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:82)
> - waiting to lock <555896b3> (a org.drools.core.common.ProjectClassLoader) owned by "http-bio-172.16.216.19-80-exec-37519" t@6245366
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:122)
> at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:46)
> at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:89)
> at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
> at org.drools.core.common.AbstractWorkingMemory.initInitialFact(AbstractWorkingMemory.java:385)
> at org.drools.core.common.AbstractWorkingMemory.<init>(AbstractWorkingMemory.java:378)
> at org.drools.core.common.AbstractWorkingMemory.<init>(AbstractWorkingMemory.java:261)
> at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:15)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:134)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:397)
> at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> at com.local.lds.LdsBean.search(LdsBean.java:200)
> at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> - locked <57e6b780> (a org.apache.tomcat.util.net.SocketWrapper)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Locked ownable synchronizers:
> - locked <726294fc> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "http-bio-172.16.216.19-80-exec-37519" - Thread t@6245366
> java.lang.Thread.State: RUNNABLE
> at java.lang.ClassLoader.findLoadedClass0(Native Method)
> at java.lang.ClassLoader.findLoadedClass(Unknown Source)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> - locked <555896b3> (a org.drools.core.common.ProjectClassLoader)
> at org.drools.core.common.ProjectClassLoader.internalLoadClass(ProjectClassLoader.java:99)
> at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:82)
> - locked <555896b3> (a org.drools.core.common.ProjectClassLoader)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at org.drools.core.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:122)
> at org.drools.core.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:46)
> at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:89)
> at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:71)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:164)
> at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:400)
> at com.local.lds.RuleEngineBean.applyKnowledge(RuleEngineBean.java:50)
> at com.local.lds.LdsBean.search(LdsBean.java:200)
> at com.local.lds.servlet.SearchServlet.doGet(SearchServlet.java:55)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
> - locked <43c2901> (a org.apache.tomcat.util.net.SocketWrapper)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Locked ownable synchronizers:
> - locked <88f8fa9> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {noformat}
> Here is the code that I use to call Drools:
> {code:java}
> public static Collection<ResultSet> applyRule(String rule,
> KieBase kb, Collection<ResultSet> resultSets, SearchParameters params) {
> try {
> if (kb == null) {
> return resultSets;
> }
> StatelessKieSession ksession = kb.newStatelessKieSession();
> ksession.setGlobal(OUTPUT, new ArrayList<>());
> Collection<Object> collection = new ArrayList<Object>(resultSets);
> collection.add(params);
> ksession.execute(collection);
> return (Collection<ResultSet>) ksession.getGlobals().get(OUTPUT);
> } catch (ConsequenceException e) {
> LOG.error("Error in rule: " + rule + " " + e.getRule(), e);
> throw e;
> } catch (RuntimeException e) {
> LOG.error("Error in rule: " + rule, e);
> throw e;
> }
> }
> {code}
--
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
10 years, 1 month
[JBoss JIRA] (WFLY-3100) ClassCastException in JSPs where spring-web tags and jstl tags are used
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3100?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-3100.
-------------------------------
Assignee: Shelly McGowan (was: Remy Maucherat)
Fix Version/s: 8.0.1.Final
Resolution: Done
Fixed version of spec jsp api was merged to master.
> ClassCastException in JSPs where spring-web tags and jstl tags are used
> -----------------------------------------------------------------------
>
> Key: WFLY-3100
> URL: https://issues.jboss.org/browse/WFLY-3100
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE, Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: abhishek vijra
> Assignee: Shelly McGowan
> Labels: jsp, jstl
> Fix For: 8.0.1.Final
>
> Attachments: spring-fun.war
>
>
> Following JSP with spring tags
> <%@ page contentType="text/html;charset=UTF-8" language="java" %>
> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
> <%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>
> <html>
> <head><title>Simple jsp page</title></head>
> <body>
>
> <c:set var="hasError" value="${param.hasError}" />
> <c:set var="msg" value="${param.msg}" />
>
> <c:if test="${param.hasError=='true'}">
> Message: <spring:message text="${param.msg}"/>
> </c:if>
>
> </body>
> </html>
> breaks following error
> ERROR [org.springframework.web.servlet.tags.MessageTag] (default task-1) org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects: java.lang.ClassCastException: org.apache.taglibs.standard.lang.jstl.ImplicitObjects cannot be cast to javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects
> at javax.servlet.jsp.el.ImplicitObjectELResolver$ImplicitObjects.getImplicitObjects(ImplicitObjectELResolver.java:608) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.jsp.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:169) [jboss-jsp-api_2.3_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:95) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:32) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.el.ELResolverImpl.getValue(ELResolverImpl.java:78) [jastow-1.0.0.Final.jar:1.0.0.Final]
> at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-3.0.0.jar:3.0.0]
> at com.sun.el.parser.AstValue.getBase(AstValue.java:151) [javax.el-3.0.0.jar:3.0.0]
> at com.sun.el.parser.AstValue.getValue(AstValue.java:200) [javax.el-3.0.0.jar:3.0.0]
> There are two jars (jboss-jsp-api_2.3_spec-1.0.0.Final.jar and jboss-jstl-api_1.2_spec-1.0.4.Final.jar) that are incompatible with each other due to a bug -- both are storing an object in the same place, but the objects are not compatible.
> The result is that a jsp page cannot contain both JSTL and Spring tags, or it will get that error.
--
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
10 years, 1 month