Re: [infinispan-dev] Long time no hear, or ISPN-78 continued
by Ales Justin
It does, if we then have some additional method to seal-off / make-immutable that stream / big-object.
e.g.
void closeFinally(K key); // method name is taken from GAE's FileWriteChannel
Which then probably calls for check method
boolean isOpen(K key);
I would also need a way to lock access per Key,
but I guess Infinispan already knows how to to this?
(probably in this case it would have to know the Key's sub-Keys of all pieces and lock them?)
boolean lock(K key); // true if the lock succeeded
Or perhaps with timeout as well
boolean lock(K key, long time, TimeUnit unit); // true if the lock succeeded
and of course: void unlock(K key);
-Ales
> Hi Ales,
>
> yes, that sounds reasonable. In fact, I have been worrying about the
> user relinquishing control over how Infinispan handles streaming large
> objects. One quick question, though: I envisaged
>
> OutputStream writeToKey(K key)
>
> to be the "standard" way of streaming large objects into Infinispan.
> Doesn't it fit your bill?
>
> - Olaf
>
> Am 14.10.11 22:29, schrieb Ales Justin:
>> @Olaf:
>>
>> Looking at the API you proposed
>> / public interface StreamingHandler<K> {//
>> / / void writeToKey(K key, InputStream largeObject);//
>> // OutputStream writeToKey(K key);//
>> // InputStream readFromKey(K key);//
>> // boolean removeKey(K key);//
>> // StreamingHandler<K> //withFlags(Flag... flags//);
>> // }/
>>
>> and what I actually need:
>> *
>> http://code.google.com/p/googleappengine/source/browse/trunk/java/src/mai...
>> --> see openRecordWriteChannel and openRecordReadChannel
>>
>> Where the read has a way of jumping back&forth in the channel,
>> and write can seal the written bytes with closeFinally.
>> *
>> http://code.google.com/p/googleappengine/source/browse/trunk/java/src/mai...
>> *
>> http://code.google.com/p/googleappengine/source/browse/trunk/java/src/mai...
>>
>> Hence I guess we could change it to
>>
>> Closeable writeToKey(K key, InputStream largeObject); -- returning a
>> handle to seal off (making it immutable from then on)
>>
>> InputStream readFromKey (K key, long position); -- also taking
>> position into consideration
>>
>> Wdyt?
>>
>> (unfortunately I also don't have the time to help with impl,
>> but I'm definitely willing to test it (since I need it anyway, right :-)))
>>
>> -Ales
13 years, 5 months
Fwd: [jboss-as7-dev] Serializing Data in the Modular World
by Galder Zamarreño
Pete et al, for your interest. This is related to the chat we had in Lisbon about adding deployment info to the marshalling payload.
Begin forwarded message:
> From: "Jason T. Greene" <jason.greene(a)redhat.com>
> Subject: Re: [jboss-as7-dev] Serializing Data in the Modular World
> Date: October 10, 2011 5:07:24 PM GMT+02:00
> To: Galder Zamarreño <galder(a)jboss.org>
> Cc: "jboss-as7-dev(a)lists.jboss.org" <jboss-as7-dev(a)lists.jboss.org>
>
> On 10/10/11 9:33 AM, Galder Zamarreño wrote:
>> Interesting article Jason.
>>
>> This might be handy for Infinispan because in the discussions we had
>> in Lisbon, we're talking about being able to have the module
>> identifier included in the payload for AS envs. Your solution would
>> make our lifes easier.
>>
>> Couple of questions:
>>
>> - Is ModularClassResolver a class of JBoss Marshalling or AS?
>
> It's in JBoss Marshalling.
>
>>
>> - What happens if you use ModularClassResolver in a non-AS
>> environment? Could it delegate to a backup class resolver? I think
>> this could be useful.
>
> It currently requires that both communication peers use JBoss Modules, not necessarily both be AS7. For EJB3 we were going to write a variant that filtered the module information and loaded classes on the classpath to support embedded client usage in a non-modularized client. Not sure if that was done yet or not, its not much work though.
>
>>
>> Cheers,
>>
>> On Sep 27, 2011, at 11:03 PM, Jason T. Greene wrote:
>>
>>> Hi Everyone,
>>>
>>> I wrote up an article today that talks about the issues (and
>>> solutions) of serializing in a modular (or any multi-classloader)
>>> environment:
>>>
>>> http://community.jboss.org/wiki/ModularSerialization
>>>
>>> If you are developing any kind of component that sends data on AS7,
>>> then please give this a read.
>>>
>>> As an example of the application of this information, ejb3 remote
>>> communication is being developed to follow solution 3.
>>>
>>> -- Jason T. Greene JBoss AS Lead / EAP Platform Architect JBoss, a
>>> division of Red Hat
>>> _______________________________________________ jboss-as7-dev
>>> mailing list jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache
>>
>
>
> --
> Jason T. Greene
> JBoss AS Lead / EAP Platform Architect
> JBoss, a division of Red Hat
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
13 years, 5 months
FineGrainedAtomicMap pull request review
by Vladimir Blagojevic
Hey guys,
After endless hours of super interesting hacking I think this one is
close to integration now. While you guys review it I'll tidy up javadoc
and amend the pull.
A few notes. I kept applyDelta method in AdvancedCache because we can
now stick anything DeltaAware into cache and apply delta changes to that
DeltaAware using transactions. I believe that is why Manik wanted to
have applyDelta so visibly in our API. And I believe he was right - it
makes a lot of sense.
https://github.com/infinispan/infinispan/pull/570
Regards,
Vladimir
13 years, 5 months
5.1.0.BETA2 - reminder
by Galder Zamarreño
Hi guys,
BETA2 should be out next Monday, 17th October.
How are things looking on your corresponding JIRAs?
Couple of my JIRAs (https://issues.jboss.org/browse/ISPN-1396 and https://issues.jboss.org/browse/ISPN-509) are waiting for further input from several lists and both related to configuration, so I probably synch up with Pete on his configuration changes. Btw Pete, it'd be interesting to hear your thoughts on these two threads since you're the config guru :)
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
13 years, 5 months
Re: [infinispan-dev] Rollback and CacheEntry
by Mircea Markus
On 12 Oct 2011, at 10:46, Vladimir Blagojevic wrote:
> Mircea,
>
> Maybe I should have sent the previous email only to you!
>
> The reason I want to do this is that FineGrainedMap cumulative delta changes are stored in AtomicHashMap itself.
I think that causes a concurrency issue: if two tx operate on the same AHM then they will see each other's changes. The changes should be placed in the InvocationContext, or even better in the CacheTransaction object which represents the running transaction. See how CacheEntries are added to the context within the EntryWrappingInterceptor.
> They are committed when commit is issued. However, I have not hook to clear these delta changes on rollback and they get accumulated for the next commit.
>
> Therefore this use case fails:
>
> @Test(enabled=true)
> public void testRollbackAndThenCommit() throws Exception {
> final Cache<String, Object> cache1 = cache(0, "atomic");
> final Cache<String, Object> cache2 = cache(1, "atomic");
> final FineGrainedAtomicMap<String, String> map1 = AtomicMapLookup.getFineGrainedAtomicMap(cache1, "testRollbackAndThenCommit",true);
>
> tm(0, "atomic").begin();
> map1.put("k1", "v");
> map1.put("k2", "v2");
> tm(0, "atomic").rollback();
> FineGrainedAtomicMap<Object, Object> map2 = AtomicMapLookup.getFineGrainedAtomicMap(cache2, "testRollbackAndThenCommit", true);
> assert !map2.containsKey("k1");
> assert !map1.containsKey("k1");
>
> tm(0, "atomic").begin();
> map1.put("k3", "v3");
> map1.put("k4", "v4");
> tm(0, "atomic").commit();
>
> assert map1.size() == 2 && map2.size() == 2;
I guess the failure is here as the map.size == 4?
> }
>
>
> On 11-10-12 11:40 AM, Vladimir Blagojevic wrote:
>> Hi Mircea,
>>
>> Can we make a hook to notify CacheEntry-ies in context that they have
>> been rollbacked? We already have CacheEntry#rollback method but it is
>> only called in ClusteringDependentLogic when commit fails.
>>
>> We could do this easily in EntryWrappingInterceptor. However, what would
>> the effect be on the current codebase?
>>
>> Regards,
>> Vladimir
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
13 years, 5 months
Rollback and CacheEntry
by Vladimir Blagojevic
Hi Mircea,
Can we make a hook to notify CacheEntry-ies in context that they have
been rollbacked? We already have CacheEntry#rollback method but it is
only called in ClusteringDependentLogic when commit fails.
We could do this easily in EntryWrappingInterceptor. However, what would
the effect be on the current codebase?
Regards,
Vladimir
13 years, 5 months
FileCacheStore monitor exception
by Penumbra
I see that there was a jira INSP-1418 for an IllegalMonitorStateException on line 244 of loader/file/FileCacheStore.java
I'm getting a similar, if not exactly the same, exception about 30 seconds after Infinispan fires up within my TorqueBox 2.x build 504 app server.
https://gist.github.com/1272662
This particular Sinatra app is here:
https://github.com/lance/beer
TB 2.x build 504 is using Infinispan 5.1.0 Alpha. Substituting in 5.1.0 Beta had no effect.
Thanks!
--penumbra
13 years, 5 months
