[JBoss JIRA] (WFLY-8335) User should be informed when switching between JDBC and journal store in transactions subsystem
by Romain Pelisse (JIRA)
Romain Pelisse created WFLY-8335:
------------------------------------
Summary: User should be informed when switching between JDBC and journal store in transactions subsystem
Key: WFLY-8335
URL: https://issues.jboss.org/browse/WFLY-8335
Project: WildFly
Issue Type: Enhancement
Components: Transactions
Affects Versions: 10.1.0.Final
Reporter: Romain Pelisse
Assignee: Romain Pelisse
Priority: Minor
Precondition: 'Use journal store' or 'Use JDBC store' was previously set to true.
When enabling other type of store, user is not informed about the fact, that only one of those can be set and the previously enabled store is disabled and the new store is enabled without notification. User should be definitely informed about this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-6916) Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty
by Rodrigo Veleda (JIRA)
[ https://issues.jboss.org/browse/WFLY-6916?page=com.atlassian.jira.plugin.... ]
Rodrigo Veleda edited comment on WFLY-6916 at 3/10/17 9:28 AM:
---------------------------------------------------------------
[~boda.prakash] Yes. Adding this entry to the web.xml file fixed the ZipException for me. My issue was exactly as the same as yours, assuming you've also followed the steps for setting up multiple JSF-installations within Wildfly 10. Let me know if it works for you as well.
was (Author: rveleda):
[~boda.prakash] Yes. Adding this entry to the web.xml file fixed the ZipException for me. My issue was exactly the same as yours, assuming you've also followed the steps for setting up multiple JSF-installations within Wildfly 10. Let me know if it works for you as well.
> Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6916
> URL: https://issues.jboss.org/browse/WFLY-6916
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Environment: Wildfly 10 final
> Java 8
> Reporter: Prakash Boda
> Assignee: Farah Juma
>
> Below is the stacktrace.
> 2016-08-03 15:26:50,061 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 98) WFLYUT0021: Registered web context: /productName-services
> 2016-08-03 15:26:52,532 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) Unable to process annotations for url, vfs:/E:/V6/productName/wildfly-10.0.0.Final/bin/content/virtuosoapp.ear/jboss-seam-2.3.0.Final.jar/META-INF/faces-config.xml. Reason: java.util.zip.ZipException: zip file is empty
> 2016-08-03 15:26:52,570 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) : java.util.zip.ZipException: zip file is empty
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.<init>(ZipFile.java:219)
> at java.util.zip.ZipFile.<init>(ZipFile.java:149)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:88)
> at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:221)
> at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:216)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:215)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:71)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:109)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89)
> at com.sun.faces.config.JavaClassScanningAnnotationScanner.processClasspath(JavaClassScanningAnnotationScanner.java:166)
> at com.sun.faces.config.JavaClassScanningAnnotationScanner.getAnnotatedClasses(JavaClassScanningAnnotationScanner.java:125)
> at com.sun.faces.config.DelegatingAnnotationProvider.getAnnotatedClasses(DelegatingAnnotationProvider.java:85)
> at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:841)
> at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:793)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:351)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Suppressed: java.nio.file.NoSuchFileException: C:\Users\bodap\AppData\Local\Temp\jar_cache5902044866304783743.tmp
> at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
> at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
> at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
> at java.nio.file.Files.delete(Files.java:1126)
> at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:226)
> ... 25 more
> After this error also deployment is successful.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-6916) Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty
by Rodrigo Veleda (JIRA)
[ https://issues.jboss.org/browse/WFLY-6916?page=com.atlassian.jira.plugin.... ]
Rodrigo Veleda commented on WFLY-6916:
--------------------------------------
[~boda.prakash] Yes. Adding this entry to the web.xml file fixed the ZipException for me. My issue was exactly the same as yours, assuming you've also followed the steps for setting up multiple JSF-installations within Wildfly 10. Let me know if it works for you as well.
> Wildfly 10 with JSF(mojarra 2.1.18) give java.util.zip.ZipException: zip file is empty
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6916
> URL: https://issues.jboss.org/browse/WFLY-6916
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Environment: Wildfly 10 final
> Java 8
> Reporter: Prakash Boda
> Assignee: Farah Juma
>
> Below is the stacktrace.
> 2016-08-03 15:26:50,061 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 98) WFLYUT0021: Registered web context: /productName-services
> 2016-08-03 15:26:52,532 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) Unable to process annotations for url, vfs:/E:/V6/productName/wildfly-10.0.0.Final/bin/content/virtuosoapp.ear/jboss-seam-2.3.0.Final.jar/META-INF/faces-config.xml. Reason: java.util.zip.ZipException: zip file is empty
> 2016-08-03 15:26:52,570 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 69) : java.util.zip.ZipException: zip file is empty
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.<init>(ZipFile.java:219)
> at java.util.zip.ZipFile.<init>(ZipFile.java:149)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:88)
> at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:221)
> at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:216)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:215)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:71)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:109)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89)
> at com.sun.faces.config.JavaClassScanningAnnotationScanner.processClasspath(JavaClassScanningAnnotationScanner.java:166)
> at com.sun.faces.config.JavaClassScanningAnnotationScanner.getAnnotatedClasses(JavaClassScanningAnnotationScanner.java:125)
> at com.sun.faces.config.DelegatingAnnotationProvider.getAnnotatedClasses(DelegatingAnnotationProvider.java:85)
> at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:841)
> at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:793)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:351)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Suppressed: java.nio.file.NoSuchFileException: C:\Users\bodap\AppData\Local\Temp\jar_cache5902044866304783743.tmp
> at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
> at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
> at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
> at java.nio.file.Files.delete(Files.java:1126)
> at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:226)
> ... 25 more
> After this error also deployment is successful.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2162) Failed to send broadcast when opening the connection
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-2162?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated JGRP-2162:
------------------------------
Description:
IRC discussion:
{quote}
bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side.
<bela_> rvansa: reproducible?
<rvansa> bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending"
<rvansa> bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be
<bela_> rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit
<bela_> rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don’t wait long enough
<rvansa> bela_: I don't think it should go over the limit
<rvansa> bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting
<rvansa> bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message
{quote}
I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]):
{code:xml}
<TCPPING async_discovery="true" initial_hosts="${jgroups.tcpping.initial_hosts:localhost[7800]}" port_range="0"/>
{code}
This causes that the physical connection is not opened by discovery. However, the reproducer suffers from (always reproducible) flaw - it does not send the message to third node at all (and the test fails, therefore).
Note that increasing the timeout in request options does not help.
was:
IRC discussion:
{quote}
bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side.
<bela_> rvansa: reproducible?
<rvansa> bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending"
<rvansa> bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be
<bela_> rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit
<bela_> rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don’t wait long enough
<rvansa> bela_: I don't think it should go over the limit
<rvansa> bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting
<rvansa> bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message
{quote}
I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]):
{code:xml}
<TCPPING async_discovery="true" initial_hosts="${jgroups.tcpping.initial_hosts:localhost[7800]}" port_range="0"/>
{code}
This causes that the physical connection is not open. However, the reproducer suffers from (always reproducible) flaw, not sending the message to third node at all.
> Failed to send broadcast when opening the connection
> ----------------------------------------------------
>
> Key: JGRP-2162
> URL: https://issues.jboss.org/browse/JGRP-2162
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Attachments: TcpNio2McastTest.java
>
>
> IRC discussion:
> {quote}
> bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side.
> <bela_> rvansa: reproducible?
> <rvansa> bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending"
> <rvansa> bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be
> <bela_> rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit
> <bela_> rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don’t wait long enough
> <rvansa> bela_: I don't think it should go over the limit
> <rvansa> bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting
> <rvansa> bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message
> {quote}
> I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]):
> {code:xml}
> <TCPPING async_discovery="true" initial_hosts="${jgroups.tcpping.initial_hosts:localhost[7800]}" port_range="0"/>
> {code}
> This causes that the physical connection is not opened by discovery. However, the reproducer suffers from (always reproducible) flaw - it does not send the message to third node at all (and the test fails, therefore).
> Note that increasing the timeout in request options does not help.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2162) Failed to send broadcast when opening the connection
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-2162?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated JGRP-2162:
------------------------------
Description:
IRC discussion:
{quote}
bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side.
<bela_> rvansa: reproducible?
<rvansa> bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending"
<rvansa> bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be
<bela_> rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit
<bela_> rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don’t wait long enough
<rvansa> bela_: I don't think it should go over the limit
<rvansa> bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting
<rvansa> bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message
{quote}
I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]):
{code:xml}
<TCPPING async_discovery="true" initial_hosts="${jgroups.tcpping.initial_hosts:localhost[7800]}" port_range="0"/>
{code}
This causes that the physical connection is not open. However, the reproducer suffers from (always reproducible) flaw, not sending the message to third node at all.
was:
IRC disucssion:
{quote}
bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side.
<bela_> rvansa: reproducible?
<rvansa> bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending"
<rvansa> bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be
<bela_> rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit
<bela_> rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don’t wait long enough
<rvansa> bela_: I don't think it should go over the limit
<rvansa> bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting
<rvansa> bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message
{quote}
I was trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCP_PING with only the first node in hosts list (localhost[7800]) - this causes that the physical connection is not open. However, the reproducer suffers from (always reproducible) flaw, not sending the message to third node at all.
> Failed to send broadcast when opening the connection
> ----------------------------------------------------
>
> Key: JGRP-2162
> URL: https://issues.jboss.org/browse/JGRP-2162
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Attachments: TcpNio2McastTest.java
>
>
> IRC discussion:
> {quote}
> bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side.
> <bela_> rvansa: reproducible?
> <rvansa> bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending"
> <rvansa> bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be
> <bela_> rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit
> <bela_> rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don’t wait long enough
> <rvansa> bela_: I don't think it should go over the limit
> <rvansa> bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting
> <rvansa> bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message
> {quote}
> I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]):
> {code:xml}
> <TCPPING async_discovery="true" initial_hosts="${jgroups.tcpping.initial_hosts:localhost[7800]}" port_range="0"/>
> {code}
> This causes that the physical connection is not open. However, the reproducer suffers from (always reproducible) flaw, not sending the message to third node at all.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2162) Failed to send broadcast when opening the connection
by Radim Vansa (JIRA)
Radim Vansa created JGRP-2162:
---------------------------------
Summary: Failed to send broadcast when opening the connection
Key: JGRP-2162
URL: https://issues.jboss.org/browse/JGRP-2162
Project: JGroups
Issue Type: Bug
Reporter: Radim Vansa
Assignee: Bela Ban
Attachments: TcpNio2McastTest.java
IRC disucssion:
{quote}
bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side.
<bela_> rvansa: reproducible?
<rvansa> bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending"
<rvansa> bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be
<bela_> rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit
<bela_> rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don’t wait long enough
<rvansa> bela_: I don't think it should go over the limit
<rvansa> bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting
<rvansa> bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message
{quote}
I was trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCP_PING with only the first node in hosts list (localhost[7800]) - this causes that the physical connection is not open. However, the reproducer suffers from (always reproducible) flaw, not sending the message to third node at all.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2517) Coverity, Dereference after null check (Elytron subsystem)
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2517?page=com.atlassian.jira.plugi... ]
Ilia Vassilev reassigned WFCORE-2517:
-------------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> Coverity, Dereference after null check (Elytron subsystem)
> ----------------------------------------------------------
>
> Key: WFCORE-2517
> URL: https://issues.jboss.org/browse/WFCORE-2517
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
>
> Coverity found possible dereference of null. In this code {{defaultPolicy}} is checked for null and in next step {{defaultPolicy.equals()}} is called.
> https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=10578...
> {code:java|title=PolicyParser.java}
> boolean providerFound = defaultPolicy == null;
> while (reader.hasNext() && reader.nextTag() != END_ELEMENT) {
> verifyNamespace(reader);
> String localName = reader.getLocalName();
> switch (localName) {
> // Permission Mapper
> case JACC_POLICY:
> providerFound = defaultPolicy.equals(parseJaccPolicy(addPolicy, reader, operations)) || providerFound;
> break;
> case CUSTOM_POLICY:
> providerFound = defaultPolicy.equals(parseCustomPolicy(addPolicy, reader, operations)) || providerFound;
> break;
> default:
> throw unexpectedElement(reader);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8334) It's not possible to set username and password for datasource in elytron-only configuration
by Flavia Rainone (JIRA)
Flavia Rainone created WFLY-8334:
------------------------------------
Summary: It's not possible to set username and password for datasource in elytron-only configuration
Key: WFLY-8334
URL: https://issues.jboss.org/browse/WFLY-8334
Project: WildFly
Issue Type: Bug
Components: JCA
Reporter: Flavia Rainone
Assignee: Flavia Rainone
elytron-only = configuration with elytron subsystem and without security subsystem
It's not possible to set username and password for datasource in elytron-only configuration.
In elytron-only configuration, attribute elytron-enabled has to be set to true otherwise datasource service fails to start because of dependencies on legacy security services (see JBEAP-8763).
But when elytron-enabled=true then it's not possible to use username and password (credential-reference doesn't seem to be taken into account - looks like bug with current behavior).
I expect that users will want to use simple username and password even in elytron-only configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months