[JBoss JIRA] (ELY-124) Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-124?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-124:
--------------------------------
[~mchoma] The client provides the serverName when server is created as unbound (serverName = null).
Negotiated property mean value is provided by opposite side of the communication - so yes, client in case of SaslServer.
Ad task 8001104: this is feature request for feature, which is necessary to implement unbound for GS2/GSSAPI sasl server - this is used in attached pull request.
> Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value
> --------------------------------------------------------------------------------
>
> Key: ELY-124
> URL: https://issues.jboss.org/browse/ELY-124
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Affects Versions: 1.2.0.Beta10
> Reporter: David Lloyd
> Assignee: Jan Kalina
> Fix For: 1.2.0.Beta11
>
>
> Since Java 8, the SaslServerFactory interface has been changed so that the serverName may be null. If null, the server name is considered "unbound" and the client can select what server name it wants to use.
> The release notes say:
> {quote}
> SASL service for multiple host names: When creating a SASL server, the server name can be set to null to denote an unbound server, which means a client can request for the service using any server name. After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME. See RFE 7110803.
> {quote}
> The updated JavaDoc says:
> {quote}
> serverName - The fully qualified host name of the server to authenticate to, or null if the server is not bound to any specific host name. If the mechanism does not allow an unbound server, a SaslException will be thrown.
> {quote}
> The RFE link is: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7110803
> The two SASL mechanisms in Elytron that would be impacted by this are DIGEST-MD5 and GSSAPI.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFLY-6696) Problem with infinispan, Unable to acquire lock after 15 seconds for key
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6696?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6696:
------------------------------------
To support concurrent distributed web session access, you should configure your web session cache configuration to be non-transactional, with READ_COMMITTED isolation.
We're working on improving distributed web session concurrency over the next few releases, such that sessions are fully concurrent, but only on one node at a time.
> Problem with infinispan, Unable to acquire lock after 15 seconds for key
> -------------------------------------------------------------------------
>
> Key: WFLY-6696
> URL: https://issues.jboss.org/browse/WFLY-6696
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: linux debian, apache, oracle database
> Reporter: Bruno Silva
> Assignee: Paul Ferraro
> Attachments: error.txt
>
>
> I have two nodes in cluster using standalone-ha.xml, but when put <distributable/> into web.xml the error below has happened frenquently and I'm using SSO.
> {noformat}
> 2016-06-09 14:46:55,160 ERROR [io.undertow.request] (default task-93) UT005071: Undertow request failed HttpServerExchange{ GET /intranet/app/pagina.action request Cookie=[JSESSIONID=hwGOzICm6QQGaHzyf3MQ8jK8j7aRBGbDksNF4oeK.node3; JSESSIONIDSSO=iYEO1MGfzBBsKmvmuO8HPz0whseKXJmRzjuuuiRQ; org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key hwGOzICm6QQGaHzyf3MQ8jK8j7aRBGbDksNF4oeK and requestor GlobalTransaction:<node3>:475504:local. Lock is held by GlobalTransaction:<node3>:474447:local
> at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAllAndRecord(AbstractLockingInterceptor.java:199)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:199)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:165)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:184)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:157)
> at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:215)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitLockControlCommand(TransactionSynchronizerInterceptor.java:78)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:238)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:102)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:81)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:163)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:828)
> at org.infinispan.cache.impl.CacheImpl.lock(CacheImpl.java:810)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.lock(AbstractDelegatingAdvancedCache.java:177)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:84)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:69)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:39)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:61)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:40)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:234)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:139)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:726)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:756)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:760)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:557)
> at io.undertow.servlet.spec.HttpServletResponseImpl.doErrorDispatch(HttpServletResponseImpl.java:168)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:319)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFLY-4616) Problem with distributable sessions on long IO
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-4616?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-4616:
------------------------------------
>From the configuration XML, you can either:
* Replace <transaction mode="BATCH"/> with <transaction mode="NONE"/>
* Remove <transaction mode="BATCH"/> altogether - this will use the default mode of NONE.
>From the CLI, any of the following will work:
* /subsystem=infinispan/cache-container=web/distributed-cache=dist/component=transaction:write-attribute(name=mode, value=NONE){allow-resource-service-restart=true}
* /subsystem=infinispan/cache-container=web/distributed-cache=dist/component=transaction:undefine-attribute(name=mode){allow-resource-service-restart=true} This will revert the mode attribute to its default value of NONE.
* /subsystem=infinispan/cache-container=web/distributed-cache=dist/component=transaction:remove(){allow-resource-service-restart=true} As a required cache component, the resource will be recreated using its default values.
When using a non-transactional cache (where each cache operation is a separate tx), REPEATABLE_READ doesn't make much sense, so I would suggest switching the lock isolation mode to READ_COMMITTED.
> Problem with distributable sessions on long IO
> ----------------------------------------------
>
> Key: WFLY-4616
> URL: https://issues.jboss.org/browse/WFLY-4616
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.1.0.Final, 8.2.0.Final, 10.0.0.Final
> Reporter: Paweł Goździkowski
> Assignee: Paul Ferraro
> Priority: Critical
>
> Hi,
> I faced problem with wildfly <distributable/> what I want to ask is if it will be fixed/or is fixed in new versions on wildfly.
> The problem is when server starts performing long operation, ex. moving file to ntfs file system wildfly hangs over and starts to throw exceptions.. I tested it on wildfly 8.1 and 8.2 and wildfly and problem still occures.
> Disscusion about it you can find:
> https://developer.jboss.org/message/908454?et=watches.email.thread#908454
> Exception:
> 13:19:00,670 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-19) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [15 seconds] on key [j4-c64fI_msgIgF60Eqw_q72] for requestor [GlobalTransaction:<pgozdzik/web>:6832:local]! Lock held by [GlobalTransaction:<pgozdzik/web>:6830:local]
> at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:198)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:171)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:169)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitGetKeyValueCommand(PessimisticLockingInterceptor.java:70)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:226)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:263)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:247)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.CacheImpl.get(CacheImpl.java:377)
> at org.infinispan.DecoratedCache.get(DecoratedCache.java:396)
> at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271)
> at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54)
> at org.jboss.as.clustering.infinispan.invoker.Locator$LockingFindOperation.invoke(Locator.java:71)
> at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
> at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:109)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:55)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:149)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:353) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:168) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:153) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
>
> 13:19:00,727 ERROR [io.undertow.request] (default task-19) UT005023: Exception handling request to /test: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=6832}, status=1} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275)
> at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:263)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:247)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.CacheImpl.get(CacheImpl.java:377)
> at org.infinispan.DecoratedCache.get(DecoratedCache.java:396)
> at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271)
> at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54)
> at org.jboss.as.clustering.infinispan.invoker.Locator$LockingFindOperation.invoke(Locator.java:71)
> at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
> at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:109)
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.findValue(CoarseSessionFactory.java:55)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:149)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:353) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:168) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:153) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]
> - See more at: https://developer.jboss.org/message/908454?et=watches.email.thread#908454
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ELY-124) Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-124?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-124:
---------------------------
Affects Version/s: 1.2.0.Beta10
> Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value
> --------------------------------------------------------------------------------
>
> Key: ELY-124
> URL: https://issues.jboss.org/browse/ELY-124
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Affects Versions: 1.2.0.Beta10
> Reporter: David Lloyd
> Assignee: Jan Kalina
> Fix For: 1.2.0.Beta11
>
>
> Since Java 8, the SaslServerFactory interface has been changed so that the serverName may be null. If null, the server name is considered "unbound" and the client can select what server name it wants to use.
> The release notes say:
> {quote}
> SASL service for multiple host names: When creating a SASL server, the server name can be set to null to denote an unbound server, which means a client can request for the service using any server name. After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME. See RFE 7110803.
> {quote}
> The updated JavaDoc says:
> {quote}
> serverName - The fully qualified host name of the server to authenticate to, or null if the server is not bound to any specific host name. If the mechanism does not allow an unbound server, a SaslException will be thrown.
> {quote}
> The RFE link is: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7110803
> The two SASL mechanisms in Elytron that would be impacted by this are DIGEST-MD5 and GSSAPI.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ELY-283) Investigate Elytron and gssproxy interoperability
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-283 at 12/20/17 9:57 AM:
----------------------------------------------------------
OK, I has found the problem: the SIGSEGV in cfree occures when variable *minor* passed into the *gss_accept_sec_context* is not initialized to zero!
After following modification acceptContext call finish successfully:
{code}
src/java.security.jgss/share/native/libj2gss/GSSLibStub.c
- OM_uint32 minor, major;
+ OM_uint32 minor = 0, major;
{code}
As the *minor_status* parameter is defined as output, I suppose this is bug of kerberos library and zero initialization of minor should not be required.
was (Author: honza889):
OK, I has found the problem: the SIGSEGV in cfree occures when variable *minor* passed into the *gss_accept_sec_context* is not initialized to zero!
After following modification acceptContext call finish successfully:
{code}
- OM_uint32 minor, major;
+ OM_uint32 minor = 0, major;
{code}
As the *minor_status* parameter is defined as output, I suppose this is bug of kerberos library and zero initialization of minor should not be required.
> Investigate Elytron and gssproxy interoperability
> -------------------------------------------------
>
> Key: ELY-283
> URL: https://issues.jboss.org/browse/ELY-283
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Reporter: Peter Skopek
> Assignee: Jan Kalina
> Fix For: 2.0.0.Alpha1
>
> Attachments: openjdk-patch-native-mechs.patch
>
>
> Investigate Elytron and gssproxy interoperability.
> https://fedorahosted.org/gss-proxy/
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ELY-283) Investigate Elytron and gssproxy interoperability
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-283:
--------------------------------
OK, I has found the problem: the SIGSEGV in cfree occures when variable *minor* passed into the *gss_accept_sec_context* is not initialized to zero!
After following modification acceptContext call finish successfully:
{code}
- OM_uint32 minor, major;
+ OM_uint32 minor = 0, major;
{code}
As the *minor_status* parameter is defined as output, I suppose this is bug of kerberos library and zero initialization of minor should not be required.
> Investigate Elytron and gssproxy interoperability
> -------------------------------------------------
>
> Key: ELY-283
> URL: https://issues.jboss.org/browse/ELY-283
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Reporter: Peter Skopek
> Assignee: Jan Kalina
> Fix For: 2.0.0.Alpha1
>
> Attachments: openjdk-patch-native-mechs.patch
>
>
> Investigate Elytron and gssproxy interoperability.
> https://fedorahosted.org/gss-proxy/
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (AS7-6441) Transaction automatically started for MDB even though it uses BMT
by Donatas Čiukšys (JIRA)
[ https://issues.jboss.org/browse/AS7-6441?page=com.atlassian.jira.plugin.s... ]
Donatas Čiukšys commented on AS7-6441:
--------------------------------------
This issue is not fixed. We reproduced it on EAP 7.0.5. Please re-open.
> Transaction automatically started for MDB even though it uses BMT
> -----------------------------------------------------------------
>
> Key: AS7-6441
> URL: https://issues.jboss.org/browse/AS7-6441
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Justin Bertram
> Assignee: jaikiran pai
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> When an MDB uses BMT a transaction is still begun when onMessage() is invoked. This is because org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent#isDeliveryTransacted doesn't check whether or not the MDB is using BMT.
> You can workaround this issue by using CMT with NOT_SUPPORTED.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (DROOLS-2122) Error when drl file is opened with in project with runtime classes
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2122?page=com.atlassian.jira.plugi... ]
Andrej Podhradsky closed DROOLS-2122.
-------------------------------------
Verified with Devstudio IS 11.1.0.CR2 which contains Drools 7.5.0.Final
> Error when drl file is opened with in project with runtime classes
> -------------------------------------------------------------------
>
> Key: DROOLS-2122
> URL: https://issues.jboss.org/browse/DROOLS-2122
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Affects Versions: 7.3.0.Final
> Environment: DevstudioIS 11.1.0.Beta1
> Brms 6.4.6.GA
> Reporter: Tomas David
> Assignee: Mario Fusco
> Priority: Blocker
> Fix For: 7.5.0.Final
>
> Attachments: Screenshot from 2017-11-09 09-55-05.png, devstudiolog.log
>
>
> If new drools project is created with build using Java and Drools classes, error is displayed after drl file is opened.
> This blocks also other functions like add a breakpoint or show content assist menu.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months