[JBoss JIRA] (WFLY-9541) Storing a LinkedHashMap subclass in the session breaks replication.
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9541?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-9541:
------------------------------------
[~klaasjanb] For the moment, you could workaround this issue by providing a custom Externalizer for your class (which would trump the LinkedHashMap externalizer). To do this create an implementation of org.wildfly.clustering.marshalling.Externalizer and list the implementation class in a META-INF/services/org.wildfly.clustering.marshalling.Externalizer file.
The org.wildfly.clustering.marshalling.api module, which contains this interface, is public and is exposed to deployments by default.
In general, it is a good idea to provide externalizers for custom classes like this, as it avoid the need to serialize class definitions and can reduce the replication payload significantly.
That said, this needs to be fixed. I'll alter the WFLY-9497 to be more discerning. Thanks for the report.
> Storing a LinkedHashMap subclass in the session breaks replication.
> -------------------------------------------------------------------
>
> Key: WFLY-9541
> URL: https://issues.jboss.org/browse/WFLY-9541
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 12.0.0.Alpha1
> Environment: Tested on JDK 1.8.0_152 on OS X 10.12
> Reporter: Klaasjan Brand
> Assignee: Paul Ferraro
>
> Context: trying to get one of our applications to work with Wildfly session replication.
> After trying out a build from the Wildfly master branch to test another bug I submitted I noticed another issue which works fine in the Wildfly 11 release.
> Our application has a custom LinkedHashMap subclass (MostRecentlyUsedMap from the Wicket framework) which it stores in the session. It also keeps a reference to the subclass since that one has a few extra fields.
> When marshalling the session the MostRecentlyUsedMap is converted to a LinkedHashMap. When unmarshalling the session this causes an error since the field is of the subclass type.
> This behaviour is new in WF 12 and is related to this commit:
> https://github.com/wildfly/wildfly/commit/143527f595206c5f2bf037b47c797f0...
> (fix for the WFLY-9497 issue).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
- 1
- 0
[JBoss JIRA] (DROOLS-1825) [Guided Decision Table] Ability to change HIT policy in a decision table anytime
by Toni Rikkola (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugi... ]
Toni Rikkola commented on DROOLS-1825:
--------------------------------------
You are right. The goal was to have the verification popup panel there, but when I tried to implement the feature I noticed the area was reserved by Data Modeler. Looks like it can now be shared if those two are using it. We could have dtable preferences in one icon and verification report in another.
> [Guided Decision Table] Ability to change HIT policy in a decision table anytime
> --------------------------------------------------------------------------------
>
> Key: DROOLS-1825
> URL: https://issues.jboss.org/browse/DROOLS-1825
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor
> Affects Versions: 7.1.0.Beta2
> Reporter: Ivo Bek
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: UX
> Attachments: DROOLS-1825 (Parent Rule).png, DecisionTable1.png, DecisionTable2.png
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy.
> Thus, it should be possible to change HIT policy in a decision table anytime.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
- 1
- 0
[JBoss JIRA] (WFLY-9516) JPA deployer adding cross sub deployment dependencies when multiple persistence units deployed
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-9516?page=com.atlassian.jira.plugin.... ]
Ingo Weiss commented on WFLY-9516:
----------------------------------
[~bmaxwell], do you have a reproducer at hand?
> JPA deployer adding cross sub deployment dependencies when multiple persistence units deployed
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-9516
> URL: https://issues.jboss.org/browse/WFLY-9516
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Scott Marlow
>
> If an ear contains two EJB sub deployments which each contain a Persistence Unit and a Stateless EJB which injects the PU that is in its jar using @PersistenceContext. There is a dependency being added where in the Stateless EJB from one deployment depends on the PU from the other jar. It appears this is happening after this bug fix WFLY-1531
> {code}
> app.ear
> - ejb-with-pu1.jar
> - ejb-with-pu2.jar
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
- 1
- 0
[JBoss JIRA] (WFLY-9542) Iron JAC Amar is being told to create more KeyConnectionAssociation under CachedConnectionManagerImpl then actual JTA transactions open (Reproducible with NESTED EJB calls)
by Nuno Godinho de Matos (JIRA)
Nuno Godinho de Matos created WFLY-9542:
-------------------------------------------
Summary: Iron JAC Amar is being told to create more KeyConnectionAssociation under CachedConnectionManagerImpl then actual JTA transactions open (Reproducible with NESTED EJB calls)
Key: WFLY-9542
URL: https://issues.jboss.org/browse/WFLY-9542
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.1.0.Final
Reporter: Nuno Godinho de Matos
I have been trying to understand for what reason we sometimes are seing the exception:
{panel}
IJ000311: Throwable from unregister connection: java.lang.IllegalStateException: IJ000152: Trying to return an unknown connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@2021ff6.
{panel}
I have now created a sample application that allows the exception to be reproduced:
https://github.com/99sono/wildlfly-ironjacamar-unregisterconnection/
To summarize:
If we start a JTA transaction T1 by invoking an @EJB with TransacitonAttirbute RequiresNew.
And then this EJB calls a second EJB with TransacitonAttirbute Supports.
Then we will have the problem that if the First JDBC access is done on the nested EJB, the connection handed over to the JPA layer (eclipselink) will be popped out of the
org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.currentObjects
As soon as we come out of the Nested EJB call.
I do not know how serious this is.
If somehow the popped out connection continues in fact locked to the ongoing JTA transaction or if might be going back to the connection pool and potentially be up for grabs.
This I do not know how... I lack the knowledge to say how crucial it is to have a good synchrinization between the connections being managed under the:
org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl
And the JPA layer.
But intuitively, I would say: quite important.
So whenever a Stack gets popped with connections being managed, I would intuitively say: one of the parties has done something wrong. Either:
(a) ARJUNA is asking JAC AMAR to open stacks when the JTA transaction is the same and it shouldn't, or
(b) It does not really matter that the conneciton is popped out - somehow JAC AMAR still knows that the connection it popped out is still bound to the JTA transaction and the problem is logically strange but of low impact...
What appears to be true, is that eclipselink is doing something logicla, in the sense that it is only asking for the conneciton to be closed/unregistered at the end of the JTA transaction.
NOTE:
In fact the error that we see when we get the stack trace, could also happen and no stack trance be logged by jac AMAR.
This is the scenario when JAC leaves the unregister conneciton via:
org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl would be going out via the:
{panel}
CopyOnWriteArrayList<ConnectionRecord> conns = cmToConnectionsMap.get(cm);
// Can happen if connections are "passed" between contexts
if (conns == null)
return;
{panel}
But in my oppinion this exit path deserves the exact same stack trace.
The sample application is to be found here:
https://github.com/99sono/wildlfly-ironjacamar-unregisterconnection/
This sample application is not as simple to deploy because one needs to hava a data source configured.
In any case the sample application has in src/test/resources my standalone.xml.
It should be realtively easy to fix the JDBC drivers configured in the atnadlone.xml.
And it should be relatively simple to fix the persistence.xml to search for eclipselink in the appropriate moduel.
I will no copy paste bellow the LOG of the exception of the sample application.
{panel}
2017-11-09 10:20:00,918 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73)
--------------------------------------
-- STARTING TransactionImple < ac, BasicAction: 0:ffffac140c58:634ef22a:5a041dbd:15 status: ActionStatus.RUNNING >: observing the CDI event StartupEventToTryToReproduceIJ000311Issue
--------------------------------------
2017-11-09 10:20:00,919 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) Doing a fetch ALL query. just to bind the connection manager to the KEY of stack level 1.
2017-11-09 10:20:01,033 FINE [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) Eclipselink connected (jndiName: java:/jdbc/SAMPLE_DS)- obtaining connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@1d5b3a43. Eclipselink Server session is: ServerSession(
DatabaseAccessor(connected)
PostgreSQLPlatform)
2017-11-09 10:20:01,057 FINE [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) EclipseLink - Closing connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@1d5b3a43
2017-11-09 10:20:01,063 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) At this point the org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl will have registered on stack1 the connection used by eclipselink, and unregistered as well.
However, this temporary register/de-register is sufficient to add to the current key.getCMToConnectionsMap() and entry for the JDBC connection manger.
This is fundamental, because without this step the exception that we will later see would be hidden away - even though the logical problem would be there no exception would be logged. By taking this magical step here, we have ensured that we will be able to reproduce the excpetion later.
To summarize what has happend so far.
1. We have forced eclipselink to register and unregister a connection due to are fetch id query
2. The JTA transaction ID TransactionImple < ac, BasicAction: 0:ffffac140c58:634ef22a:5a041dbd:15 status: ActionStatus.RUNNING > continues healthy and running without any problem 3. Meanwhile internally, our CachedConnectionManagerImpl, for this thread, has a single task of keys in its currentObjects field
4. The leading key on this stack does not hold any connectionrecords (eclipselink returned the connecton to the pool) but it does have a KEY for the JDBC connection manager 5. Point 4 is the magical step to allow us to see the stack trace but not the core of the issue - just the core of seing the stack trace
2017-11-09 10:20:01,066 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) START: executoreSynchronousSameJta
2017-11-09 10:20:01,066 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) Right now we are within the same JTA transaction. But on a NESTED EJB call.
What technically has happened at this point is that IRON JAC AMAR now has a second stack (keyAssociation)
in the currentObjects. We add in stacks each time we go through an EJB evne if we keep the JTA transaction
and this is the BUG. But we will see more about this later.
2017-11-09 10:20:01,066 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) STARTING 3: observing the CDI event StartupEventToTryToReproduceIJ000311Issue - The current transaction id is: TransactionImple < ac, BasicAction: 0:ffffac140c58:634ef22a:5a041dbd:15 status: ActionStatus.RUNNING >
2017-11-09 10:20:01,066 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) Going to create 50 entities on the database
2017-11-09 10:20:01,067 FINE [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) Eclipselink connected (jndiName: jdbc/SAMPLE_NON_JTA_DS)- obtaining connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@4be2573e. Eclipselink Server session is: ClientSession({})
2017-11-09 10:20:01,073 FINE [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) EclipseLink - Closing connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@4be2573e
2017-11-09 10:20:01,078 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) 50 entities should have been created:
2017-11-09 10:20:01,078 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) Now we want to flush - we want to force eclipselink to have to acquire the java:/jdbc/SAMPLE_DS and not be allowed to close the connection yet.
2017-11-09 10:20:01,085 FINE [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) Eclipselink connected (jndiName: java:/jdbc/SAMPLE_DS)- obtaining connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@2021ff6. Eclipselink Server session is: ClientSession({default=DatabaseAccessor(connected)})
2017-11-09 10:20:01,101 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) The flush has been done. We expec that the log now shows us that java:/jdbc/SAMPLE_DS connection was acquired but not yet closed by eclipselink.
2017-11-09 10:20:01,101 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) ENDING TransactionImple < ac, BasicAction: 0:ffffac140c58:634ef22a:5a041dbd:15 status: ActionStatus.RUNNING >: finishing to observer. The current transaction id is: {}
2017-11-09 10:20:01,101 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) OK. Now we are about to leave our nested EJB call. What is happening now is very important.
1. We will leave a nested EJB call but not the JTA transaction 2. Wildfly will go to the cachedConnectonManagerImpl and tell it to pop a stack (BUG) 3. The stack that goes away is actually holding the JDBC connection thta has been given to ECLIPSELINK and thta eclipselink will later try to close 4. When we leave this call we go back to STACK 1, where no connections are being managed
2017-11-09 10:20:01,102 INFO [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) FINISH: executoreSynchronousSameJta:
2017-11-09 10:20:01,102 WARN [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) NOW we are out of our nested EJB call. We are bout to leave the main EJB transaction call.
In short we are about to reproduce the stack trace.
What will now happen is the following.
1. Wildfly will tell eclipselink that the transaction is at an end and it should commit if it can
2. Eclipselink does its job of committing the changes and takes the JTA connection it was given and tries to close it
3. IRON JAC AMAR will log the stack trace we wanted to reproduce saying it has not idea what connection we are trying to return to the pool.
4. The reason the CachedConnectionManagerImpl does not know about the connection is because it was managed under STACK 2 but was popped out of existence after the nested transaction
5. Now it is very important to keep in mind that even if we were not seing the stack trace the error would be there (the moment we popped a key stack that had still connections) 6. Keep in mind that if we were to modify the source code and disable our reproduceBugService.fetchAlIds() call we would see no stack trace but the same issue would be present.7. The difference that doing the reproduceBugService.fetchAlIds() does is whether or not CachedConnectionManagerImpl during unregister connection leaves via the if conns == null return null or if goes further into the if (!ignoreConnections)
8. OK - Now that we understand what is happening behind the scenes we can let eclipselink try to close the JDBC connection at the end of the JTA transaction
2017-11-09 10:20:01,106 FINE [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) EclipseLink - Closing connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@2021ff6
2017-11-09 10:20:01,107 INFO [org.jboss.jca.core.connectionmanager.listener.TxConnectionListener] (ServerService Thread Pool -- 73) IJ000311: Throwable from unregister connection: java.lang.IllegalStateException: IJ000152: Trying to return an unknown connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@2021ff6
at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.unregisterConnection(CachedConnectionManagerImpl.java:408)
at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.connectionClosed(TxConnectionListener.java:645)
at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.returnHandle(BaseWrapperManagedConnection.java:596)
at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:541)
at org.jboss.jca.adapters.jdbc.WrappedConnection.returnConnection(WrappedConnection.java:298)
at org.jboss.jca.adapters.jdbc.WrappedConnection.close(WrappedConnection.java:256)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.closeDatasourceConnection(DatabaseAccessor.java:522)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.closeConnection(DatasourceAccessor.java:537)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.closeConnection(DatabaseAccessor.java:545)
at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.closeJTSConnection(DatasourceAccessor.java:188)
at org.eclipse.persistence.sessions.server.ClientSession.releaseJTSConnection(ClientSession.java:171)
at org.eclipse.persistence.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:175)
at org.eclipse.persistence.transaction.JTASynchronizationListener.beforeCompletion(JTASynchronizationListener.java:68)
at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:116)
at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:368)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200)
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:91)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:349)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:241)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
at startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb$$$view9.observeStartupEventToTryToReproduceIJ000311Issue(Unknown Source)
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 org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
at startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb$Proxy$_$$_Weld$EnterpriseProxy$.observeStartupEventToTryToReproduceIJ000311Issue(Unknown Source)
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 org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78)
at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269)
at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:302)
at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:291)
at org.jboss.weld.event.EventImpl.fire(EventImpl.java:89)
at startupconnectionproblem.event.FireStartupEventsServiceImpl.fireStartupCDIEvents(FireStartupEventsServiceImpl.java:41)
at startupconnectionproblem.event.FireStartupEventsServiceImpl$Proxy$_$$_WeldClientProxy.fireStartupCDIEvents(Unknown Source)
at startupconnectionproblem.event.StartupSingletonLocalEjb.postConstrcut(StartupSingletonLocalEjb.java:38)
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 org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:114)
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:103)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263)
at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.notSupported(LifecycleCMTTxInterceptor.java:87)
at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.singleton.StartupCountDownInterceptor.processInvocation(StartupCountDownInterceptor.java:25)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
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:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
2017-11-09 10:20:01,114 INFO [startupconnectionproblem.event.FireStartupEventsServiceImpl] (ServerService Thread Pool -- 73) FIINSH: StartupEventToTryToReproduceIJ000311Issue
2017-11-09 10:20:01,114 INFO [startupconnectionproblem.event.StartupSingletonLocalEjb] (ServerService Thread Pool -- 73) ENDING 1: Post construct of startup bean singleton ending
2017-11-09 10:20:01,240 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 73) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '/app'
2017-11-09 10:20:02,098 INFO [org.primefaces.webapp.PostConstructA
{panel}
Thanks for considering this issue.
I do not know how much impact this issue can actually have.
We have many hundred different types of JTA business transactions, and we see this sample application happening on system tests and stress tests relatively often.
Now that I have better understand of the issue, I can in some cases rework the code to dodge this problem to avoid nested calls of EJBS on the same transaciton - but this will not always be possible.
And I would be quite afraid of this issue, if means that our connectons still in the hands of ElcipseLInk are going back to the pool.
This would explain some strange errors we have had only on stress test application, that we do not see when using a different app server.
I must say it was extremelly difficult to be able to make the stack trace reproducible.
There are many tricky points to be able to lead the code to go precisely through the code path that leads to the excpetion.
But it is relatively trivial to make the code leave through the "silent bug iron jac amar code path".
Many thanks for all the help on this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
- 1
- 0
[JBoss JIRA] (DROOLS-2123) Signavio extensions module was missing in the kie-dmn-bom
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-2123:
--------------------------------------
Summary: Signavio extensions module was missing in the kie-dmn-bom
Key: DROOLS-2123
URL: https://issues.jboss.org/browse/DROOLS-2123
Project: Drools
Issue Type: Bug
Components: dmn engine
Reporter: Matteo Mortari
Assignee: Matteo Mortari
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
- 1
- 0
[JBoss JIRA] (ELY-1439) Perform certificate authentication only in cases when certificate is present
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1439?page=com.atlassian.jira.plugin.s... ]
Martin Choma updated ELY-1439:
------------------------------
Description:
{noformat}
Martin Choma·10:18 AM
I see some client certificate verificaton related exception. However, I am not configuring 2 way SSL, just 1 way SSL. Why does this verification happens eagerly when there is no chance it can success?
Darran Lofthouse·11:03 AM
@MartinChoma it is one of those older APIs where the only way we can find out if we do have a peer certificate is to make the call and find out if we get a response or an exception - that is why it is only logged at TRACE level. In this case this is in the mechanism initialisation so slightly separate from the SSLContext handling. Maybe we could double check if we have access to the SSLContext itself at any point and check if needing or wanting a client cert was enabled, but in the want case we would still get this same message if it was not available.
Martin Choma·11:09 AM
@DarranLofthouse , yes I was thinking of optimalization based on leveraging need-client-auth attribute. I will create enhancement ELY JIRA.
Darran Lofthouse·11:10 AM
@MartinChoma what we would need to check is if we get access to that, I can't remember if Remoting passes us the complete SSLContext or just the SSLSession if it exists
{noformat}
{noformat}
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "management-client"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.5.Final-redhat-1"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service
10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to unverified SSL peer
10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism ANONYMOUS
10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 79 bytes
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) No buffers in queue for message header
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Allocated fresh buffers
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received 79 bytes
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received message java.nio.HeapByteBuffer[pos=0 lim=75 cap=8192]
10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capabilities response
10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: version 1
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote endpoint name "localhost:MANAGEMENT"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: SASL mechanism ANONYMOUS
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) SASL mechanism ANONYMOUS added to allowed set
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: message close protocol supported
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote version is "5.0.5.Final-redhat-1"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels in is "40"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels out is "40"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: authentication service
10:13:29,084 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient for mechanism ANONYMOUS, using Provider WildFlyElytron and protocol remote
10:13:29,087 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient [org.wildfly.security.sasl.util.PrivilegedSaslClient@286a43a6->org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory$LocalPrincipalSaslClient@149c06be->org.wildfly.security.sasl.anonymous.AnonymousSaslClient@56ad35c9] for mechanisms [ANONYMOUS]
10:13:29,088 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client initiating authentication using mechanism ANONYMOUS
10:13:29,091 TRACE [org.jboss.remoting.endpoint] (XNIO-1 I/O-1) Allocated tick to 9 of endpoint "management-client" <7968a9d> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor@71812f8)
10:13:29,093 TRACE [org.jboss.remoting.remote] (XNIO-1 task-3) Setting read listener to org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication@4dff2604
10:13:29,094 TRACE [org.jboss.remoting.endpoint] (XNIO-1 task-3) Resource closed count 00000008 of endpoint "management-client" <7968a9d> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor@71812f8)
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Sent 24 bytes
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Flushed channel
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 24 bytes
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192]
10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192]
10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received authentication request
10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Peer unverified: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:431)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1000)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
at org.wildfly.security.sasl.util.SSLQueryCallbackHandler.handle(SSLQueryCallbackHandler.java:68)
at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
at org.wildfly.security.sasl.util.SetMechanismInformationSaslServerFactory.createSaslServer(SetMechanismInformationSaslServerFactory.java:74)
at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory.createSaslServer(AuthenticationCompleteCallbackSaslServerFactory.java:51)
at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.createSaslServer(TrustManagerSaslServerFactory.java:72)
at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory.createSaslServer(AuthenticationTimeoutSaslServerFactory.java:74)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
at org.wildfly.security.sasl.util.SSLSaslServerFactory.createSaslServer(SSLSaslServerFactory.java:67)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
at org.wildfly.security.sasl.util.ServerNameSaslServerFactory.createSaslServer(ServerNameSaslServerFactory.java:48)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
at org.wildfly.security.sasl.util.ProtocolSaslServerFactory.createSaslServer(ProtocolSaslServerFactory.java:48)
at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory.createSaslServer(SecurityIdentitySaslServerFactory.java:51)
at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:61)
at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:52)
at org.wildfly.security.auth.server.AbstractMechanismAuthenticationFactory.createMechanism(AbstractMechanismAuthenticationFactory.java:54)
at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:281)
at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:141)
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:1131)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback type='SASL' name='ANONYMOUS' host-name='localhost.localdomain' protocol='remote'
10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Created SaslServer [org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1@2a8e9ff7->org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer@493accbb->org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1@6a9c91e2->org.wildfly.security.sasl.anonymous.AnonymousSaslServer@2b612585] for mechanism [ANONYMOUS]
{noformat}
was:
Martin Choma·10:18 AM
I see some client certificate verificaton related exception. However, I am not configuring 2 way SSL, just 1 way SSL. Why does this verification happens eagerly when there is no chance it can success?
{noformat}
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "management-client"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.5.Final-redhat-1"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service
10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to unverified SSL peer
10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism ANONYMOUS
10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 79 bytes
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) No buffers in queue for message header
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Allocated fresh buffers
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received 79 bytes
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received message java.nio.HeapByteBuffer[pos=0 lim=75 cap=8192]
10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capabilities response
10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: version 1
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote endpoint name "localhost:MANAGEMENT"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: SASL mechanism ANONYMOUS
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) SASL mechanism ANONYMOUS added to allowed set
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: message close protocol supported
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote version is "5.0.5.Final-redhat-1"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels in is "40"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels out is "40"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: authentication service
10:13:29,084 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient for mechanism ANONYMOUS, using Provider WildFlyElytron and protocol remote
10:13:29,087 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient [org.wildfly.security.sasl.util.PrivilegedSaslClient@286a43a6->org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory$LocalPrincipalSaslClient@149c06be->org.wildfly.security.sasl.anonymous.AnonymousSaslClient@56ad35c9] for mechanisms [ANONYMOUS]
10:13:29,088 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client initiating authentication using mechanism ANONYMOUS
10:13:29,091 TRACE [org.jboss.remoting.endpoint] (XNIO-1 I/O-1) Allocated tick to 9 of endpoint "management-client" <7968a9d> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor@71812f8)
10:13:29,093 TRACE [org.jboss.remoting.remote] (XNIO-1 task-3) Setting read listener to org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication@4dff2604
10:13:29,094 TRACE [org.jboss.remoting.endpoint] (XNIO-1 task-3) Resource closed count 00000008 of endpoint "management-client" <7968a9d> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor@71812f8)
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Sent 24 bytes
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Flushed channel
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 24 bytes
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192]
10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192]
10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received authentication request
10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Peer unverified: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:431)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1000)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
at org.wildfly.security.sasl.util.SSLQueryCallbackHandler.handle(SSLQueryCallbackHandler.java:68)
at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
at org.wildfly.security.sasl.util.SetMechanismInformationSaslServerFactory.createSaslServer(SetMechanismInformationSaslServerFactory.java:74)
at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory.createSaslServer(AuthenticationCompleteCallbackSaslServerFactory.java:51)
at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.createSaslServer(TrustManagerSaslServerFactory.java:72)
at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory.createSaslServer(AuthenticationTimeoutSaslServerFactory.java:74)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
at org.wildfly.security.sasl.util.SSLSaslServerFactory.createSaslServer(SSLSaslServerFactory.java:67)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
at org.wildfly.security.sasl.util.ServerNameSaslServerFactory.createSaslServer(ServerNameSaslServerFactory.java:48)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
at org.wildfly.security.sasl.util.ProtocolSaslServerFactory.createSaslServer(ProtocolSaslServerFactory.java:48)
at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory.createSaslServer(SecurityIdentitySaslServerFactory.java:51)
at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:61)
at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:52)
at org.wildfly.security.auth.server.AbstractMechanismAuthenticationFactory.createMechanism(AbstractMechanismAuthenticationFactory.java:54)
at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:281)
at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:141)
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:1131)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback type='SASL' name='ANONYMOUS' host-name='localhost.localdomain' protocol='remote'
10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Created SaslServer [org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1@2a8e9ff7->org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer@493accbb->org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1@6a9c91e2->org.wildfly.security.sasl.anonymous.AnonymousSaslServer@2b612585] for mechanism [ANONYMOUS]
{noformat}
Darran Lofthouse·11:03 AM
@MartinChoma it is one of those older APIs where the only way we can find out if we do have a peer certificate is to make the call and find out if we get a response or an exception - that is why it is only logged at TRACE level. In this case this is in the mechanism initialisation so slightly separate from the SSLContext handling. Maybe we could double check if we have access to the SSLContext itself at any point and check if needing or wanting a client cert was enabled, but in the want case we would still get this same message if it was not available.
Martin Choma·11:09 AM
@DarranLofthouse , yes I was thinking of optimalization based on leveraging need-client-auth attribute. I will create enhancement ELY JIRA.
Darran Lofthouse·11:10 AM
@MartinChoma what we would need to check is if we get access to that, I can't remember if Remoting passes us the complete SSLContext or just the SSLSession if it exists
> Perform certificate authentication only in cases when certificate is present
> ----------------------------------------------------------------------------
>
> Key: ELY-1439
> URL: https://issues.jboss.org/browse/ELY-1439
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Mechanisms
> Affects Versions: 1.2.0.Beta9
> Reporter: Martin Choma
>
> {noformat}
> Martin Choma·10:18 AM
> I see some client certificate verificaton related exception. However, I am not configuring 2 way SSL, just 1 way SSL. Why does this verification happens eagerly when there is no chance it can success?
> Darran Lofthouse·11:03 AM
> @MartinChoma it is one of those older APIs where the only way we can find out if we do have a peer certificate is to make the call and find out if we get a response or an exception - that is why it is only logged at TRACE level. In this case this is in the mechanism initialisation so slightly separate from the SSLContext handling. Maybe we could double check if we have access to the SSLContext itself at any point and check if needing or wanting a client cert was enabled, but in the want case we would still get this same message if it was not available.
> Martin Choma·11:09 AM
> @DarranLofthouse , yes I was thinking of optimalization based on leveraging need-client-auth attribute. I will create enhancement ELY JIRA.
> Darran Lofthouse·11:10 AM
> @MartinChoma what we would need to check is if we get access to that, I can't remember if Remoting passes us the complete SSLContext or just the SSLSession if it exists
> {noformat}
> {noformat}
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "management-client"
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.5.Final-redhat-1"
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40"
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40"
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service
> 10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to unverified SSL peer
> 10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism ANONYMOUS
> 10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 79 bytes
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) No buffers in queue for message header
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Allocated fresh buffers
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received 79 bytes
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received message java.nio.HeapByteBuffer[pos=0 lim=75 cap=8192]
> 10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capabilities response
> 10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: version 1
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote endpoint name "localhost:MANAGEMENT"
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: SASL mechanism ANONYMOUS
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) SASL mechanism ANONYMOUS added to allowed set
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: message close protocol supported
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote version is "5.0.5.Final-redhat-1"
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels in is "40"
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels out is "40"
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: authentication service
> 10:13:29,084 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient for mechanism ANONYMOUS, using Provider WildFlyElytron and protocol remote
> 10:13:29,087 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient [org.wildfly.security.sasl.util.PrivilegedSaslClient@286a43a6->org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory$LocalPrincipalSaslClient@149c06be->org.wildfly.security.sasl.anonymous.AnonymousSaslClient@56ad35c9] for mechanisms [ANONYMOUS]
> 10:13:29,088 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client initiating authentication using mechanism ANONYMOUS
> 10:13:29,091 TRACE [org.jboss.remoting.endpoint] (XNIO-1 I/O-1) Allocated tick to 9 of endpoint "management-client" <7968a9d> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor@71812f8)
> 10:13:29,093 TRACE [org.jboss.remoting.remote] (XNIO-1 task-3) Setting read listener to org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication@4dff2604
> 10:13:29,094 TRACE [org.jboss.remoting.endpoint] (XNIO-1 task-3) Resource closed count 00000008 of endpoint "management-client" <7968a9d> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor@71812f8)
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Sent 24 bytes
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Flushed channel
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 24 bytes
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192]
> 10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192]
> 10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received authentication request
> 10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Peer unverified: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
> at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:431)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1000)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
> at org.wildfly.security.sasl.util.SSLQueryCallbackHandler.handle(SSLQueryCallbackHandler.java:68)
> at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
> at org.wildfly.security.sasl.util.SetMechanismInformationSaslServerFactory.createSaslServer(SetMechanismInformationSaslServerFactory.java:74)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory.createSaslServer(AuthenticationCompleteCallbackSaslServerFactory.java:51)
> at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.createSaslServer(TrustManagerSaslServerFactory.java:72)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory.createSaslServer(AuthenticationTimeoutSaslServerFactory.java:74)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
> at org.wildfly.security.sasl.util.SSLSaslServerFactory.createSaslServer(SSLSaslServerFactory.java:67)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
> at org.wildfly.security.sasl.util.ServerNameSaslServerFactory.createSaslServer(ServerNameSaslServerFactory.java:48)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
> at org.wildfly.security.sasl.util.ProtocolSaslServerFactory.createSaslServer(ProtocolSaslServerFactory.java:48)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory.createSaslServer(SecurityIdentitySaslServerFactory.java:51)
> at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:61)
> at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:52)
> at org.wildfly.security.auth.server.AbstractMechanismAuthenticationFactory.createMechanism(AbstractMechanismAuthenticationFactory.java:54)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:281)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:141)
> 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:1131)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> 10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback type='SASL' name='ANONYMOUS' host-name='localhost.localdomain' protocol='remote'
> 10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Created SaslServer [org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1@2a8e9ff7->org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer@493accbb->org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1@6a9c91e2->org.wildfly.security.sasl.anonymous.AnonymousSaslServer@2b612585] for mechanism [ANONYMOUS]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
- 1
- 0
[JBoss JIRA] (ELY-1439) Perform certificate authentication only in cases when certificate is present
by Martin Choma (JIRA)
Martin Choma created ELY-1439:
---------------------------------
Summary: Perform certificate authentication only in cases when certificate is present
Key: ELY-1439
URL: https://issues.jboss.org/browse/ELY-1439
Project: WildFly Elytron
Issue Type: Enhancement
Components: Authentication Mechanisms
Affects Versions: 1.2.0.Beta9
Reporter: Martin Choma
Martin Choma·10:18 AM
I see some client certificate verificaton related exception. However, I am not configuring 2 way SSL, just 1 way SSL. Why does this verification happens eagerly when there is no chance it can success?
{noformat}
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "management-client"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.5.Final-redhat-1"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service
10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to unverified SSL peer
10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism ANONYMOUS
10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 79 bytes
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) No buffers in queue for message header
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Allocated fresh buffers
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received 79 bytes
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received message java.nio.HeapByteBuffer[pos=0 lim=75 cap=8192]
10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capabilities response
10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: version 1
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote endpoint name "localhost:MANAGEMENT"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: SASL mechanism ANONYMOUS
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) SASL mechanism ANONYMOUS added to allowed set
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: message close protocol supported
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote version is "5.0.5.Final-redhat-1"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels in is "40"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels out is "40"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: authentication service
10:13:29,084 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient for mechanism ANONYMOUS, using Provider WildFlyElytron and protocol remote
10:13:29,087 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient [org.wildfly.security.sasl.util.PrivilegedSaslClient@286a43a6->org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory$LocalPrincipalSaslClient@149c06be->org.wildfly.security.sasl.anonymous.AnonymousSaslClient@56ad35c9] for mechanisms [ANONYMOUS]
10:13:29,088 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client initiating authentication using mechanism ANONYMOUS
10:13:29,091 TRACE [org.jboss.remoting.endpoint] (XNIO-1 I/O-1) Allocated tick to 9 of endpoint "management-client" <7968a9d> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor@71812f8)
10:13:29,093 TRACE [org.jboss.remoting.remote] (XNIO-1 task-3) Setting read listener to org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication@4dff2604
10:13:29,094 TRACE [org.jboss.remoting.endpoint] (XNIO-1 task-3) Resource closed count 00000008 of endpoint "management-client" <7968a9d> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor@71812f8)
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Sent 24 bytes
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Flushed channel
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 24 bytes
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192]
10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192]
10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received authentication request
10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Peer unverified: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:431)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1000)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
at org.wildfly.security.sasl.util.SSLQueryCallbackHandler.handle(SSLQueryCallbackHandler.java:68)
at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
at org.wildfly.security.sasl.util.SetMechanismInformationSaslServerFactory.createSaslServer(SetMechanismInformationSaslServerFactory.java:74)
at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory.createSaslServer(AuthenticationCompleteCallbackSaslServerFactory.java:51)
at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.createSaslServer(TrustManagerSaslServerFactory.java:72)
at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory.createSaslServer(AuthenticationTimeoutSaslServerFactory.java:74)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
at org.wildfly.security.sasl.util.SSLSaslServerFactory.createSaslServer(SSLSaslServerFactory.java:67)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
at org.wildfly.security.sasl.util.ServerNameSaslServerFactory.createSaslServer(ServerNameSaslServerFactory.java:48)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
at org.wildfly.security.sasl.util.ProtocolSaslServerFactory.createSaslServer(ProtocolSaslServerFactory.java:48)
at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory.createSaslServer(SecurityIdentitySaslServerFactory.java:51)
at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:61)
at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:52)
at org.wildfly.security.auth.server.AbstractMechanismAuthenticationFactory.createMechanism(AbstractMechanismAuthenticationFactory.java:54)
at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:281)
at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:141)
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:1131)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback type='SASL' name='ANONYMOUS' host-name='localhost.localdomain' protocol='remote'
10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Created SaslServer [org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1@2a8e9ff7->org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer@493accbb->org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1@6a9c91e2->org.wildfly.security.sasl.anonymous.AnonymousSaslServer@2b612585] for mechanism [ANONYMOUS]
{noformat}
Darran Lofthouse·11:03 AM
@MartinChoma it is one of those older APIs where the only way we can find out if we do have a peer certificate is to make the call and find out if we get a response or an exception - that is why it is only logged at TRACE level. In this case this is in the mechanism initialisation so slightly separate from the SSLContext handling. Maybe we could double check if we have access to the SSLContext itself at any point and check if needing or wanting a client cert was enabled, but in the want case we would still get this same message if it was not available.
Martin Choma·11:09 AM
@DarranLofthouse , yes I was thinking of optimalization based on leveraging need-client-auth attribute. I will create enhancement ELY JIRA.
Darran Lofthouse·11:10 AM
@MartinChoma what we would need to check is if we get access to that, I can't remember if Remoting passes us the complete SSLContext or just the SSLSession if it exists
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
- 1
- 0
[JBoss JIRA] (DROOLS-2122) Error when drl file is opened with in project with runtime classes
by Tomas David (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2122?page=com.atlassian.jira.plugi... ]
Tomas David updated DROOLS-2122:
--------------------------------
Description:
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.
was:If new drools project is created with build using Java and Drools classes, error is displayed after drl file is opened.
> 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
> Priority: Blocker
> 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, 8 months
- 1
- 0
[JBoss JIRA] (DROOLS-2122) Error when drl file is opened with in project with runtime classes
by Tomas David (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2122?page=com.atlassian.jira.plugi... ]
Tomas David commented on DROOLS-2122:
-------------------------------------
[~KrisVerlaenen], eclipse plugin issues are still assigned to Robert (Bob) Brodt but he is no longer the developer of this component. Should I assignee these issues to you?
> 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
> Priority: Blocker
> 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 message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
- 1
- 0
[JBoss JIRA] (DROOLS-2122) Error when drl file is opened with in project with runtime classes
by Tomas David (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2122?page=com.atlassian.jira.plugi... ]
Tomas David reassigned DROOLS-2122:
-----------------------------------
Assignee: (was: Tomas David)
> 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
> Priority: Blocker
> 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 message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
- 1
- 0