[JBoss JIRA] (WFCORE-1033) ManagedDatagramSocketBinding and ManagedMulticastSocketBinding throw NPE if created with bind address
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1033?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1033:
-------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1268185|https://bugzilla.redhat.com/show_bug.cgi?id=1268185] from MODIFIED to ON_QA
> ManagedDatagramSocketBinding and ManagedMulticastSocketBinding throw NPE if created with bind address
> -----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1033
> URL: https://issues.jboss.org/browse/WFCORE-1033
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 2.0.0.CR6
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
> Fix For: 2.0.0.CR7
>
>
> {noformat}
> &#27;[0m&#27;[31m14:51:47,114 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector: java.lang.NullPointerException
> at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:96)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 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)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.network.ManagedMulticastSocketBinding.bind(ManagedMulticastSocketBinding.java:78)
> at java.net.MulticastSocket.<init>(MulticastSocket.java:172)
> at org.jboss.as.network.ManagedMulticastSocketBinding.<init>(ManagedMulticastSocketBinding.java:54)
> at org.jboss.as.network.ManagedMulticastSocketBinding.create(ManagedMulticastSocketBinding.java:40)
> at org.jboss.as.network.SocketBindingManagerImpl.createMulticastSocket(SocketBindingManagerImpl.java:82)
> at org.jboss.as.clustering.jgroups.ManagedSocketFactoryNew.createMulticastSocket(ManagedSocketFactoryNew.java:127)
> at org.jgroups.util.Util.createMulticastSocket(Util.java:3089)
> at org.jgroups.protocols.MPING.start(MPING.java:190)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> at org.jgroups.JChannel.startStack(JChannel.java:890)
> at org.jgroups.JChannel._preConnect(JChannel.java:553)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
> {noformat}
> This is because the MulticastSocket and DatagramSocket constructors call bind(...), but the ManagedBindingRegistry is not yet set.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (JBJCA-1276) Prefill race condition in flush
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1276?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1276:
------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1231658|https://bugzilla.redhat.com/show_bug.cgi?id=1231658] from MODIFIED to ON_QA
> Prefill race condition in flush
> -------------------------------
>
> Key: JBJCA-1276
> URL: https://issues.jboss.org/browse/JBJCA-1276
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: 1.0.31.Final, 1.1.9.Final
> Reporter: Takayoshi Kimura
> Assignee: Jesper Pedersen
> Fix For: 1.0.33.Final
>
> Attachments: server.log
>
>
> There is a race condition between AbstractPool and SemaphoreArrayListManagedConnectionPool.
> https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.0.31.Final/...
> https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.0.31.Final/...
> AbstractPool flushes the mcp, mcp invokes PoolFiller which works in a separate thread. However AbstractPool is going to unregister the empty mcp and this mcp is no longer used. Then the dead mcp is prefilled in a separate thread by PoolFiller.
> At next getConnection(), the mcp is re-initialized and prefilled.
> I've attached logs, prefill enabled and min-size is 10. Boot server, invoke flush-all-connection-in-pool, getConnection() then killed. The prefill is done 3 times where it should be twice.
> {noformat}
> 16:26:04,254 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 1) ExampleDS: flush(true)
> 16:26:04,255 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 1) Destroying flushed connection org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@1d298ed8[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@4ae26a1b connection handles=0 lastUse=1434353148384 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@56a43905 pool internal context=SemaphoreArrayListManagedConnectionPool@5cbd770e[pool=ExampleDS] xaResource=LocalXAResourceImpl@379ba3b3[connectionListener=1d298ed8 connectionManager=4b18594a warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2012-07-13) jndiName=java:jboss/datasources/ExampleDS] txSync=null]
> (repeat 10 times)
> 16:02:20,666 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 7) Shutdown - Pool: ExampleDS MCP: 2f5a2102
> 16:02:20,666 TRACE [org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory] (JCA PoolFiller) Using properties: {user=sa, password=--hidden--}
> 16:02:20,666 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (management-handler-thread - 7) Unregister pool: SemaphoreArrayListManagedConnectionPool@2f5a2102[pool=ExampleDS]
> 16:26:04,259 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (JCA PoolFiller) Filling pool cl=org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@34f0bb27[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@288f1898 connection handles=0 lastUse=1434353164259 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@56a43905 pool internal context=SemaphoreArrayListManagedConnectionPool@5cbd770e[pool=ExampleDS] xaResource=LocalXAResourceImpl@4a97b7f5[connectionListener=34f0bb27 connectionManager=4b18594a warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2012-07-13) jndiName=java:jboss/datasources/ExampleDS] txSync=null]
> (repeat 10 times)
> 16:26:11,342 TRACE [org.jboss.jca.core.connectionmanager.TxConnectionManager] (http-/127.0.0.1:8080-1) getManagedConnection interleaving=false , tx=null
> 16:26:11,343 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (http-/127.0.0.1:8080-1) Register pool: SemaphoreArrayListManagedConnectionPool@1d4ae61f[pool=ExampleDS] (interval=1800000)
> 16:26:11,344 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (JCA PoolFiller) Filling pool cl=org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@1c706b4d[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@18949ad1 connection handles=0 lastUse=1434353171343 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@56a43905 pool internal context=SemaphoreArrayListManagedConnectionPool@1d4ae61f[pool=ExampleDS] xaResource=LocalXAResourceImpl@44401bf2[connectionListener=1c706b4d connectionManager=4b18594a warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2012-07-13) jndiName=java:jboss/datasources/ExampleDS] txSync=null]
> (repeat 10 times)
> {noformat}
> In 1.0.31.Final:
> > if (mcp.isEmpty())
> > clearMcpPools.add(mcp);
> In 1.2 branch it looks like already fixed within commit 956af09c8494d4187db24a253e7e37b5ba5d9779 for JBJCA-1135:
> > if (mcp.isEmpty() && !isPrefill() && size > 1)
> > clearMcpPools.add(mcp);
> We probably need to backport "!isPrefill()" to the 1.0/1.1 branch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (WFLY-5556) Configure remote tx timeout via system property
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-5556?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-5556:
-----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1265300|https://bugzilla.redhat.com/show_bug.cgi?id=1265300] from MODIFIED to ON_QA
> Configure remote tx timeout via system property
> -----------------------------------------------
>
> Key: WFLY-5556
> URL: https://issues.jboss.org/browse/WFLY-5556
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
> Fix For: 10.0.0.CR4
>
>
> Description of problem:
> The hardcoded 5 minute timeout period was replace with Integer.MAX_VALUE for the timeout period of "remote" distributed transaction branches.
> - https://issues.jboss.org/browse/WFLY-2789
> - https://bugzilla.redhat.com/show_bug.cgi?id=1056585#c1
> An "infinite" timeout is a problem as this value is also passed to the database to control statement execution. This means that database statements may run uncontrolled in most cases. Too, in one case we have seen that the database driver or the database is mishandling the value and aborting almost immediately (e.g. after only 2 or 3 seconds).
> Version-Release number of selected component (if applicable):
> How reproducible:
> Consistently
> Steps to Reproduce:
> 1. Start a transaction in server "one"
> 2. Using JTA/EJB remoting, propagate that transaction to a remote server
> 3. The timeout for the transaction on the remote can be seen to be Integer.MAX_VALUE
> Actual results:
> Either an "infinite" timeout period for database statement execution or else an immediate abort
> Expected results:
> A "reasonable" smaller value must be used.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (WFLY-5340) Unable to specify module when specifying custom JACC policy class.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-5340?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-5340:
-----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1263336|https://bugzilla.redhat.com/show_bug.cgi?id=1263336] from MODIFIED to ON_QA
> Unable to specify module when specifying custom JACC policy class.
> ------------------------------------------------------------------
>
> Key: WFLY-5340
> URL: https://issues.jboss.org/browse/WFLY-5340
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.Beta2
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 10.0.0.CR1
>
>
> It is currently possible to specify the 'javax.security.jacc.policy.provider' system property, however it is not possible to specify a module.
> From the JACC specification: -
> _For each JRE of a J2EE 1.4 or later version Java EE application server, if the
> system property
> “javax.security.jacc.policy.provider
> ” is defined,
> the application server must construct an
> instance of the class identified by the
> system property, confirm that the
> resulting object is an instance of
> java.security.Policy,
> and set, by calling the
> java.security.Policy.setPolicy
> method, the resulting object as the
> corresponding Policy object u
> sed by the JRE. _
> The specification only specifies that the system property identifies the class, it does not specify how.
> In it's simplest form we should assume this is just a class name, in a more complex form we should allow the module to be specified.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (SECURITY-882) Fix for SECURITY-868 breaks flush-cache capability
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-882?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-882:
--------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1219778|https://bugzilla.redhat.com/show_bug.cgi?id=1219778] from MODIFIED to ON_QA
> Fix for SECURITY-868 breaks flush-cache capability
> --------------------------------------------------
>
> Key: SECURITY-882
> URL: https://issues.jboss.org/browse/SECURITY-882
> Project: PicketBox
> Issue Type: Bug
> Components: AS-Integration
> Affects Versions: PicketBox_4_0_19.Final
> Environment: EAP 6.3.3, JDV 6.1.0
> Reporter: Hisanobu Okuda
> Assignee: Stefan Guilhen
>
> The member field ThreadLocal<CompoundInfo> validatedDomainInfo was introduced for the fix of SECURITY-868. When you are authenticated, a valid security info is stored in the field thread-locally. Then, you flushes the JAAS cache via CLI or API in another thread, org.jboss.security.authentication.JBossCachedAuthenticationManager.flushCache() is invoked, but validatedDomainInfo is not flushed properly, since it is ThreadLocal. As a result, a cached security info is re-used unexpectedly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month