[JBoss JIRA] Commented: (JBAS-1098) Foreign key violation during cascade delete
by Gunnar Grim (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1098?page=comments#action_12355968 ]
Gunnar Grim commented on JBAS-1098:
-----------------------------------
The batch-cascade-delete workaround can't be used when there are more than one level of cascade delete. Why is this issue rejected?
> Foreign key violation during cascade delete
> -------------------------------------------
>
> Key: JBAS-1098
> URL: http://jira.jboss.com/jira/browse/JBAS-1098
> 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: No Release
>
>
> SourceForge Submitter: sflexus .
> JBoss 3.2.5, JDK 1.4.2_04, Linux.
> I have CMP Entity Customer and CMP entity Album with
> the following relationships:
> 1) 1 Customer has Many Albums
> 2) 1 Customer has 1 Album "Inbox"
> 3) 1 Customer has 1 Album "Private"
> 4) 1 Customer has 1 Album "Recycle Bin"
> So basically there are 3 Albums each of which has double
> relationship to Customer, both 1-1 and 1-M
> Relationship (1) has cascade-delete on Album side, so if
> customer is deleted, all his albums should be deleted.
> Relationships (2)-(4) has NO cascade-delete setting,
> since (1) should be enough, as it references ALL
> customer's albums, including those referenced in (2)-(4).
> There are other entities related to Customer in the
> application, but they seem non-important (at first sight).
> If I try to remove Customer instance, I get foreigh key
> violation in the database. All foreign keys were created
> by JBoss itself. I have attached TRACE-level log. What
> happens is that all 3 albums (inbox, private and recycle
> bin, their IDs are 162, 163 and 164) are scheduled for
> cascade delete, but only the one with ID=164 is updated
> to set its CMR column to NULL before issuing DELETE
> FROM Customer SQL. The foreign key fk_album_owner
> which is being violated corresponds to relation (1) "1
> Customer has Many Albums".
> The interesting thing is that if I redeploy the application
> and issue remove again, it completes normally! Looks like
> it depends on some cache state.
> Two files are attached. First one demonstrates foreign
> key violation, second one demonstrates success deletion
> after application is redeployed.
--
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, 1 month
[JBoss JIRA] Created: (JBCACHE-950) Expose information about buddy group membership
by Brian Stansberry (JIRA)
Expose information about buddy group membership
-----------------------------------------------
Key: JBCACHE-950
URL: http://jira.jboss.com/jira/browse/JBCACHE-950
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Currently there is no way for external code to find out any information about how the cache participates in buddy relationships.
Two issues (probably should be subtasks):
1) BuddyManager exposes getBuddyAddresses() but that only provides info about the group for which the node is data owner, not for any groups the node participates in as a buddy. Also, it returns an internal data structure, making it unsafe to expose to random code.
Because of this, if a "primary buddy" wanted to gravitate some or all data upon exit of the data owner, it would have no way to know if it is primary. Having all buddies gravitate data would be "a bad thing".
1) In 2.0.0 I believe the BuddyManager is not available except through CacheSPI. Perhaps some info about buddy group membership could be exposed via RuntimeConfig.
--
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, 1 month
[JBoss JIRA] Updated: (JGRP-176) Asynchronous dispatching of requests in RequestCorrelator
by Bela Ban (JIRA)
[ http://jira.jboss.com/jira/browse/JGRP-176?page=all ]
Bela Ban updated JGRP-176:
--------------------------
Fix Version/s: 2.6
(was: 2.5)
Moved to 2.6, as break-the-locks (JBCACHE-326) has been moved to JBossCache 2.1.0.
Note: we may not even need this functionality anymore, as the concurrent stack might already solve this by delivering messages from different senders on different threads
> Asynchronous dispatching of requests in RequestCorrelator
> ---------------------------------------------------------
>
> Key: JGRP-176
> URL: http://jira.jboss.com/jira/browse/JGRP-176
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 2.2.9.1, 2.2.9, 2.2.8
> Reporter: Bela Ban
> Assigned To: Vladimir Blagojevic
> Fix For: 2.6
>
>
> In RequestCorrelator.handleRequest(), we call handle(Message) on the registered RequestHandler (RpcDispatcher in the case of JBossCache).
> Because of http://jira.jboss.com/jira/browse/JBCACHE-326, we need to provide an asynchronous way of calling handle(Message), which doesn't need to wait for the call to return, but is notified later when the response is ready (or not at all if the call is asynchronous).
> This could be implemented using a subinterface of RequestHandler (e.g. AsyncRequestHandler), and a *future*.
--
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, 1 month
[JBoss JIRA] Created: (JGRP-418) MuxChannel.getState() always returns false with StreamingStateTransfer protocol
by Jerry Gauthier (JIRA)
MuxChannel.getState() always returns false with StreamingStateTransfer protocol
-------------------------------------------------------------------------------
Key: JGRP-418
URL: http://jira.jboss.com/jira/browse/JGRP-418
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4.1
Reporter: Jerry Gauthier
Assigned To: Vladimir Blagojevic
When I execute DRMTestCase.testIsMasterReplica() in JBossAS 5.0 using the StreamingStateTransfer protocol, MuxChannel.getState() always returns false. This method is invoked from ClusterPartition.fetchState(); it returns false even though debugging the other node in a two node cluster shows that the state has been retrieved. If I use the StateTransfer protocol instead, the transfer is successful.
I started debugging this issue and determined that ClusterPartition never successfully retrieves state from the multiplexer channel when using StreamingStateTransfer. It's possible that the problem lies in ClusterPartition but this can't be determined until it's understood why getState() is returning false.
This problem can be replicated as follows.
1) Ensure that you're using the latest JBossAS 5.0.0 HEAD cluster and testsuite\cluster code as I made recent changes in this area.
2) Modify ..\cluster\output\resources\jgroups-multiplexer.sar\META-INF\multiplexer-stacks.xml. Change the "tunnel" stack to use StreamingStateTransfer instead of StateTransfer. This is the stack used by the test in DRMTestCase.testIsMasterReplica().
3) Running the test should show the following result.
<error message="Initial serviceState transfer failed: Channel.getState() returned false" type="java.lang.IllegalStateException">java.lang.IllegalStateException: Initial serviceState transfer failed: Channel.getState() returned false
at org.jboss.ha.framework.server.ClusterPartition.fetchState(ClusterPartition.java:511)
at org.jboss.ha.framework.server.ClusterPartition.startService(ClusterPartition.java:335)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
at org.jboss.test.cluster.test.DRMTestCase.testIsMasterReplica(DRMTestCase.java:686)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
</error>
4) Note: DRMTestCase.testIsMasterReplica() won't execute successfully with the StateTransfer protocol until JGRP-416 is resolved. This issue causes JGroups to issue UnsupportedOperationException for UnmodifiableVector during the merge process in the test case. I've patched the problem in JGroups locally and confirmed that the test does run successfully for StateTransfer after this issue is resolved. It's not necessary to patch JGRP-416 to investigate MuxChannel.getState() as the state problem occurs before the UnmodifiableVector problem.
--
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, 1 month
[JBoss JIRA] Commented: (JBPORTAL-692) Calendar Portlet
by Peter Oates (JIRA)
[ http://jira.jboss.com/jira/browse/JBPORTAL-692?page=comments#action_12355945 ]
Peter Oates commented on JBPORTAL-692:
--------------------------------------
Hi,
I'm having a issue deploying this portlet.
I build the portlet with ant,then i put both har and war files in the deploy dir.
I'm testing it with the standard jboss portal bundle downloaded.Im getting many errors
but the culmination is this.
--- MBeans waiting for other MBeans ---
ObjectName: portal:service=CalendarioHibernate
State: CONFIGURED
I Depend On:
jboss.jca:service=DataSourceBinding,name=jdbc/intranetDS
--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.jca:service=DataSourceBinding,name=jdbc/intranetDS
State: NOTYETINSTALLED
Depends On Me:
portal:service=CalendarioHibernate
> Calendar Portlet
> ----------------
>
> Key: JBPORTAL-692
> URL: http://jira.jboss.com/jira/browse/JBPORTAL-692
> Project: JBoss Portal
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Portal Samples
> Reporter: Roy Russo
> Priority: Optional
> Attachments: CalendarioPortlet.zip, CalendarioPortlet.zip, CalendarioPortlet.zip, MyFacesPortletExtension.zip
>
>
> Simple Calendar portlet that displays a calendar of the month, allowing for month-to-month navigation.
> - User should be able to access a specific day and add an event to it.
> - Days with events, should be highlighted in the month-view. Should not be tied to external calendar services, such as MS Exchange.
> *A calendar sharing feature is a nice-to-have addon.
--
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, 1 month