[JBoss JIRA] (WFLY-13471) Warn the ws deployment packaged with JAXP implementation
by Jim Ma (Jira)
[ https://issues.redhat.com/browse/WFLY-13471?page=com.atlassian.jira.plugi... ]
Jim Ma updated WFLY-13471:
--------------------------
Summary: Warn the ws deployment packaged with JAXP implementation (was: Fail the ws deployment packaged with JAXP implementation)
> Warn the ws deployment packaged with JAXP implementation
> --------------------------------------------------------
>
> Key: WFLY-13471
> URL: https://issues.redhat.com/browse/WFLY-13471
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 19.1.0.Final
> Reporter: Jim Ma
> Assignee: Jim Ma
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> Deploy JAXWS application that packages an older JAXP implementation.
> Try to get the wsdl: wget http://localhost:8080/helloWorld?wsdl
> When the container is performing operations, it should use the container's JAXP implementation, else it could fail if the application is packaging a version that is not compatible.
> {code}
> 19:28:42,560 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.3.0.GA (WildFly Core 10.1.2.Final-redhat-00001) started in 4091ms - Started 426 of 652 services (374 services are lazy, passive or on-demand)
> 19:28:45,537 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /helloWorld: java.lang.AbstractMethodError: org.apache.xerces.dom.DeferredDocumentImpl.setXmlStandalone(Z)V
> at org.apache.cxf.frontend.WSDLGetUtils.updateDoc(WSDLGetUtils.java:332)
> at org.apache.cxf.frontend.WSDLGetUtils.writeWSDLDocument(WSDLGetUtils.java:708)
> at org.apache.cxf.frontend.WSDLGetUtils.getDocument(WSDLGetUtils.java:151)
> at org.apache.cxf.frontend.WSDLGetInterceptor.getDocument(WSDLGetInterceptor.java:129)
> at org.apache.cxf.frontend.WSDLGetInterceptor.handleMessage(WSDLGetInterceptor.java:77)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
> at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:110)
> at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:225)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:503)
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
> ...
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (DROOLS-5427) Update Type in Traffic Violation example
by Anna Dupliak (Jira)
Anna Dupliak created DROOLS-5427:
------------------------------------
Summary: Update Type in Traffic Violation example
Key: DROOLS-5427
URL: https://issues.redhat.com/browse/DROOLS-5427
Project: Drools
Issue Type: Task
Components: Scenario Simulation and Testing
Affects Versions: 7.38.0.Final
Reporter: Anna Dupliak
Assignee: Anna Dupliak
Since we changed a constraints type mechanism we the old test scenario got failing
So need to recreate scesim file in Traffic Violation example.
workarounds:
if you recreate scesim
if you remove that column and add it again, no error is raised
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (DROOLS-4446) Confusing scenario validation message for collection types
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4446?page=com.atlassian.jira.plug... ]
Jozef Marko closed DROOLS-4446.
-------------------------------
Fix Version/s: 7.39.0.Final
Resolution: Out of Date
Thank you [~yamer]. I can confirm this is not reproducible anymore. Closing.
> Confusing scenario validation message for collection types
> ----------------------------------------------------------
>
> Key: DROOLS-4446
> URL: https://issues.redhat.com/browse/DROOLS-4446
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing
> Affects Versions: 7.26.0.Final
> Reporter: Jozef Marko
> Assignee: Yeser Amer
> Priority: Minor
> Labels: drools-tools
> Fix For: 7.39.0.Final
>
> Attachments: Screenshot from 2019-08-20 10-19-46.png, Screenshot from 2020-06-10 16-24-49.png
>
>
> There is small enhancement needed if the user validates dmn scenario with *collection* data type, being previously simple data type.
> h2. Steps to reproduce
> - Create new DMN
> - Define there custom data type *LKW:string*
> - Set this LKW type for some *input data* node
> - Save DMN
> - Create a Scenario for this DMN
> - Go back to DMN
> - Check tickbox *Is Collection* for the *LKW* type
> - Save DMN
> - Validate Scenario, you will get message as shown in the picture. It can be confusing as it says *LKW* changed to *LKW*
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (JGRP-1618) missingMessageReceived() never called in NAKACK resulting in memory leak
by Senthil SP (Jira)
[ https://issues.redhat.com/browse/JGRP-1618?page=com.atlassian.jira.plugin... ]
Senthil SP edited comment on JGRP-1618 at 6/11/20 1:26 AM:
-----------------------------------------------------------
[~bbn-tlv] [~belaban] - We are also facing exactly the same issue, but the messages accumulate in xmit_table instead of xmit_stats.
was (Author: senthil.aru):
[~bbn-tlv] [~belaban] - We are also facing exactly the same issue, but the messages accumulates in xmit_table instead of xmit_stats.
> missingMessageReceived() never called in NAKACK resulting in memory leak
> ------------------------------------------------------------------------
>
> Key: JGRP-1618
> URL: https://issues.redhat.com/browse/JGRP-1618
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.8.1, 2.12.2
> Environment: Java 6
> Reporter: Harry Mark
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.2.9, 3.3
>
> Attachments: 1618-jgrp-patch.jar, NakReceiverWindow.java, screenshot-1.png
>
>
> We are using JGroups 2.8.1 and encountered a memory leak where it eventually ran out of CMS Old Gen memory. The heap dump revealed that the problem was in the xmit_stats ConcurrentHashMap of org.jgroups.protocols.pbcast.NAKACK.
> After much analysis here's what we found: when the system is under load, messages can start arriving out of order. When the receiver receives a higher sequence number than expected, it requests the sender retransmit the missing messages with the lower sequence numbers. The sender sends the missing message, however the bug in the NakReceiverWindow meant that the missing message was never purged from the Map that tracks missing messages (xmit_stats) because missingMessageReceived() was never invoked. Over time this Map grows and starts using up CMS Old Gen; the only way it would get reduced was when a server left the cluster and the missing messages were purged for that server.
> In JMX, the MissingMsgsReceived attribute of jgroups:cluster=*,protocol=NAKACK,type=protocol was always zero, confirming that it never purged any received "missing messages".
> When I looked at the most recent GA version 3.2.8 of NakReceiverWindow.java , it has the corrected logic that ensures that missingMessageReceived() is called. I checked the the most recent 2.x, which is 2.12.2, and found it also has the same bug in the logic as 2.8.1. This bug may apply to other 2.x but I did not check.
> Attached is the fixed NakReceiverWindow.java for 2.8.1.
> After applying the patch, the memory leak went away.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (JGRP-1618) missingMessageReceived() never called in NAKACK resulting in memory leak
by Senthil SP (Jira)
[ https://issues.redhat.com/browse/JGRP-1618?page=com.atlassian.jira.plugin... ]
Senthil SP commented on JGRP-1618:
----------------------------------
[~bbn-tlv] [~belaban] - Exactly the same issue, but the messages accumulates in xmit_table instead of xmit_stats.
> missingMessageReceived() never called in NAKACK resulting in memory leak
> ------------------------------------------------------------------------
>
> Key: JGRP-1618
> URL: https://issues.redhat.com/browse/JGRP-1618
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.8.1, 2.12.2
> Environment: Java 6
> Reporter: Harry Mark
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.2.9, 3.3
>
> Attachments: 1618-jgrp-patch.jar, NakReceiverWindow.java, screenshot-1.png
>
>
> We are using JGroups 2.8.1 and encountered a memory leak where it eventually ran out of CMS Old Gen memory. The heap dump revealed that the problem was in the xmit_stats ConcurrentHashMap of org.jgroups.protocols.pbcast.NAKACK.
> After much analysis here's what we found: when the system is under load, messages can start arriving out of order. When the receiver receives a higher sequence number than expected, it requests the sender retransmit the missing messages with the lower sequence numbers. The sender sends the missing message, however the bug in the NakReceiverWindow meant that the missing message was never purged from the Map that tracks missing messages (xmit_stats) because missingMessageReceived() was never invoked. Over time this Map grows and starts using up CMS Old Gen; the only way it would get reduced was when a server left the cluster and the missing messages were purged for that server.
> In JMX, the MissingMsgsReceived attribute of jgroups:cluster=*,protocol=NAKACK,type=protocol was always zero, confirming that it never purged any received "missing messages".
> When I looked at the most recent GA version 3.2.8 of NakReceiverWindow.java , it has the corrected logic that ensures that missingMessageReceived() is called. I checked the the most recent 2.x, which is 2.12.2, and found it also has the same bug in the logic as 2.8.1. This bug may apply to other 2.x but I did not check.
> Attached is the fixed NakReceiverWindow.java for 2.8.1.
> After applying the patch, the memory leak went away.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (JGRP-1618) missingMessageReceived() never called in NAKACK resulting in memory leak
by Senthil SP (Jira)
[ https://issues.redhat.com/browse/JGRP-1618?page=com.atlassian.jira.plugin... ]
Senthil SP edited comment on JGRP-1618 at 6/11/20 1:25 AM:
-----------------------------------------------------------
[~bbn-tlv] [~belaban] - We are also facing exactly the same issue, but the messages accumulates in xmit_table instead of xmit_stats.
was (Author: senthil.aru):
[~bbn-tlv] [~belaban] - Exactly the same issue, but the messages accumulates in xmit_table instead of xmit_stats.
> missingMessageReceived() never called in NAKACK resulting in memory leak
> ------------------------------------------------------------------------
>
> Key: JGRP-1618
> URL: https://issues.redhat.com/browse/JGRP-1618
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.8.1, 2.12.2
> Environment: Java 6
> Reporter: Harry Mark
> Assignee: Bela Ban
> Priority: Major
> Fix For: 3.2.9, 3.3
>
> Attachments: 1618-jgrp-patch.jar, NakReceiverWindow.java, screenshot-1.png
>
>
> We are using JGroups 2.8.1 and encountered a memory leak where it eventually ran out of CMS Old Gen memory. The heap dump revealed that the problem was in the xmit_stats ConcurrentHashMap of org.jgroups.protocols.pbcast.NAKACK.
> After much analysis here's what we found: when the system is under load, messages can start arriving out of order. When the receiver receives a higher sequence number than expected, it requests the sender retransmit the missing messages with the lower sequence numbers. The sender sends the missing message, however the bug in the NakReceiverWindow meant that the missing message was never purged from the Map that tracks missing messages (xmit_stats) because missingMessageReceived() was never invoked. Over time this Map grows and starts using up CMS Old Gen; the only way it would get reduced was when a server left the cluster and the missing messages were purged for that server.
> In JMX, the MissingMsgsReceived attribute of jgroups:cluster=*,protocol=NAKACK,type=protocol was always zero, confirming that it never purged any received "missing messages".
> When I looked at the most recent GA version 3.2.8 of NakReceiverWindow.java , it has the corrected logic that ensures that missingMessageReceived() is called. I checked the the most recent 2.x, which is 2.12.2, and found it also has the same bug in the logic as 2.8.1. This bug may apply to other 2.x but I did not check.
> Attached is the fixed NakReceiverWindow.java for 2.8.1.
> After applying the patch, the memory leak went away.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (DROOLS-5384) Clicking rightmost column's header in DMN decision table raises an error
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5384?page=com.atlassian.jira.plug... ]
Jozef Marko commented on DROOLS-5384:
-------------------------------------
[~dadossan] thank you for looking into the issue. I updated the acceptance criteria as a note what to try during review as I see the fix comes to general appformer grid framework.
> Clicking rightmost column's header in DMN decision table raises an error
> ------------------------------------------------------------------------
>
> Key: DROOLS-5384
> URL: https://issues.redhat.com/browse/DROOLS-5384
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.38.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Fix For: 7.39.0.Final
>
> Attachments: dmn-decision-table-error-popup-7.38.0.png, drools5384.mp4
>
>
> When I import Traffic_Violation sample, opened a "Fine" decision table. The rightmost column's header is empty ("Enter Text") and I get an error pop-up when clicked. (At the first time, it raises an error popup. After that, the header is unresponsive)
> See screenshot.
> Chrome 80.0.3987.122
> Firefox 60.6.2
> h3. Acceptance criteria
> - DMN grids are not affected
> - GDST grid is unaffected
> - Scesim grid is unaffected
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (DROOLS-5384) Clicking rightmost column's header in DMN decision table raises an error
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5384?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5384:
--------------------------------
Description:
When I import Traffic_Violation sample, opened a "Fine" decision table. The rightmost column's header is empty ("Enter Text") and I get an error pop-up when clicked. (At the first time, it raises an error popup. After that, the header is unresponsive)
See screenshot.
Chrome 80.0.3987.122
Firefox 60.6.2
h3. Acceptance criteria
- DMN grids are not affected
- GDST grid is unaffected
- Scesim grid is unaffected
was:
When I import Traffic_Violation sample, opened a "Fine" decision table. The rightmost column's header is empty ("Enter Text") and I get an error pop-up when clicked. (At the first time, it raises an error popup. After that, the header is unresponsive)
See screenshot.
Chrome 80.0.3987.122
Firefox 60.6.2
> Clicking rightmost column's header in DMN decision table raises an error
> ------------------------------------------------------------------------
>
> Key: DROOLS-5384
> URL: https://issues.redhat.com/browse/DROOLS-5384
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.38.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Fix For: 7.39.0.Final
>
> Attachments: dmn-decision-table-error-popup-7.38.0.png, drools5384.mp4
>
>
> When I import Traffic_Violation sample, opened a "Fine" decision table. The rightmost column's header is empty ("Enter Text") and I get an error pop-up when clicked. (At the first time, it raises an error popup. After that, the header is unresponsive)
> See screenshot.
> Chrome 80.0.3987.122
> Firefox 60.6.2
> h3. Acceptance criteria
> - DMN grids are not affected
> - GDST grid is unaffected
> - Scesim grid is unaffected
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months