[JBoss JIRA] (ELY-2026) UnsupportedOperationException in SSLEngine using jdk 251+
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/ELY-2026?page=com.atlassian.jira.plugin.... ]
Ricardo Martin Camarero updated ELY-2026:
-----------------------------------------
Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/1448
> UnsupportedOperationException in SSLEngine using jdk 251+
> ---------------------------------------------------------
>
> Key: ELY-2026
> URL: https://issues.redhat.com/browse/ELY-2026
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.10.9.Final
> Reporter: Ricardo Martin Camarero
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.13.1.Final
>
>
> Some SSLEngines provided by elytron does not implement the new TLS methods that jdk-8 251+ incorporated from jdk-11. That makes some tests in the wildfly-http-client to fail with the following exception:
> {code}
> 12:07:31,031 ERROR (XNIO-3 I/O-1) [org.xnio.listener] <ChannelListeners.java:94> XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException:
> java.lang.reflect.InvocationTargetException
> at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:99)
> at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:81)
> at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:77)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1211)
> at io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1286)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:94)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:97)
> ... 8 more
> Caused by: java.lang.UnsupportedOperationException
> at org.wildfly.security.ssl.JDKSpecific.getApplicationProtocol(JDKSpecific.java:35)
> at org.wildfly.security.ssl.AbstractDelegatingSSLEngine.getApplicationProtocol(AbstractDelegatingSSLEngine.java:166)
> ... 13 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ELY-2026) UnsupportedOperationException in SSLEngine using jdk 251+
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/ELY-2026?page=com.atlassian.jira.plugin.... ]
Farah Juma resolved ELY-2026.
-----------------------------
Resolution: Done
> UnsupportedOperationException in SSLEngine using jdk 251+
> ---------------------------------------------------------
>
> Key: ELY-2026
> URL: https://issues.redhat.com/browse/ELY-2026
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.10.9.Final
> Reporter: Ricardo Martin Camarero
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.13.1.Final
>
>
> Some SSLEngines provided by elytron does not implement the new TLS methods that jdk-8 251+ incorporated from jdk-11. That makes some tests in the wildfly-http-client to fail with the following exception:
> {code}
> 12:07:31,031 ERROR (XNIO-3 I/O-1) [org.xnio.listener] <ChannelListeners.java:94> XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException:
> java.lang.reflect.InvocationTargetException
> at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:99)
> at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:81)
> at io.undertow.client.ALPNClientSelector$2.handleEvent(ALPNClientSelector.java:77)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1211)
> at io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1286)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:94)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:97)
> ... 8 more
> Caused by: java.lang.UnsupportedOperationException
> at org.wildfly.security.ssl.JDKSpecific.getApplicationProtocol(JDKSpecific.java:35)
> at org.wildfly.security.ssl.AbstractDelegatingSSLEngine.getApplicationProtocol(AbstractDelegatingSSLEngine.java:166)
> ... 13 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (DROOLS-5687) NullPointerException on second consecutive declared type update
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5687?page=com.atlassian.jira.plug... ]
Mario Fusco reopened DROOLS-5687:
---------------------------------
> NullPointerException on second consecutive declared type update
> ---------------------------------------------------------------
>
> Key: DROOLS-5687
> URL: https://issues.redhat.com/browse/DROOLS-5687
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.43.0.Final
> Reporter: Matteo Casalino
> Assignee: Mario Fusco
> Priority: Major
> Attachments: npe-consecutives-declare-update-skip-kiebase-init.zip, npe-consecutives-declare-update-skip-kiebase-init.zip, npe-consecutives-declare-update.zip
>
>
> When updating a {{KieContainer}} with {{updateToVersion}} with a change in a declared type two consecutive times, a {{NullPointerException}} is raised.
> Minimal example DRL triggering the issue (notice at least two declared types are needed):
> {noformat}
> declare FactType1
> x : int
> end
> declare FactType2
> y : int
> end
> {noformat}
> first update:
> {noformat}
> declare FactType1
> x : int
> z : int
> end
> declare FactType2
> y : int
> end
> {noformat}
> second update:
> {noformat}
> declare FactType1
> x : int
> z : int
> w : int
> end
> declare FactType2
> y : int
> end
> {noformat}
> The second update will raise the following exception:
> {noformat}
> java.lang.NullPointerException
> at org.drools.compiler.kie.util.ChangeSetBuilder.build(ChangeSetBuilder.java:106)
> at org.drools.compiler.kie.builder.impl.InternalKieModule.getChanges(InternalKieModule.java:132)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:241)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:237)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:195)
> at org.example.reproducer.KjarUpdateTest.update(KjarUpdateTest.java:37)
> at org.example.reproducer.KjarUpdateTest.testConsecutiveUpdates(KjarUpdateTest.java:48)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (JGRP-2418) Impedence mismatch between message types and transports
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2418?page=com.atlassian.jira.plugin... ]
Bela Ban edited comment on JGRP-2418 at 10/7/20 11:16 AM:
----------------------------------------------------------
When sending a message, marshalling is done in the bundler. When receiving a message, unmarshalling is done in the transport.
We should do marshalling/unmarshalling at the same level, in the *transport*. This means that marshalling would be moved to the transport (further down from the bundler in the stack). This way, UDP / TCP could marshal messages into a byte array, and then pass it to the DatagramSocket / Socket. TCP_NIO2, however, would do the same, but pass *NIO messages* (direct or heap-based) directly to the SocketChannel, thereby avoiding the unnecessary conversion from ByteBuffer to byte array to ByteBuffer.
was (Author: belaban):
When sending a message, marshalling is done in the bundler. When receiving a message, unmarshalling is done in the transport.
We should do marshalling/unmarshalling at the same level, in the *transport*. This means that marshalling would be moved to the transport (further down from the bundler in the stack). This way, UDP / TCP could marshal messages into a byte array, and then pass it to the DatagramSocket / Socket. TCP_NIO2, however, would do the same, but pass NIO messages (direct or heap-based) directly to the SocketChannel, thereby avoiding the unnecessary conversion from ByteBuffer to byte array to ByteBuffer.
> Impedence mismatch between message types and transports
> -------------------------------------------------------
>
> Key: JGRP-2418
> URL: https://issues.redhat.com/browse/JGRP-2418
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> When sending a message (_of any type_), it is currently marshalled into a byte[] array, which is handled differently by each transport:
> * UDP wraps it into a DatagramPacket and calls DatagramSocket.send()
> * TCP writes the array to the socket's output stream
> * TCP_NIO2 wraps it into a {{ByteBuffer}} and calls SocketChannel.write(ByteBuffer)
> In some cases, there is an impedance mismatch between the type of the message and the type of the transport: for example, when sending an NioMessage (containing a ByteBuffer), we don't actually need the conversion to byte array and the subsequent wrapping into a ByteBuffer, this is superfluous. Even worse, when using off-heap, this creates unneeded memory allocation. Passing the *same* ByteBuffer all the way down from the application to the transport would be beneficial.
> This requires changes in the way bundlers accumulate messages. Also, perhaps the transport itself should become an SPI, to which a generic {{Transport}} protocol delegates. This would also allow up to implement multiple transports (JGRP-1424) in the same stack.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (JGRP-2418) Impedence mismatch between message types and transports
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2418?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2418:
--------------------------------
When sending a message, marshalling is done in the bundler. When receiving a message, unmarshalling is done in the transport.
We should do marshalling/unmarshalling at the same level, in the *transport*. This means that marshalling would be moved to the transport (further down from the bundler in the stack). This way, UDP / TCP could marshal messages into a byte array, and then pass it to the DatagramSocket / Socket. TCP_NIO2, however, would do the same, but pass NIO messages (direct or heap-based) directly to the SocketChannel, thereby avoiding the unnecessary conversion from ByteBuffer to byte array to ByteBuffer.
> Impedence mismatch between message types and transports
> -------------------------------------------------------
>
> Key: JGRP-2418
> URL: https://issues.redhat.com/browse/JGRP-2418
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> When sending a message (_of any type_), it is currently marshalled into a byte[] array, which is handled differently by each transport:
> * UDP wraps it into a DatagramPacket and calls DatagramSocket.send()
> * TCP writes the array to the socket's output stream
> * TCP_NIO2 wraps it into a {{ByteBuffer}} and calls SocketChannel.write(ByteBuffer)
> In some cases, there is an impedance mismatch between the type of the message and the type of the transport: for example, when sending an NioMessage (containing a ByteBuffer), we don't actually need the conversion to byte array and the subsequent wrapping into a ByteBuffer, this is superfluous. Even worse, when using off-heap, this creates unneeded memory allocation. Passing the *same* ByteBuffer all the way down from the application to the transport would be beneficial.
> This requires changes in the way bundlers accumulate messages. Also, perhaps the transport itself should become an SPI, to which a generic {{Transport}} protocol delegates. This would also allow up to implement multiple transports (JGRP-1424) in the same stack.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (DROOLS-5703) Put common "generation code" inside one place
by Gabriele Cardosi (Jira)
Gabriele Cardosi created DROOLS-5703:
----------------------------------------
Summary: Put common "generation code" inside one place
Key: DROOLS-5703
URL: https://issues.redhat.com/browse/DROOLS-5703
Project: Drools
Issue Type: Enhancement
Reporter: Gabriele Cardosi
Assignee: Gabriele Cardosi
There is functionally duplicated code between kogito-runimte/PredictionCodegen and kie-maven-plugin/GeneratePMMLMojo.
Identify, isolate and put in common place as much as possible of it
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months