[JBoss JIRA] Updated: (JBAS-3194) Proxies for HAServiceMBeanSupport subclass unbound across cluster when any instance undeployed
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3194?page=all ]
Brian Stansberry updated JBAS-3194:
-----------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
Scott, I pushed this out to 4.0.6. If you can do it before Aug 4 for 4.0.5, that's fine, but 4.0.6 is OK.
> Proxies for HAServiceMBeanSupport subclass unbound across cluster when any instance undeployed
> ----------------------------------------------------------------------------------------------
>
> Key: JBAS-3194
> URL: http://jira.jboss.com/jira/browse/JBAS-3194
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: JBossAS-4.0.4.CR2, JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final
> Reporter: Brian Stansberry
> Assigned To: Scott Marlow
> Fix For: JBossAS-4.0.6.CR1
>
>
> ProxyFactoryHA registers a JMX notification listener for the shutdown of its target service and removes the proxy from JNDI on receipt of the notification. HAServiceMBeanSupport broadcasts its JMX notifications *across the cluster*. The effect of this is that the ProxyFactoryHA on all cluster nodes will receive the notification when any one instance of the service undeploys. The effect is all proxies across the cluster are removed from JNDI.
> Test org.jboss.test.cluster.jmx.test.HAInvokerUnitTestCase demonstrates this.
> Following is a deliberately created stacktrace showing the origin of a notification that caused an invalid removal from JNDI:
> 2006-05-08 01:51:53,703 DEBUG [org.jboss.proxy.generic.ProxyFactoryHA] About to stop: disabling remote access to mbean jboss.test:service=HAService
> 2006-05-08 01:51:53,703 DEBUG [org.jboss.proxy.generic.ProxyFactoryHA] java.lang.Exception: stacktrace
> java.lang.Exception: stacktrace
> at org.jboss.proxy.generic.ProxyFactoryHA.containerIsAboutToStop(ProxyFactoryHA.java:169)
> at org.jboss.proxy.generic.ProxyFactoryHA$StateChangeListener.handleNotification(ProxyFactoryHA.java:231)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.notification.NotificationListenerProxy.invoke(NotificationListenerProxy.java:153)
> at $Proxy10.handleNotification(Unknown Source)
> at org.jboss.mx.util.JBossNotificationBroadcasterSupport.handleNotification(JBossNotificationBroadcasterSupport.java:127)
> at org.jboss.mx.util.JBossNotificationBroadcasterSupport.sendNotification(JBossNotificationBroadcasterSupport.java:110)
> at org.jboss.ha.jmx.HAServiceMBeanSupport._receiveRemoteNotification(HAServiceMBeanSupport.java:393)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330)
> at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:1017)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:597)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:497)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:320)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:725)
> at org.jgroups.JChannel.up(JChannel.java:1041)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:377)
> at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:393)
> at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:141)
> at org.jgroups.stack.UpHandler.run(Protocol.java:60)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months
[JBoss JIRA] Commented: (JBAS-1322) Farm service fails to deploy correctly on startup
by Scott Marlow (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1322?page=comments#action_12340094 ]
Scott Marlow commented on JBAS-1322:
------------------------------------
At the last JBoss World Las Vegas, we had a face-2-face discussion about JBoss 5 and cluster management. We decided at that time, that its not worth making further improvements to farm deployment, since we are making cluster deployment in 5.x, a part of cluster administration.
> Farm service fails to deploy correctly on startup
> -------------------------------------------------
>
> Key: JBAS-1322
> URL: http://jira.jboss.com/jira/browse/JBAS-1322
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: JBossAS-4.0.0 Final
> Reporter: Andrew Oliver
> Assigned To: Scott Marlow
> Fix For: JBossAS-4.0.5.CR1
>
> Original Estimate: 2 hours
> Time Spent: 6 hours
> Remaining Estimate: 0 minutes
>
> Assume we have two JBoss nodes in a cluster. If we start node A and node B then deploy an ear file to farm it is propegated to both servers as expected. If we have the ear file in node A's farm but not node B's farm -- then start node B fully before starting node A -- Jboss fails to deploy the ear to node B.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months
[JBoss JIRA] Updated: (JBAS-1553) Update the JAAS login module base class password mapping options
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1553?page=all ]
Dimitris Andreadis updated JBAS-1553:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
> Update the JAAS login module base class password mapping options
> ----------------------------------------------------------------
>
> Key: JBAS-1553
> URL: http://jira.jboss.com/jira/browse/JBAS-1553
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: JBossAS-3.2.7 Final, JBossAS-4.0.1 Final
> Reporter: Scott M Stark
> Fix For: JBossAS-4.0.6.CR1
>
>
> Currently we support a simple notion of only having the first login module perform authentication with all other login modules bypassing authentication when the password-stacking=useFirstPass
> We need to update the base login modules that support most of the options from the jaas developer guide:
> * try_first_pass - If true, the first LoginModule in the stack saves the password entered, and subsequent LoginModules also try to use it. If authentication fails, the LoginModules prompt for a new password and retry the authentication.
> * use_first_pass - If true, the first LoginModule in the stack saves the password entered, and subsequent LoginModules also try to use it. LoginModules do not prompt for a new password if authentication fails (authentication simply fails).
> * try_mapped_pass - If true, the first LoginModule in the stack saves the password entered, and subsequent LoginModules attempt to map it into their service-specific password. If authentication fails, the LoginModules prompt for a new password and retry the authentication.
> * use_mapped_pass - If true, the first LoginModule in the stack saves the password entered, and subsequent LoginModules attempt to map it into their service-specific password. LoginModules do not prompt for a new password if authentication fails (authentication simply fails).
> * moduleBanner - If true, then when invoking the CallbackHandler, the LoginModule provides a TextOutputCallback as the first Callback, which describes the LoginModule performing the authentication.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months
[JBoss JIRA] Updated: (JBAS-1537) When Tomcat error handler is invoked, JBossGenericPrincipal is returned instead of custom principal
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1537?page=all ]
Dimitris Andreadis updated JBAS-1537:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
> When Tomcat error handler is invoked, JBossGenericPrincipal is returned instead of custom principal
> ---------------------------------------------------------------------------------------------------
>
> Key: JBAS-1537
> URL: http://jira.jboss.com/jira/browse/JBAS-1537
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Tomcat) service
> Affects Versions: JBossAS-4.0.1 Final
> Environment: linux i386, jdk 1.4.2_07
> Reporter: Rick Wong
> Assigned To: Anil Saldhana
> Fix For: JBossAS-4.0.6.CR1
>
>
> Hi,
> I followed the instruction in the Wiki to set up a custom principal
> http://www.jboss.org/wiki/Wiki.jsp?page=UsingCustomPrincpalsWith
> Normally, this works perfectly such that the call to
> request.getUserPrincipal()
> returns my custom principal type. However, if a JSP error page is invoked either by the default error handler in the web.xml, or by the JSP declaration, a different Principal object is returned.
> A call to request.getUserPrincipal() in the error handler results in an object of type
> org.jboss.web.tomcat.security.JBossGenericPrincipal
> Is this by design? Shouldn't it also return my custom attribute?
> Thanks,
> --
> Rick
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months
[JBoss JIRA] Updated: (JBAS-1057) FK Violation deleting 1-1 relationship
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1057?page=all ]
Dimitris Andreadis updated JBAS-1057:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
> FK Violation deleting 1-1 relationship
> --------------------------------------
>
> Key: JBAS-1057
> URL: http://jira.jboss.com/jira/browse/JBAS-1057
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CMP service
> Affects Versions: JBossAS-3.2.6 Final
> Reporter: SourceForge User
> Assigned To: Alexey Loubyansky
> Fix For: JBossAS-4.0.6.CR1
>
>
> SourceForge Submitter: suzyrizzo .
> I have attached a set of CMPs that cause a foreign key
> violation when deleted.
> Entities:
> Group
> Address
> GroupId
> Group has a uni-directional 1-1 relationship with
> Address. A foreign key is set up on the
> Group.physicalAddressKey field.
> Group has a bi-directional 1-many relationship with
> GroupId.
> I have batch-cascade-delete turned on for the group-
> has-groupids relationship because the GroupId.groupKey
> cannot be null.
> I do not have batch-cascade-delete turned on for the
> group-has-address relationship because
> physicalAddressKey is an FK into Address, so Address
> cannot be deleted before Group.
> The relationships work separately, but when I have them
> defined at the same time, I get a Foreign Key violation.
> I've included the server.log file with the full error
> message in my attachment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months
[JBoss JIRA] Updated: (JBAS-1177) NPE on TableCache while promoting row
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1177?page=all ]
Dimitris Andreadis updated JBAS-1177:
-------------------------------------
Fix Version/s: (was: JBossAS-4.0.5.CR1)
> NPE on TableCache while promoting row
> -------------------------------------
>
> Key: JBAS-1177
> URL: http://jira.jboss.com/jira/browse/JBAS-1177
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CMP service
> Affects Versions: JBossAS-3.2.6 Final
> Reporter: SourceForge User
> Assigned To: Alexey Loubyansky
>
> SourceForge Submitter: ioparra .
> JBoss3_2_6
> with Cache Invalidition
> JDK1.4
> The system was under heavy load both from normal
> means and cache invalidation.
> Race condition???
> java.lang.NullPointerException
> at
> org.jboss.ejb.plugins.cmp.jdbc2.schema.TableCache$Cac
> hedRow.access$202(TableCache.java:418)
> at
> org.jboss.ejb.plugins.cmp.jdbc2.schema.TableCache.prom
> oteRow(TableCache.java:388)
> at
> org.jboss.ejb.plugins.cmp.jdbc2.schema.TableCache.getFi
> elds(TableCache.java:157)
> at
> org.jboss.ejb.plugins.cmp.jdbc2.schema.PartitionedTableC
> ache.getFields(PartitionedTableCache.java:152)
> at
> org.jboss.ejb.plugins.cmp.jdbc2.schema.EntityTable$View
> .getRowByPk(EntityTable.java:868)
> at
> org.jboss.ejb.plugins.cmp.jdbc2.schema.EntityTable.loadR
> ow(EntityTable.java:444)
> at
> org.jboss.ejb.plugins.cmp.jdbc2.JDBCStoreManager2.loadE
> ntity(JDBCStoreManager2.java:347)
> at
> org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity
> (CMPPersistenceManager.java:338)
> at
> org.jboss.resource.connectionmanager.CachedConnection
> Interceptor.loadEntity
> (CachedConnectionInterceptor.java:355)
> at
> org.jboss.ejb.plugins.EntitySynchronizationInterceptor.inv
> oke(EntitySynchronizationInterceptor.java:246)
> at
> org.jboss.resource.connectionmanager.CachedConnection
> Interceptor.invoke
> (CachedConnectionInterceptor.java:186)
> at
> org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke
> (EntityReentranceInterceptor.java:116)
> at
> org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke
> (EntityInstanceInterceptor.java:175)
> at
> org.jboss.ejb.plugins.EntityCreationInterceptor.invoke
> (EntityCreationInterceptor.java:54)
> at
> org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
> (AbstractTxInterceptor.java:84)
> at
> org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
> ons(TxInterceptorCMT.java:315)
> at org.jboss.ejb.plugins.TxInterceptorCMT.invoke
> (TxInterceptorCMT.java:148)
> at org.jboss.ejb.plugins.SecurityInterceptor.invoke
> (SecurityInterceptor.java:111)
> at org.jboss.ejb.plugins.LogInterceptor.invoke
> (LogInterceptor.java:191)
> at
> org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invok
> e(ProxyFactoryFinderInterceptor.java:122)
> at org.jboss.ejb.EntityContainer.internalInvoke
> (EntityContainer.java:484)
> at org.jboss.ejb.Container.invoke
> (Container.java:709)
> at
> org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke
> (BaseLocalProxyFactory.java:419)
> at org.jboss.ejb.plugins.local.EntityProxy.invoke
> (EntityProxy.java:44)
> at $Proxy1224.getName(Unknown Source)
> at
> com.activereasoning.session.infrastructure.DeviceConfigS
> essionBean.updateOrCreateNew
> (DeviceConfigSessionBean.java:300)
> at sun.reflect.GeneratedMethodAccessor164.invoke
> (Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke
> (Method.java:324)
> at
> org.jboss.ejb.StatelessSessionContainer$ContainerInterce
> ptor.invoke(StatelessSessionContainer.java:683)
> at
> org.jboss.resource.connectionmanager.CachedConnection
> Interceptor.invoke
> (CachedConnectionInterceptor.java:186)
> at
> org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor
> .invoke(StatelessSessionInstanceInterceptor.java:72)
> at
> org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
> (AbstractTxInterceptor.java:84)
> at
> org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
> ons(TxInterceptorCMT.java:315)
> at org.jboss.ejb.plugins.TxInterceptorCMT.invoke
> (TxInterceptorCMT.java:148)
> at org.jboss.ejb.plugins.AbstractInterceptor.invoke
> (AbstractInterceptor.java:94)
> at
> com.activereasoning.metrics.MetricsInterceptor.invoke
> (MetricsInterceptor.java:63)
> at org.jboss.ejb.plugins.SecurityInterceptor.invoke
> (SecurityInterceptor.java:111)
> at org.jboss.ejb.plugins.LogInterceptor.invoke
> (LogInterceptor.java:191)
> at
> org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invok
> e(ProxyFactoryFinderInterceptor.java:122)
> at
> org.jboss.ejb.StatelessSessionContainer.internalInvoke
> (StatelessSessionContainer.java:331)
> at org.jboss.ejb.Container.invoke
> (Container.java:709)
> at
> org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke
> (BaseLocalProxyFactory.java:419)
> at
> org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke
> (StatelessSessionProxy.java:83)
> at $Proxy1772.updateOrCreateNew(Unknown
> Source)
> at
> com.activereasoning.probemanager.ver4.converters.Host
> ConfigConverter.processCmd
> (HostConfigConverter.java:147)
> at
> com.activereasoning.probemanager.ver4.util.MessageProc
> essor.processXMLMesgs(MessageProcessor.java:251)
> at
> com.activereasoning.probemanager.ver4.util.MessageProc
> essor.processMesg(MessageProcessor.java:138)
> at
> com.activereasoning.probemanager.mesgbeans.MDDataLis
> tenerBean.onMessage(MDDataListenerBean.java:190)
> at sun.reflect.GeneratedMethodAccessor100.invoke
> (Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke
> (Method.java:324)
> at
> org.jboss.ejb.MessageDrivenContainer$ContainerIntercept
> or.invoke(MessageDrivenContainer.java:458)
> at
> org.jboss.resource.connectionmanager.CachedConnection
> Interceptor.invoke
> (CachedConnectionInterceptor.java:186)
> at
> org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.i
> nvoke(MessageDrivenInstanceInterceptor.java:62)
> at
> org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
> (AbstractTxInterceptor.java:84)
> at
> org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
> ons(TxInterceptorCMT.java:282)
> at org.jboss.ejb.plugins.TxInterceptorCMT.invoke
> (TxInterceptorCMT.java:148)
> at org.jboss.ejb.plugins.AbstractInterceptor.invoke
> (AbstractInterceptor.java:94)
> at
> com.activereasoning.metrics.MetricsInterceptor.invoke
> (MetricsInterceptor.java:63)
> at
> org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke
> (RunAsSecurityInterceptor.java:90)
> at org.jboss.ejb.plugins.LogInterceptor.invoke
> (LogInterceptor.java:191)
> at
> org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invok
> e(ProxyFactoryFinderInterceptor.java:122)
> at
> org.jboss.ejb.MessageDrivenContainer.internalInvoke
> (MessageDrivenContainer.java:372)
> at org.jboss.ejb.Container.invoke
> (Container.java:709)
> at
> org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke
> (JMSContainerInvoker.java:914)
> at
> org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageLi
> stenerImpl.onMessage(JMSContainerInvoker.java:1208)
> at
> com.sonicsw.pso.jboss.SonicMQServerSession.onMessage
> (SonicMQServerSession.java:118)
> at progress.message.jimpl.Session.kT_(Unknown
> Source)
> at progress.message.jimpl.Session.run(Unknown
> Source)
> at
> com.sonicsw.pso.jboss.SonicMQServerSession.run
> (SonicMQServerSession.java:80)
> at
> EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.
> run(PooledExecutor.java:748)
> at java.lang.Thread.run(Thread.java:534)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months