[JBoss JIRA] (DROOLS-5621) KieComponentFactory should not declare non static logger field
by Christian Martensen (Jira)
Christian Martensen created DROOLS-5621:
-------------------------------------------
Summary: KieComponentFactory should not declare non static logger field
Key: DROOLS-5621
URL: https://issues.redhat.com/browse/DROOLS-5621
Project: Drools
Issue Type: Bug
Affects Versions: 7.42.0.Final
Reporter: Christian Martensen
Assignee: Mario Fusco
h3. Description
The serializable class org.drools.core.reteoo.KieComponentFactory declares a non static logger field (currently unused).
{code:java}
Logger logger = LoggerFactory.getLogger(KieComponentFactory.class);
{code}
When serializing the object this causes problems if the used slf4j logger is not serializable. This will also cause problems if the used logger is not available during deserialization.
h3. Desired solution
Either declare the logger field as static or remove it since it is unused.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined with JDK8 now
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ]
Jan Stourac commented on WFWIP-339:
-----------------------------------
[~fjuma], thank you for the explanation and for the fix! I understand now. I've also tested your changes and re-run our pipeline and all looks okay now!
I'm gonna resolve this one. Thank you again!
> OpenSSL security provider seems to be used when not defined with JDK8 now
> -------------------------------------------------------------------------
>
> Key: WFWIP-339
> URL: https://issues.redhat.com/browse/WFWIP-339
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
> Attachments: client.jks, server.jks, standalone-full.xml
>
>
> It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. I also see this change of behavior only with JDK8. JDK11 works as expected!
> Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
> {quote}
> 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {quote}
> This INFO message starts to occur in the server log since 'server-ssl-context' or 'client-ssl-contexts' are added into the server configuration and server is started with JDK8:
> {code}
> <server-ssl-contexts>
> <server-ssl-context name="server-ssl-context" need-client-auth="true" key-manager="server-ssl-contextKM" trust-manager="server-ssl-contextTM"/>
> </server-ssl-contexts>
> <client-ssl-contexts>
> <client-ssl-context name="proxy-ssl-context" key-manager="proxy-ssl-contextKM" trust-manager="proxy-ssl-contextTM"/>
> </client-ssl-contexts>
> {code}
> There are two questions from this:
> # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected?
> # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. Not to mention that we don't want to behave differently for JDK8 and JDK11.
> Hope I don't have any misconfiguration in the configuration itself.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined with JDK8 now
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ]
Jan Stourac resolved WFWIP-339.
-------------------------------
Resolution: Done
> OpenSSL security provider seems to be used when not defined with JDK8 now
> -------------------------------------------------------------------------
>
> Key: WFWIP-339
> URL: https://issues.redhat.com/browse/WFWIP-339
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
> Attachments: client.jks, server.jks, standalone-full.xml
>
>
> It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. I also see this change of behavior only with JDK8. JDK11 works as expected!
> Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
> {quote}
> 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {quote}
> This INFO message starts to occur in the server log since 'server-ssl-context' or 'client-ssl-contexts' are added into the server configuration and server is started with JDK8:
> {code}
> <server-ssl-contexts>
> <server-ssl-context name="server-ssl-context" need-client-auth="true" key-manager="server-ssl-contextKM" trust-manager="server-ssl-contextTM"/>
> </server-ssl-contexts>
> <client-ssl-contexts>
> <client-ssl-context name="proxy-ssl-context" key-manager="proxy-ssl-contextKM" trust-manager="proxy-ssl-contextTM"/>
> </client-ssl-contexts>
> {code}
> There are two questions from this:
> # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected?
> # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. Not to mention that we don't want to behave differently for JDK8 and JDK11.
> Hope I don't have any misconfiguration in the configuration itself.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[JBoss JIRA] (WFLY-13824) Use TimeUtil timeout adjustments in cases of timeout defined on JMS receive
by Ondrej Chaloupka (Jira)
Ondrej Chaloupka created WFLY-13824:
---------------------------------------
Summary: Use TimeUtil timeout adjustments in cases of timeout defined on JMS receive
Key: WFLY-13824
URL: https://issues.redhat.com/browse/WFLY-13824
Project: WildFly
Issue Type: Enhancement
Components: Test Suite
Affects Versions: 20.0.1.Final
Reporter: Ondrej Chaloupka
Assignee: Ondrej Chaloupka
There are several places in testsuite where is omitted usage of {{TimeoutUtil}} to allow adjustment of timeouts. When user defines the property {{-Dtimeout.factor}} when he runs the testsuite the waiting timeout for the JMS receival should be adjusted as well.
This issue comes from issues hit on Narayana CI. The machine is slow and running the WildFly testsuite with the Narayana SNAPSHOTs is unstable because of timeouts are not configurable at many places.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[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 updated JGRP-2418:
---------------------------
Description:
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.
was:
When sending a message (_of any type_), it is currently marshalled into a byte[] array, which is handled diffently 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.
> 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, 1 month
[JBoss JIRA] (JGRP-1424) TP: use of multiple transports
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-1424?page=com.atlassian.jira.plugin... ]
Bela Ban closed JGRP-1424.
--------------------------
Resolution: Won't Do
See comments. We can also revisit this should the need arise to have multiple transports.
> TP: use of multiple transports
> ------------------------------
>
> Key: JGRP-1424
> URL: https://issues.redhat.com/browse/JGRP-1424
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> Refactor TP so that the socket sending and receiving is done in a separate class (UDP, TCP, TCP_NIO). Once this is done, add the ability to attach multiple transports to TP, e.g. UDP and TCP.
> The UDP transport could then be used for cluster wide messages (null destination) and the TCP transport could be used for unicast messages (non-null destination).
> Or this could be overridden by a message flag on a per-message basis !
> We could even attach multiple transports of the same type, e.g. one per physical network (10.x.x.x and 192.168.x.x), and do round-robin sending over them.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[JBoss JIRA] (JGRP-1424) TP: use of multiple transports
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-1424?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-1424:
--------------------------------
Thanks for the feedback, Dan!
I'm curious: on what criteria do users typically pick a stack in Infinispan? Cloud -> "cloud", IP multicasting disabled -> "tcp", else "udp"?
You're kind of supporting my arguments against multiple transports. I guess I need to do some more thinking, but I'm inclined to kill this feature for now. Perhaps, one day a scenario will appear that warrants revisiting this...
Cheers,
> TP: use of multiple transports
> ------------------------------
>
> Key: JGRP-1424
> URL: https://issues.redhat.com/browse/JGRP-1424
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> Refactor TP so that the socket sending and receiving is done in a separate class (UDP, TCP, TCP_NIO). Once this is done, add the ability to attach multiple transports to TP, e.g. UDP and TCP.
> The UDP transport could then be used for cluster wide messages (null destination) and the TCP transport could be used for unicast messages (non-null destination).
> Or this could be overridden by a message flag on a per-message basis !
> We could even attach multiple transports of the same type, e.g. one per physical network (10.x.x.x and 192.168.x.x), and do round-robin sending over them.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month