[JBoss JIRA] Created: (JGRP-563) Consolidate state transfer API to use streams
by Vladimir Blagojevic (JIRA)
Consolidate state transfer API to use streams
---------------------------------------------
Key: JGRP-563
URL: http://jira.jboss.com/jira/browse/JGRP-563
Project: JGroups
Issue Type: Task
Reporter: Vladimir Blagojevic
Assigned To: Vladimir Blagojevic
Fix For: 3.0
Although streaming state transfer has its advantages over byte based state transfer, byte based state transfer is absolutely necessary since streaming based transfer relies on plain sockets that are not firewall friendly. However, that does not mean that we cannot consolidate state transfer API at application level and mask byte based transfer with streams. We have already done this in JBC 2.0 so there is no reason not to do it on JGroups level as well.
Advantages:
- simpler state transfer API
- interchangeable state transfer mechanism without affect on application
- simplification of client application
Disadvantages:
- we break current API by eliminating getState(byte[]) and setState(byte [])
--
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
13 years, 6 months
[JBoss JIRA] Created: (JGRP-567) Add one shot state transfer for multiple substates
by Vladimir Blagojevic (JIRA)
Add one shot state transfer for multiple substates
--------------------------------------------------
Key: JGRP-567
URL: http://jira.jboss.com/jira/browse/JGRP-567
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.x
Reporter: Vladimir Blagojevic
Assigned To: Vladimir Blagojevic
Currently (2.5) each sub state transfer requires separate state transfer invocation for each sub state. It would be very convenient if we could transfer a list of substates all in one underlying state transfer. This would require introduction of a new method in JChannel API, however we should avoid additional callbacks on application level. Proposed API for additional JChannel method is:
public boolean getState(Address target, List<String> state_ids, long timeout) throws ChannelNotConnectedException, ChannelClosedException;
--
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
13 years, 6 months
[JBoss JIRA] Created: (JBAS-5474) @PostLoad -> LazyInitializationException: illegal access to loading collection ond a @OneToMany with FetchType.EAGER
by Stefan Lindner (JIRA)
@PostLoad -> LazyInitializationException: illegal access to loading collection ond a @OneToMany with FetchType.EAGER
--------------------------------------------------------------------------------------------------------------------
Key: JBAS-5474
URL: http://jira.jboss.com/jira/browse/JBAS-5474
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB3
Affects Versions: JBossAS-4.2.2.GA
Environment: Win XP SP2, Java 1.5.0_15-b04
Reporter: Stefan Lindner
Assigned To: Carlo de Wolf
Fix For: JBossAS-4.2.3.GA
I have a bean with a @OneToMany relation mapping like
private List<TherapieeinheitBean> therapieeinheiten;
@OneToMany(
cascade = {CascadeType.REFRESH},
fetch = FetchType.EAGER,
mappedBy="therapiekatalog"
)
with FetchType.EAGER and a simnple @PostLoad like
@PostLoad
public void postLoad() {
System.out.println("!!!!!!!!!! postLoad !!!!!!!!!!");
System.out.print("size: " + therapieeinheiten.size());
}
When an entity of this bean is loaded JBoss trows
org.hibernate.LazyInitializationException: illegal access to loading collection
at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:341)
at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86)
at org.hibernate.collection.PersistentBag.iterator(PersistentBag.java:249)
at de.visiodesk.therapiekatalog.TherapiekatalogBean.postLoad(TherapiekatalogBean.java:170)
.
.
.
and prints the messages
WARN [LoadContexts] fail-safe cleanup (collections) : org.hibernate.engine.loading.CollectionLoadContext@2c8ce9<rs=Ingres-ResultSet[18523]>
WARN [CollectionLoadContext] On CollectionLoadContext#cleanup, localLoadingCollectionKeys contained [206] entries
afterwards. The PostLoad method should be called after the data was completely loaded. Is there a workaround for this Problem? I found some other ressources on the net where peole had the same problem, but I saw no resolution, no hint, no workaround.
--
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
13 years, 6 months
[JBoss JIRA] Created: (JBRULES-1644) Make drools imply null checks before trying to read a value
by Alex McCarrier (JIRA)
Make drools imply null checks before trying to read a value
-----------------------------------------------------------
Key: JBRULES-1644
URL: http://jira.jboss.com/jira/browse/JBRULES-1644
Project: JBoss Drools
Issue Type: Feature Request
Components: Drl Parser/Builder
Affects Versions: 4.0.6
Environment: all
Reporter: Alex McCarrier
Assigned To: Mark Proctor
Priority: Minor
Fix For: FUTURE
Not sure if this is MVEL or drools itself, but it would be nice if it would do null checks on fields for you rather than having the rule author do it. Example, when doing something like:
when
Object(value1.value2 == something)
before attempting to read value2 it makes sure value1 is not null, and if value1 is null than rather than throwing an error like it does currently, just consider the rule as not matching.
--
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
13 years, 7 months