[JBoss Cache: Core Edition] - Re: Should be able to use ClusteredCacheLoader with CacheMod
by lovelyliatroim
Ok correct me of im wrong here, using a clustered cache loader with replication set to replicate changes is useless because all the values will be replicated anyways to other members. It would only make sense to use it in this mode if you could configure CCL to point to a different cluster which i dont think you can do at the moment.
So is it fair to say that CCL only makes sense to use when replicating in INVALIDATION mode??
anonymous wrote :
| Now if the cluster is not replicated, nodes A, B and C would have different state, potentially using the same Fqns. And using a CCL here could result in meaningless state retrieval.
I would say it really depends on your scenario here, if i had static data that doesnt change then i wouldnt really worry about the above happening but i do see that in other scenarioÃÂôs it would be a problem.
Another question just on how CCL works. Say i have 2 nodes, A,B. Data items have a life expectancy of 15 mins on each node. So after 15 mins the data item is evicted and if a request comes in and data item isnt there we retrieve from source.
Each of the nodes are configured to use CCL and every entry made in a cache is flagged as a local entry via
treeCache.getInvocationContext().getOptionOverrides().setCacheModeLocal(true);
| treeCache.put(nodePath,map);
|
Now take sequence of events as follows
1. Node A receives request for data item X
2. Data Item X, not there, retrieve from source and place in cache.
3. 14 mins later Node B is asked for data item X,it doesnt have it but node A does and is replicated on B via CCL.
4. Data Item X is removed from the cache on node A because its 15 minute lifetime expectancy is up.
5. Node A receives request for data item X,it doesnt have it but node B does. data Item is replicated on to A via CCL. So actually data item X is older than 15 minutes in reality.
Can the above scenario happen? Will node A keep data Item X for another 15 mins and also have the possibility of the cycle continuing or does NODE B when it receives data Item X know that it must be evicted in 1 minutes time??
So does jboss cache replicate the timestamp of a data item if it is replicated from one node to another via CCL??
if not as a possible solution to achieve this could one write their own eviction policy and use an internal ID(member variable) that is transferred from node to node?
Thanks Manik,
LL
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147765#4147765
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147765
16 years
[JBoss Cache: Core Edition] - Re: Getting data from a node
by FredrikJ
The returned map from the node seems to be an instance of java.util.Collections$UnmodifiableMap. The javadoc for the UnmodifiableMap specifies:
anonymous wrote : unmodifiableMap
|
| public static <K,V> Map<K,V> unmodifiableMap(Map<? extends K,? extends V> m)
|
| Returns an unmodifiable view of the specified map. This method allows modules to provide users with "read-only" access to internal maps. Query operations on the returned map "read through" to the specified map, and attempts to modify the returned map, whether direct or via its collection views, result in an UnsupportedOperationException.
|
| The returned map will be serializable if the specified map is serializable.
|
| Parameters:
| m - the map for which an unmodifiable view is to be returned.
| Returns:
| an unmodifiable view of the specified map.
I would say it is plausible that the unmodifiedMap provides an immutable view but is still backed by a map which will reflect changes to the underlying data thus creating a map which is not safe to iterate in concurrent situations.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147756#4147756
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147756
16 years
[JBossWS] - Need help : JBossWS Security!
by xinhua
Hi all,
i want to use ssl and signature to protect my WS on Jboss4.2.2GA , ssl works perfectly but when i use client to send a request with signature, i always got an error. My codes, configurations and evn listed as followed:
JBoss4.2.2GA
jdk1.5
SSL keyStore&trustStore file: ksbws.keystore
Signature keyStore&trustStore file: ksbws_security.keystore
Server Side:
| @Stateless
| @SecurityDomain("JBossWS")
| @RolesAllowed("friend")
| @WebService(endpointInterface="de.xxx.xxx.KSBService")
| @WebContext(contextRoot="/KSBService",
| urlPattern="/*",
| authMethod="BASIC",
| transportGuarantee="CONFIDENTIAL",
| secureWSDLAccess=false)
| @EndpointConfig(configName = "Standard WSSecurity Endpoint")
| public class KSBServiceBean implements KSBService,KSBServiceRemote,KSBServiceLocal{
|
| private static final Logger log = Logger.getLogger(KSBServiceBean.class);
|
| @EJB
| KSBManagerLocal ksb;
|
| public sting validateLogin(Long userNo, String password) {
| // doSomething
| }
|
| }
in META-INF/ i putted ksbws_security.keystore and jboss-wsse-server.xml
here is my jboss-wsse-server.xml:
| <jboss-ws-security xmlns="http://www.jboss.com/ws-security/config"
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
| xsi:schemaLocation="http://www.jboss.com/ws-security/config
| http://www.jboss.com/ws-security/schema/jboss-ws-security_1_0.xsd">
| <key-store-file>META-INF/ksbws_security.keystore</key-store-file>
| <key-store-password>test</key-store-password>
| <trust-store-file>META-INF/ksbws_security.keystore</trust-store-file>
| <trust-store-password>test</trust-store-password>
| <config>
| <sign type="x509v3" alias="KSBWS_SECURITY" />
| <requires>
| <signature />
| </requires>
| </config>
| </jboss-ws-security>
|
Server side jar deployed without exception
Client:
codes
| public static void main(String[] args) {
| KSBService ksb = null;
| try {
| //SSL keystore
| System.setProperty("javax.net.ssl.keyStore", "c:\\ksbws.keystore");
| System.setProperty("javax.net.ssl.trustStore", "c:\\ksbws.keystore");
| System.setProperty("javax.net.ssl.keyStorePassword", "test");
| System.setProperty("javax.net.ssl.trustStorePassword", "test");
| System.setProperty("javax.net.ssl.keyStoreType", "jks");
| System.setProperty("javax.net.ssl.trustStoreType", "jks");
| System.setProperty("org.jboss.security.ignoreHttpsHost","true");
|
| //Signature keystore
| System.setProperty("org.jboss.ws.wsse.keyStore","c:\\ksbws_security.keystore");
| System.setProperty("org.jboss.ws.wsse.trustStore","c:\\ksbws_security.keystore");
| System.setProperty("org.jboss.ws.wsse.keyStorePassword", "test");
| System.setProperty("org.jboss.ws.wsse.trustStorePassword", "test");
| System.setProperty("org.jboss.ws.wsse.keyStoreType", "jks");
| System.setProperty("org.jboss.ws.wsse.trustStoreType", "jks");
|
| Service service = Service.create(new URL("http://localhost:8180/KSBService/KSBServiceBean?wsdl"),
| new QName("http://xxx.xxx.de/","KSBServiceBeanService") );
|
|
|
|
| ksb= service.getPort(KSBService.class);
|
| ((StubExt) ksb).setConfigName("Standard WSSecurity Client");
|
| BindingProvider bp = (BindingProvider)ksb;
| bp.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, "kermit");
| bp.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, "thefrog");
|
|
| } catch (Exception e) {
| ....
| ...
|
|
|
also, i putted jboss-wsse-client.xml in META-INF/
| <jboss-ws-security xmlns="http://www.jboss.com/ws-security/config"
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
| xsi:schemaLocation="http://www.jboss.com/ws-security/config
| http://www.jboss.com/ws-security/schema/jboss-ws-security_1_0.xsd">
| <config>
| <sign type="x509v3" alias="KSBWS_SECURITY"/>
| <requires>
| <signature/>
| </requires>
| </config>
| </jboss-ws-security>
|
But when i run client , an Exception like this:
| java.lang.ClassCastException: $Proxy23 cannot be cast to org.jboss.ws.core.StubExt
| at dexxxxx.xxxx.xxxx.MultiThreadsTest.main(MultiThreadsTest.java:43)
| Exception in thread "Thread-1" com.sun.xml.ws.client.ClientTransportException: request requires HTTP authentication: Unauthorized
| at com.sun.xml.ws.transport.http.client.HttpClientTransport.checkResponseCode(HttpClientTransport.java:197)
| at com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:137)
| at com.sun.xml.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:74)
| at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:559)
| at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:518)
| at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:503)
| at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:400)
| at com.sun.xml.ws.client.Stub.process(Stub.java:235)
| at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:120)
| at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:230)
| at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:210)
| at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:103)
| at $Proxy23.validateLogin(Unknown Source)
|
It seems that jboss-wsse-client.xml was not readed by client.
If i remove codes and configs for signature, SSL works fine.
can anyone help me???
thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147754#4147754
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147754
16 years
[JBoss Cache: Core Edition] - Getting data from a node
by FredrikJ
We have seen ConcurrentModificationExceptions in our system when handling data maps returned from a node. In the JBC javadoc it is specified that the method Node.getData() should return an immutable map.
anonymous wrote : Returns:
| a Map containing the data in this Node. If there is no data, an empty Map is returned. The Map returned is always immutable.
|
Is this still true for 2.1.0.GA? Since there was no other way I could possibly see the exception occur in our system I whipped together a quick test to see if I could rely on the returned map not to change. What I found was that you cannot safely iterate the returned data map if other threads are changing the cache, which seems to imply that the returned map is not immutable.
You can find the simple test here: http://www.cubeia.com/misc/nodedata/
It is not possible to take a defensive copy of the map either since we then might end up with a ConcurrentModificationExceptions in the initialization of the new map (this was actually the case of the original error).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147749#4147749
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147749
16 years